Cyber Resilience Act vs DORA

In this article ↓

CRA vs DORA in one table
The scope difference
What DORA requires
What the Cyber Resilience Act requires
The overlap for fintechs
Incident reporting: do not merge the clocks
What ICT vendors should prepare
What financial entities should ask vendors
2026 implementation roadmap
Common mistakes
Bottom line
FAQ
Is the Cyber Resilience Act the same as DORA?
Can DORA compliance prove CRA compliance?
Can CRA compliance prove DORA readiness?
When do CRA reporting obligations start?
How should fintechs handle incidents that touch both DORA and CRA?
What should financial entities ask ICT vendors about CRA?
Primary sources

Last reviewed: 29 April 2026

Key takeaways

The Cyber Resilience Act is product cybersecurity law; DORA is operational resilience law for financial entities.
Some fintechs need both: product obligations for digital products and DORA evidence for regulated financial services.
Regulators and partners ask which obligations apply to the entity, product, supplier and service relationship.
Fastest path for an EMI / PI / CASP: separate product scope from regulated-entity scope -> map controls -> keep evidence by obligation.

DORA and the Cyber Resilience Act (CRA) are both EU cyber laws. They are often discussed together.

That is useful at policy level. It can also lead to the wrong implementation plan.

DORA is a financial-sector operational resilience regulation. It applies to financial entities such as payment institutions, electronic money institutions, investment firms, crypto-asset service providers, insurers and other regulated financial firms. It also creates direct oversight for certain critical ICT third-party service providers.

The Cyber Resilience Act is a product cybersecurity regulation. It applies to products with digital elements placed on the EU market, including many software and hardware products. It is aimed mainly at manufacturers, importers and distributors, with obligations across design, development, vulnerability handling, conformity assessment and post-market support.

For EU fintechs and their vendors, the practical question in 2026 is not "which one matters?"

The better question is:

Does the organisation operate a regulated financial service, place a digital product on the EU market, supply ICT services to financial entities, or do several of these at the same time?

CRA vs DORA in one table

Question	DORA	Cyber Resilience Act
Legal instrument	Regulation (EU) 2022/2554	Regulation (EU) 2024/2847
Core purpose	Digital operational resilience of the financial sector	Cybersecurity of products with digital elements
Main regulated party	Financial entities; certain critical ICT third-party service providers	Manufacturers, importers and distributors of products with digital elements
Main object of control	ICT risk management, incident reporting, resilience testing, ICT third-party risk	Secure product design, vulnerability handling, conformity assessment, CE marking
Sector scope	Financial services	Horizontal product market scope across sectors
Main application status in 2026	Applies from 17 January 2025	In force; reporting obligations start 11 September 2026; broad product obligations apply from 11 December 2027
Typical evidence	ICT risk framework, incident process, testing records, Register of Information, supplier oversight	Technical documentation, vulnerability handling process, conformity assessment, security support period, product instructions

The scope difference

DORA starts with the entity: is the organisation a financial entity covered by the regulation, or an ICT third-party service provider subject to contractual requirements or oversight?

The CRA starts with the product: is a product with digital elements made available on the EU market?

This difference matters:

a fintech may be in DORA scope even if it does not sell a standalone digital product;
a software vendor may be in CRA scope even if it is not a regulated financial entity;
a vendor selling software to financial firms may need to support customer DORA evidence and prepare its own CRA product file.

Scenario	DORA relevance	CRA relevance
EU payment institution operating its own platform	Directly in scope as a financial entity	Possible if it places a product with digital elements on the market
SaaS provider selling a fraud monitoring tool to banks	Indirectly relevant through DORA customer contracts and due diligence; potentially direct if classified as critical ICT third-party provider	Likely relevant if the software is a product with digital elements made available on the EU market
Hardware wallet manufacturer	Usually not a DORA financial entity unless it also performs regulated financial services	Likely relevant as a product with digital elements
CASP using cloud infrastructure	Directly relevant where the CASP is a DORA financial entity	Cloud provider may have separate CRA exposure only for relevant products, not because it hosts a DORA customer
Open-source component maintainer	Depends on commercial context and financial-sector use	CRA treatment depends on whether and how the component is supplied commercially as part of a product

What DORA requires

DORA is built around operational resilience. The regulation expects financial entities to manage ICT risk as a board-owned operating capability, not as a one-off security project.

The main DORA workstreams are:

ICT risk management governance and controls
ICT-related incident detection, classification, escalation and reporting
digital operational resilience testing
ICT third-party risk management
information sharing arrangements
contractual control over ICT third-party service providers
Register of Information maintenance

For a fintech SMB, the DORA evidence pack usually has to show who owns ICT risk, how incidents are classified, how critical vendors are monitored, what testing is performed, and how resilience topics reach management.

What the Cyber Resilience Act requires

The CRA is different. It attaches cybersecurity obligations to products with digital elements across their lifecycle.

Manufacturers need to:

design and develop products against essential cybersecurity requirements;
perform a conformity assessment where required;
keep technical documentation;
provide user instructions;
address vulnerabilities;
maintain security support for the expected product lifetime or for a defined support period.

The CRA also introduces reporting obligations for manufacturers for actively exploited vulnerabilities and severe incidents impacting the security of a product with digital elements. The European Commission explains that manufacturers will submit reports through a CRA Single Reporting Platform, with an early warning within 24 hours and a full notification within 72 hours.

The CRA implementation timeline is important:

Date	CRA milestone
10 December 2024	CRA entered into force
11 September 2026	Article 14 reporting obligations for manufacturers start to apply
11 December 2027	Most CRA obligations apply
11 June 2028	Certain existing cybersecurity certificates and approvals remain valid until this date unless they expire earlier or other rules apply

Not sure whether CRA, DORA or both apply?

Use a 15-minute call to separate product-security duties from financial-entity resilience duties - no pitch, just scope.

Book a free 15-min call →

The overlap for fintechs

Most fintech operators should not treat CRA and DORA as duplicate control frameworks. The overlap is narrower and more practical:

Area	DORA asks	CRA asks	Practical overlap
Governance	Board-approved ICT risk framework	Manufacturer responsibilities and product compliance ownership	Name clear owners for resilience, product security and vulnerability handling
Incident reporting	Major ICT-related incident reporting to the competent financial authority under DORA templates and technical standards	Reporting of actively exploited vulnerabilities and severe product security incidents through CRA channels	Maintain separate reporting decision trees; do not force one timeline onto all incidents
Third-party risk	Due diligence, contractual clauses, monitoring and exit planning for ICT providers	Product security obligations for manufacturers and distributors	Ask vendors for product security documentation that supports DORA supplier reviews
Testing	Digital operational resilience testing, including risk-based tests and, for some entities, TLPT	Security testing and conformity evidence for products	Reuse technical findings where possible, but map them to different legal evidence
Documentation	ICT policies, Register of Information, incident records, testing records	Technical documentation, conformity assessment records, vulnerability process	Keep a common evidence inventory with separate legal mappings

Incident reporting: do not merge the clocks

Incident reporting is where teams often make mistakes.

DORA and CRA both contain reporting duties.

They do not use the same:

reporting route;
trigger;
template;
legal owner.

DORA focuses on major ICT-related incidents affecting financial entities. The reporting package is tied to financial supervisory authorities and DORA technical standards. In practice, fintechs need a classification process that can decide whether an ICT incident is major under DORA and then produce the correct staged reports.

CRA focuses on product-security events for manufacturers. In 2026, the relevant planning item is the start of Article 14 reporting obligations on 11 September 2026. Manufacturers should be ready to report qualifying actively exploited vulnerabilities and severe incidents through the CRA reporting route.

Reporting question	DORA	CRA
Who reports?	Financial entity, under DORA incident rules	Manufacturer of a product with digital elements
What is the trigger?	Major ICT-related incident or significant cyber threat where applicable	Actively exploited vulnerability or severe incident impacting product security
Primary route	Competent financial authority / local DORA process	CRA Single Reporting Platform routing to the designated CSIRT and ENISA
Operational risk	Under-reporting because classification is weak	Missing the manufacturer reporting clock because vulnerability intake is not integrated

The safe operating model is to run one internal security intake process, but two legal classification paths.

What ICT vendors should prepare

ICT vendors serving financial entities usually feel DORA through customer contracts, due diligence questionnaires, audit rights, incident notification clauses and exit planning requirements. That is true even if the vendor is not directly regulated as a financial entity.

The CRA adds a second layer for vendors that make software or hardware products available on the EU market. A vendor may need to explain both:

how its service supports a financial customer’s DORA controls; and
how its product meets CRA product-security obligations.

For 2026, vendors should build an evidence set that can serve both conversations:

Evidence item	Helps with DORA customer reviews	Helps with CRA readiness
Secure development lifecycle	Yes, as supplier risk evidence	Yes, as product security evidence
Vulnerability disclosure and triage process	Yes, for incident and vulnerability management	Yes, for CRA vulnerability handling
Support and patching policy	Yes, for resilience and exit planning	Yes, for expected support period and user information
Security testing records	Yes, for due diligence and assurance	Yes, for conformity and technical documentation
Subprocessor and subcontractor map	Yes, for ICT third-party risk	Sometimes, where supply chain affects product security
Incident notification playbook	Yes, for DORA contractual reporting	Yes, where product security reporting is triggered

What financial entities should ask vendors

DORA does not require every fintech to audit every supplier in the same way. Proportionality matters. But where a supplier supports a critical or important function, the evidence should be much stronger than a generic security questionnaire.

For vendors that may also be affected by the CRA, useful questions include:

Vendor question	Why it matters
Is the supplied software or hardware treated as a product with digital elements under CRA?	Establishes whether product-security documentation may exist or be expected
Who owns vulnerability disclosure and coordinated vulnerability handling?	Supports both DORA incident readiness and CRA reporting readiness
What is the security support period for the product or service?	Helps assess lifecycle risk and exit planning
How are severe vulnerabilities communicated to customers?	Reduces the risk of late DORA classification by the financial entity
What technical documentation can be shared under NDA?	Helps avoid unsupported supplier assurance claims
Which subcontractors are essential to the service?	Supports DORA ICT third-party risk mapping

2026 implementation roadmap

For a fintech or fintech vendor, the most useful roadmap is not a separate DORA project and a separate CRA project. The better pattern is a shared evidence model with separate legal mappings.

Quarter	Practical work
Q2 2026	Confirm whether the organisation is a DORA financial entity, an ICT vendor, a CRA manufacturer, or a mixed-case operator
Q2-Q3 2026	Build separate incident classification paths for DORA and CRA; test intake, escalation and reporting ownership
Q3 2026	Prepare for CRA Article 14 reporting obligations where the organisation is a manufacturer
Q3-Q4 2026	Update vendor due diligence packs, contractual notification language and vulnerability disclosure procedures
Q4 2026	Run a tabletop exercise covering a product vulnerability that also affects a financial customer’s critical or important function
2027	Complete CRA conformity and technical documentation work before broad CRA application on 11 December 2027

Common mistakes

The first mistake is treating DORA and CRA as interchangeable cybersecurity laws. They are not. DORA is entity and service-operation focused; CRA is product-market focused.

The second mistake is assuming that DORA compliance proves CRA compliance. A financial entity can have a strong ICT risk framework and still lack CRA-style product documentation if it manufactures a product with digital elements.

The third mistake is assuming that CRA compliance proves DORA readiness. A secure product does not automatically prove that a financial entity has board governance, Register of Information controls, third-party exit plans or DORA incident reporting procedures.

The fourth mistake is using one universal incident reporting timer. DORA and CRA triggers, routes and templates differ. Internal security operations can be unified, but legal classification should stay explicit.

Bottom line

DORA and the Cyber Resilience Act are complementary, but they solve different problems.

DORA asks whether a financial entity can remain operationally resilient under ICT disruption, third-party dependency and supervisory scrutiny.

The CRA asks whether a digital product is secure enough to be placed on the EU market and supported throughout its lifecycle.

For fintechs and ICT vendors, the 2026 priority is to map roles first.

The organisation may be a:

financial entity;
manufacturer;
distributor;
importer;
ICT service provider;
mixed-case operator.

Once that is clear, the work becomes more concrete: separate legal duties, shared technical evidence and no false assumption that one framework automatically satisfies the other.

FAQ

Is the Cyber Resilience Act the same as DORA?

No. DORA is an operational resilience regulation for financial entities. The Cyber Resilience Act is a product-security regulation for products with digital elements placed on the EU market. They may overlap in evidence, but they have different scopes, owners and reporting routes.

Can DORA compliance prove CRA compliance?

No. A financial entity can have strong DORA governance and still lack CRA technical documentation, conformity assessment evidence or product vulnerability handling records if it also acts as a manufacturer of a product with digital elements.

Can CRA compliance prove DORA readiness?

No. CRA product-security evidence does not prove that a financial entity has a DORA ICT risk framework, Register of Information, board reporting, resilience testing, incident classification or ICT third-party exit planning.

When do CRA reporting obligations start?

Article 14 CRA reporting obligations for manufacturers start to apply on 11 September 2026. Most CRA obligations apply from 11 December 2027, so 2026 is the year to prepare reporting intake, ownership and vulnerability-handling evidence.

How should fintechs handle incidents that touch both DORA and CRA?

Use one internal security intake record, but keep two legal classification paths. DORA classification should assess major ICT-related incident reporting for the financial entity, while CRA classification should assess manufacturer reporting for actively exploited vulnerabilities or severe product-security incidents.

What should financial entities ask ICT vendors about CRA?

Ask whether the supplied software or hardware is a product with digital elements, who owns vulnerability disclosure, what the security support period is, how severe vulnerabilities are communicated and what product-security documentation can be shared under NDA.

Cyber Resilience Act vs DORA: 2026 Guide for EU Fintechs and ICT Vendors