Quick Comparison Table
Before going into the detail, here is a side-by-side summary of DORA and the CRA across the dimensions that matter most for compliance planning.
| Dimension | DORA (EU 2022/2554) | CRA (EU 2024/2847) |
|---|---|---|
| Legal form | Regulation (directly applicable) | Regulation (directly applicable) |
| Primary focus | Operational resilience of financial entities | Cybersecurity of products with digital elements |
| Who it applies to | ~22,000 EU financial entities + critical ICT providers | Manufacturers, importers, and distributors of digital products on the EU market |
| Sector scope | Financial services only | Horizontal (all sectors, all digital products) |
| Enforcement date | 17 January 2025 | Phased: reporting Sep 2026, full obligations Dec 2027 |
| Core obligation | ICT risk management, incident reporting, resilience testing, third-party oversight | Security by design, vulnerability handling, SBOM, CE marking |
| Vulnerability mgmt | Identify and remediate ICT vulnerabilities in operational environment | Handle product vulnerabilities throughout support period, coordinated disclosure |
| Incident reporting | 4h initial / 72h intermediate / 1 month final to financial NCA | 24h notification of actively exploited vulnerabilities to ENISA + national CSIRT |
| Third-party focus | Detailed: Register of Information, mandatory contract clauses, CTPP oversight | Supply chain due diligence for product components and dependencies |
| Penalties | Set by NCAs under existing powers; CTPP fines up to 1% daily turnover | Up to EUR 15M or 2.5% of global turnover; product recall or withdrawal |
| Supervisory model | Financial supervisors (ECB, EBA, ESMA, EIOPA) + Lead Overseers | National market surveillance authorities + ENISA coordination |
DORA: Operational Resilience for Financial Services
DORA (Regulation (EU) 2022/2554) is an EU regulation that focuses exclusively on the financial sector. Its purpose is to ensure that financial entities can withstand, respond to, and recover from ICT-related disruptions. It addresses the systemic risk that arises when the financial sector depends heavily on a small number of critical technology providers.
DORA applies to around 22,000 financial entities in the EU, including banks, insurers, investment firms, payment institutions, electronic money institutions, crypto-asset service providers, and credit rating agencies. It also brings critical ICT third-party service providers (CTPPs) under direct EU-level oversight for the first time.
The regulation is organised around five pillars: ICT risk management (Art. 5-16), incident management and reporting (Art. 17-23), digital resilience testing (Art. 24-27), third-party ICT risk management (Art. 28-44), and information sharing (Art. 45). Each pillar is supported by Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that provide detailed implementation guidance.
DORA's perspective is that of the entity using ICT: how do you govern, protect, test, and manage the technology your business depends on? This is a fundamentally different question from what the CRA asks.
CRA: Product Security for Digital Products
The Cyber Resilience Act (Regulation (EU) 2024/2847) is a horizontal regulation that applies to manufacturers, importers, and distributors of products with digital elements placed on the EU market. Unlike DORA, the CRA is not sector-specific; it applies across all industries, from consumer IoT devices to enterprise software and industrial control systems.
The CRA introduces mandatory cybersecurity requirements for hardware and software products throughout their lifecycle. Manufacturers must design products with security built in, provide security updates for the expected product lifetime (minimum five years), handle vulnerabilities through coordinated disclosure, and produce a Software Bill of Materials (SBOM) documenting product components and dependencies.
Products are classified into default, important (Class I and Class II), and critical categories, with higher-risk categories requiring third-party conformity assessment. Products that meet the essential cybersecurity requirements receive CE marking, without which they cannot legally be placed on the EU market.
The CRA's perspective is that of the product maker: how do you ensure the digital products you place on the market are secure by design, remain patched, and have their vulnerabilities transparently managed? This complements DORA, which asks how entities using those products remain operationally resilient.
Where DORA and the CRA Overlap
Although DORA and the CRA address different sides of the cybersecurity equation, they share several common themes that create natural points of interaction.
Vulnerability Management
Both regulations require systematic handling of vulnerabilities. DORA mandates that financial entities identify, classify, and remediate ICT vulnerabilities. The CRA requires manufacturers to handle product vulnerabilities throughout the support period, issue security patches, and report actively exploited vulnerabilities to ENISA. Better product security under the CRA directly reduces the vulnerability surface that financial entities manage under DORA.
Incident Reporting
Both regulations impose incident reporting obligations, though to different authorities and with different triggers. DORA requires financial entities to report significant ICT-related incidents to their financial NCA. The CRA requires manufacturers to report actively exploited vulnerabilities and severe security incidents affecting their products to ENISA and the relevant national CSIRT. A single vulnerability could trigger reporting under both regulations if it affects a product used by a financial entity.
Supply Chain Transparency
DORA requires financial entities to maintain a Register of Information documenting all ICT third-party arrangements. The CRA requires manufacturers to exercise due diligence on third-party components integrated into their products and to produce SBOMs. Together, these requirements create end-to-end supply chain visibility: the CRA ensures transparency at the product component level, while DORA ensures transparency at the service provider level.
Security by Design
Both regulations emphasise proactive security. DORA requires financial entities to embed ICT risk management into their operational processes, conduct resilience testing, and maintain secure configurations. The CRA requires manufacturers to apply security-by-design and security-by-default principles to their products. The combination ensures that both the products and the environments in which they operate are built with security as a foundational requirement.
Where DORA and the CRA Diverge
Despite shared cybersecurity goals, the two regulations are designed for fundamentally different regulatory contexts. Understanding these differences is essential for organisations that may interact with both.
Regulatory perspective. DORA regulates entities that use ICT (financial institutions and their service providers). The CRA regulates entities that make ICT products (manufacturers, importers, distributors). A bank using a trading platform is subject to DORA. The company that built the trading platform is subject to the CRA. These are complementary, not competing, obligations.
Third-party oversight vs CE marking. DORA's approach to product and service quality is indirect: it requires financial entities to conduct due diligence on their ICT providers, include mandatory contract clauses, and maintain exit strategies. The CRA's approach is direct: it requires manufacturers to meet essential cybersecurity requirements and obtain CE marking before placing products on the market. The CRA effectively sets a security floor for products that financial entities then assess through their DORA third-party risk management framework.
SBOM requirements. The CRA mandates that manufacturers produce a Software Bill of Materials (SBOM) documenting product components and dependencies. DORA does not require financial entities to produce SBOMs, though financial entities may benefit from requesting them from their ICT providers as part of third-party due diligence under Art. 28-30. As CRA compliance becomes standard, SBOMs will become a natural input to DORA risk assessments.
Testing obligations. DORA prescribes a structured resilience testing programme, including annual basic testing and threat-led penetration testing (TLPT) every three years for designated entities. The CRA requires manufacturers to conduct conformity assessments and security testing before placing products on the market, but does not mandate ongoing penetration testing in the DORA sense. The testing philosophies differ: DORA tests operational environments, the CRA tests products.
Penalty frameworks. The CRA imposes some of the highest penalties in EU product regulation: up to EUR 15 million or 2.5% of global annual turnover for non-compliance with essential cybersecurity requirements, and market surveillance authorities can order product recall or withdrawal. DORA's penalties are determined by national financial supervisors under existing powers, with CTPP-specific periodic penalties of up to 1% of average daily worldwide turnover.
Who Needs to Comply with Both?
Most financial entities will interact with both regulations, but typically in different roles. Understanding which obligations apply to your organisation depends on whether you are a user or a maker of digital products.
Identifying your regulatory position
If your organisation is a financial entity that only uses digital products and ICT services, you are subject to DORA. The CRA will benefit you indirectly by raising the security baseline of the products you depend on. If your organisation manufactures or distributes digital products (even as a secondary activity), the CRA applies to those products. If you do both, you need to comply with both regulations in their respective scopes.
Financial entities as product manufacturers. Some financial institutions develop and distribute digital products: banking APIs offered to third parties, white-label payment platforms, risk management software sold to other institutions, or mobile banking apps distributed through app stores. Where these constitute products with digital elements placed on the market, the CRA applies alongside DORA.
Fintech companies. Fintechs that are both regulated financial entities and software product companies are the clearest case of dual regulation. A fintech that holds a payment institution licence and sells its payment processing software to other institutions must comply with DORA for its own operational resilience and with the CRA for the security of the software products it places on the market.
ICT providers to the financial sector. Technology companies that provide ICT services to financial entities may be subject to DORA's third-party oversight framework (and potentially CTPP designation) while also being subject to the CRA as manufacturers of digital products. These organisations need a unified compliance approach that addresses both the operational requirements of DORA and the product security requirements of the CRA.
Open-source contributors. The CRA includes exemptions for open-source software developed outside a commercial activity. However, commercial open-source stewards that monetise open-source products may fall within scope. Financial entities relying heavily on open-source components should monitor how the CRA's open-source provisions develop in practice, as this affects the security assurance available for those components under DORA.
Timeline Comparison
Understanding when each regulation's obligations take effect is essential for compliance planning, particularly for organisations subject to both.
| Milestone | DORA | CRA |
|---|---|---|
| Entry into force | 16 January 2023 | 10 December 2024 |
| Application date | 17 January 2025 (full application) | 11 December 2027 (full obligations) |
| Reporting obligations | Active since January 2025 | From 11 September 2026 (exploited vulns + severe incidents) |
| Conformity assessment | N/A (not a product regulation) | Notified body requirements from 11 June 2026 |
| Full enforcement | January 2025 (all pillars) | 11 December 2027 (essential requirements + CE marking) |
Frequently Asked Questions
Not directly in most cases. The CRA applies to manufacturers, importers, and distributors of products with digital elements. Financial institutions that only use such products are end users, not manufacturers, and are not subject to CRA obligations. However, if a financial entity develops and distributes its own digital products (e.g., a banking platform sold to other institutions), the CRA may apply to those products alongside DORA. The two regulations are complementary rather than overlapping: DORA governs how you manage your operational resilience, while the CRA governs the security of any products you place on the market.
Both regulations address vulnerability management from different angles. DORA requires financial entities to identify and remediate ICT vulnerabilities in their operational environment (Art. 7-8) and through resilience testing (Art. 24-27). The CRA requires product manufacturers to handle vulnerabilities throughout the product support period, including coordinated vulnerability disclosure, timely security updates, and reporting actively exploited vulnerabilities to ENISA within 24 hours. In practice, the CRA raises the security baseline of products that financial entities depend on, directly supporting their DORA vulnerability management obligations.
Yes. The CRA requires manufacturers to identify and document the components and dependencies of their products, including by drawing up a Software Bill of Materials. The SBOM must cover at minimum the top-level dependencies and be generated in a commonly used, machine-readable format. DORA does not require financial entities to produce SBOMs, but financial entities can benefit from requesting SBOMs from their ICT providers as part of third-party risk management under DORA Art. 28-30. As CRA compliance becomes standard, SBOMs will become a valuable input to DORA risk assessments.
The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024. It applies in phases: manufacturer reporting obligations (actively exploited vulnerabilities and severe incidents) apply from 11 September 2026; conformity assessment body requirements apply from 11 June 2026; and the full set of obligations, including essential cybersecurity requirements and CE marking, apply from 11 December 2027. Products placed on the market before 11 December 2027 are only subject to CRA requirements if they undergo a substantial modification after that date.