All comparisons

Cyber Resilience Act (CRA)

VS

Digital Operational Resilience Act (DORA)

CRA vs. DORA

Product security meets digital financial resilience

Product Regulation

Applies to the manufacturer: How securely is the product built and maintained?

Financial Supervisory Law

Applies to the financial entity: How resilient is the organization against ICT risks?

CRA and DORA are complementary, not interchangeable. Software manufacturers for the financial sector may be subject to both frameworks simultaneously.

0 Covered3 Partial6 Not covered

You comply with DORA — what else do you need for your products?

DORA strengthens your organization's operational resilience in the financial sector. The CRA addresses the security of your products — a fundamental perspective shift from organization to product.

036
CRA RequirementCoverage by Digital Operational Resilience Act
ICT risk management awareness
Partial

DORA Art. 5-16 establish comprehensive ICT risk management at entity level. The CRA additionally requires a product-specific cyber risk assessment per Art. 13(2).

Incident reporting processes
Partial

DORA reporting processes to financial supervisory authorities exist. The CRA requires reporting to ENISA — different triggers (product vulnerabilities vs. operational incidents), different platform.

Third-party risk assessment
Partial

DORA Art. 28-30 govern ICT third-party risks at contract level. The CRA requires product-side due diligence for third-party components and SBOM transparency.

Product-level security requirements
Not covered

DORA is organization-focused. The CRA requires concrete technical security properties in the product itself: security by design, access control, data integrity per Annex I.

Product SBOM
Not covered

DORA has no SBOM obligation. The CRA requires a machine-readable Software Bill of Materials for every product with digital elements.

Product vulnerability handling
Not covered

DORA governs organizational ICT risk management. The CRA requires documented vulnerability handling for each product throughout the entire support period.

CE marking
Not covered

DORA has no product marking. The CRA requires CE marking as a market access prerequisite after successful conformity assessment.

Product technical documentation
Not covered

DORA focuses on ICT governance documentation. The CRA requires comprehensive product-specific technical documentation per Annex VII.

Product support period
Not covered

DORA has no product support obligation. The CRA obliges manufacturers to define a support period and provide free security updates.

01

Complementary Regulatory Approaches

The CRA regulates the supply side (secure products), DORA the demand side in the financial sector (resilient ICT systems). This complementarity is intentional.

  • CRA: Manufacturers must place secure products on the market (security by design, SBOM, vulnerability handling)
  • DORA: Financial institutions must operate ICT systems resiliently (Art. 5-16)
  • Bridge: CRA-compliant products serve as evidence of supply chain security under DORA Art. 28
02

Overlap Area: ICT Third-Party Providers

ICT third-party providers serving financial institutions may be subject to both frameworks: as manufacturers under the CRA and as ICT third-party providers under DORA.

  • CRA obligations: Annex I requirements, SBOM, ENISA reporting (24h)
  • DORA obligations (Art. 28-30): Contractual requirements, audit access rights, incident reporting support, exit strategies
  • Efficiency: CRA documentation (SBOMs, risk assessments) directly usable for DORA contractual requirements
03

Incident Reporting Compared

Both regulations require incident reporting, but with different triggers and addressees. A single incident can trigger both reporting obligations.

  • CRA (Art. 14): Manufacturer reports product vulnerabilities to ENISA — 24h early warning, 72h full notification
  • DORA (Art. 19): Financial entity reports ICT incidents to supervisory authority — initial notification, intermediate report, final report
  • Dual reporting: Manufacturer to ENISA + financial institution to supervisory authority for the same incident
04

Strategic Recommendations

CRA compliance forms the foundation upon which DORA-relevant evidence can be built. The strategy depends on your role.

  • Software manufacturers: CRA compliance as the basis — document SBOM, vulnerability handling, and security by design for DORA due diligence
  • Financial institutions: CRA conformity as procurement criterion — CE marking and SBOM simplify DORA third-party risk management
  • ICT third-party providers: Assess early whether CRA and DORA Art. 31 (critical designation by ESAs) apply

Synergies Between CRA and DORA

CRA and DORA complement each other as complementary regulations — an integrated implementation offers significant efficiency gains.

Documentation as a Bridge

CRA documentation (SBOMs, risk assessments, vulnerability reports) can be directly used for DORA due diligence reviews.

Supply Chain Security

CRA-compliant products facilitate financial institutions' compliance with DORA ICT third-party risk management requirements.

Coordinated Reporting

In the event of security incidents, CRA reporting to ENISA and DORA reporting to supervisory authorities can be triggered in parallel.

Your Next Steps

1High priority

Shift perspective from organization to product

Complement your DORA ICT risk management with product-specific security requirements. Define CRA Annex I requirements for each product.

2High priority

Implement product-level security measures

Implement security by design, access control, and secure default configuration in your software products — not just in your IT infrastructure.

3High priority

Create SBOM

Integrate automated SBOM generation into your development process. SBOM transparency simultaneously supports your DORA third-party evidence.

4Medium priority

Build CRA conformity documentation

Create product-specific technical documentation per CRA Annex VII — security architecture, risk assessment, test reports.

Frequently Asked Questions

Do software vendors serving financial institutions fall under DORA or the CRA?
Potentially under both regulations. As a manufacturer of a product with digital elements, they are subject to the CRA for product security. Simultaneously, they may be subject to contractual requirements from their financial customers under DORA Art. 28–30 as ICT third-party providers. If designated as a critical ICT third-party provider (DORA Art. 31), additional direct supervisory requirements by the ESAs apply.
How does CRA compliance facilitate DORA implementation for financial institutions?
CRA-compliant products provide documented security properties that can be directly used for DORA-relevant evidence: SBOMs enable supply chain transparency (relevant for DORA Art. 28 third-party risk management), the CRA Declaration of Conformity demonstrates security by design, and the manufacturer's ongoing vulnerability handling reduces the ICT risk management burden on the financial institution. The EU Commission confirms this supportive relationship in the CRA FAQ.
What is a critical ICT third-party provider under DORA and how does it differ from the CRA?
DORA Art. 31 empowers the European Supervisory Authorities (ESAs) to designate ICT third-party providers as 'critical' when their failure would have systemic implications for the financial sector. Critical ICT third-party providers are then subject to a direct oversight framework. The CRA has no comparable designation — instead, it distinguishes by product categories (Default, Class I, Class II) per CRA Annex III and IV, which determine the conformity assessment pathway.
Must DORA resilience tests be conducted for all software products used?
DORA Art. 24–27 requires basic and advanced resilience testing for ICT systems of financial entities. For significant financial institutions, Threat-Led Penetration Testing (TLPT) per Art. 26 applies additionally. These tests concern the financial institution's operating environment — not the product in isolation. However, CRA-compliant products with documented security architecture and known vulnerability status significantly facilitate the planning and execution of these tests.
What are the deadlines for incident reporting under CRA and DORA?
The reporting timelines differ: Under the CRA, a manufacturer must report an actively exploited vulnerability within 24 hours as an early warning to ENISA (CRA Art. 14), followed by a full notification within 72 hours. Under DORA, financial entities must report major ICT-related incidents to their supervisory authority following the three-stage process in Art. 19 — the exact deadlines are specified in the ESAs' Regulatory Technical Standards (RTS).
Can a unified risk management framework cover both regulations?
Yes, an integrated approach is recommended. CRA risk management at product level (Annex I, Section 1) and DORA ICT risk management at entity level (Art. 5–16) can be connected in an overarching framework. Key touchpoints include asset management (SBOM integration), vulnerability handling (shared processes for discovery, assessment, and remediation), incident reporting (coordinated reporting chains), and supply chain management (CRA conformity as a DORA procurement criterion).
Which products are exempt from the CRA?
Not all products with digital elements fall under the CRA. Explicitly exempt are: medical devices and in vitro diagnostics (MDR/IVDR), motor vehicles and their type-approval (UN ECE R155/R156), aviation products, products for national security or defense, and certain open-source software not made available in the course of a commercial activity. If your product falls under one of these exemptions, the respective sector-specific cybersecurity requirements apply instead of the CRA.

Further Reading

Official Sources

CRA — Regulation (EU) 2024/2847 Full Text

Official regulation text of the Cyber Resilience Act on EUR-Lex

DORA — Regulation (EU) 2022/2554 Full Text

Official regulation text of the Digital Operational Resilience Act

ESMA — DORA Page

European Securities and Markets Authority overview of DORA, including Regulatory Technical Standards

More on Kunnus

CRA Knowledge Base

Full regulation text and commentary on the CRA

CRA Explained

Overview of the Cyber Resilience Act for decision-makers

Kunnus for Software & SaaS

CRA compliance solution for software and SaaS manufacturers in the financial sector

CRA Compliance Assessment

Free initial assessment of your CRA compliance status

CRA vs. NIS 2 — EU Cybersecurity Strategy

Product security vs. organizational security: The two pillars of EU cybersecurity

CRA vs. ISO 27001 — Standard vs. Regulation

How the voluntary ISO standard and the binding EU regulation complement each other

Unify CRA and DORA Compliance

Kunnus helps software manufacturers in the financial sector efficiently implement CRA requirements — while simultaneously providing DORA-relevant documentation for their financial customers.

Learn more