Another perspective on Cyber Security: The EU Cyber Resilience Act (CRA)

The Cyber Resilience Act (CRA) represents the fundamental shift from institution-centric security to Supply Chain Integrity.

For years, the financial sector has focused its defensive perimeter on operational resilience—hardening the institution itself. This culminated in the Digital Operational Resilience Act (DORA). However, a new regulatory pillar has arrived: the EU Cyber Resilience Act (CRA).While many executives view the CRA as a regulation for manufacturers, it is actually the “Missing Link” for banks. If DORA tells a bank how to drive safely, the CRA ensures the vehicle’s components aren’t defective by design.

The Fundamentals

The EU Cyber Resilience Act (CRA) is a regulation that introduces uniform cybersecurity requirements for hardware and software products placed on the EU market, aiming to reduce vulnerabilities and improve long‑term security support.

Purpose and Objectives

• Strengthen the cybersecurity of connected hardware and software products throughout their life cycle.
• Reduce the number and severity of security vulnerabilities and ensure timely security updates.
• Increase transparency so users can identify products that provide an adequate level of security (including via CE marking).

Scope of Application

• Applies to “products with digital elements” (PDE): connected hardware and software whoseintended or reasonably foreseeable use involves a direct or indirect data connection. This includes, for example, IoT devices, operating systems, applications, security software,
  password managers, VPN software, and web browsers.
• Covers manufacturers, importers, distributors, and certain service providers that place such products on the EU market.
• Some sectors with their own specific safety and security legislation (such as medical devices or automotive) are excluded where those rules already address comparable risks.

Key Obligations for Manufacturers

• Implement “security by design and by default”: cybersecurity must be embedded in the design, development, production, and maintenance of the product.
• Perform and document a cybersecurity risk assessment before placing the product on the market, covering intended use, reasonably foreseeable misuse, operating environment, and expected lifetime.
• Establish a vulnerability management process, including continuous monitoring, handling of vulnerabilities, and provision of security patches and updates.
• Provide security updates in a timely manner, enable automatic installation by default where reasonable, and clearly distinguish security updates from feature updates where possible.
• Maintain technical documentation and relevant records (e.g., risk assessments, testing evidence, vulnerability handling processes) for at least 10 years after the product is placed on the market
  or for the entire support period, whichever is longer. The CRA explicitly requires manufacturers to create an SBOM in a commonly used, machine‑readable format as part of technical documentation for products with digital elements. An SBOM (Software Bill of Materials) is a machine‑readable list of all software components and dependencies in a product.
• Ensure conformity assessment, draw up an EU declaration of conformity, and affix the CE marking to demonstrate compliance with CRA requirements.

Incident and Vulnerability Reporting

• Obligation to report exploited vulnerabilities and severe cybersecurity incidents to the relevant authorities (such as ENISA or national CSIRTs) within a short specified timeframe after becoming aware of them.
• Set up internal processes to detect, assess, and escalate security incidents and exploited vulnerabilities, and ensure that these processes are operational before the reporting obligations start to apply.

Timeline and Transition Periods

• The CRA entered into force in December 2024 as an EU regulation.
• From September 2026, the reporting obligations for exploited vulnerabilities and severe incidents begin to apply.
• From December 2027, the core substantive obligations (security requirements, conformity assessment, CE marking, etc.) become fully applicable.

Enforcement and Penalties

• Market surveillance authorities in EU Member States oversee compliance and may require corrective measures, including product recalls, withdrawal from the market, or restrictions on sales.
• Non‑compliance can lead to significant administrative fines, potentially reaching up to a substantial percentage of the company’s worldwide annual turnover or a high fixed monetary amount,
  whichever is higher, depending on the type and severity of the infringement.

What does this mean for financial institutions regulated under DORA?

Some of these obligations sound familiar, but the EU Cyber Resilience Act (CRA) is a horizontal product‑focused cybersecurity regulation that sits alongside existing financial‑sector frameworks such as DORA and NIS2. It mainly affects banks where they act as manufacturers or distributors of “products with digital elements” (PDE), for example payment cards, terminals, or mobile banking applications.

Position of CRA in the Banking Regulatory Landscape

In contrast to DORA and NIS2, which focus on operational resilience, governance and ICT risk management of financial entities, the CRA sets minimum cybersecurity requirements for hardware and software products placed on the EU market. For banks, this means that CRA obligations are triggered when they place digital products on the market under their own name or brand, or when they substantially modify such products.

Industry associations from the financial sector (like the BdB in Germany) have highlighted the risk of duplication, since CRA requirements on vulnerability management, secure development and incident reporting overlap with obligations already imposed under DORA and sector‑specific guidelines. Nevertheless, CRA remains directly applicable and requires explicit consideration in banks’ compliance frameworks.

Typical CRA-Relevant Products in Banking

Banks should perform a structured inventory of all products with digital elements that they develop, brand, or place on the market. Typical examples in the banking environment include:

• Payment cards and card readers, including point‑of‑sale (POS) terminals and possibly self‑service
  devices, where these are marketed as products under the bank’s name.
• Mobile banking applications and online banking frontends provided to retail or corporate clients, especially where the bank is responsible for design, development and updates.
• Security applications, authentication tools or SDKs (for example, apps for strong customer authentication, transaction signing or secure messaging) that are distributed to customers.
• Other proprietary software components or platforms that the bank licenses or distributes as a stand‑alone product to external customers.

When a bank qualifies as a manufacturer or places PDE on the market under its own name, it must comply with the full set of CRA obligations described above.

Overlap with DORA and NIS2

DORA and NIS2 primarily regulate the operational cyber resilience of financial entities, covering areas such as ICT risk management, incident classification and reporting, testing regimes and third‑party risk management. The CRA, by contrast, focuses on the intrinsic security of digital products. For banks, this creates both overlaps and integration opportunities.

In practice, banks should design their ICT and security control framework so that processes such as secure software development, vulnerability management, penetration testing and patch management
simultaneously fulfil the requirements of DORA, NIS2 and the CRA. This reduces duplication and helps demonstrate consistent, end‑to‑end cyber resilience across both products and operations.

CRA introduces specific reporting duties for exploited vulnerabilities and serious cybersecurity incidents related to products. These obligations coexist with DORA’s incident reporting to financial supervisors, so banks need clear internal allocation of responsibilities and harmonised workflows.

The Executive Roadmap: No-Regret Moves

With the first reporting obligations starting in September 2026, leadership must act now: