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

Source: https://www.cyadviso.com/cyber-resilience-act-and-dora
Last reviewed: 2026-04-29
Tags: DORA, CRA

Cyber Resilience Act vs DORA in 2026: how product cybersecurity, financial operational resilience, vulnerability reporting and ICT vendor duties fit together.

---

**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 |

## 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.

## Primary sources

- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [Regulation (EU) 2024/2847 — Cyber Resilience Act, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [EBA — Guidelines on ICT and security risk management](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-ict-and-security-risk-management)
- [European Commission — Cyber Resilience Act summary](https://digital-strategy.ec.europa.eu/en/policies/cra-summary)
- [European Commission — Cyber Resilience Act reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)
- [ENISA — CRA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/cyber-resilience-act-and-dora