IN SHORT
The three texts regulate different things. The Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity rules for products with digital elements placed on the EU market and puts obligations on manufacturers, importers and distributors. NIS2 (Directive (EU) 2022/2555) requires Member States to impose cybersecurity risk-management and incident-reporting obligations on essential and important entities in listed sectors. DORA (Regulation (EU) 2022/2554) sets uniform digital operational resilience requirements for financial entities. The CRA itself says it helps entities under NIS2 and DORA meet their supply chain obligations (Recital 125).
At a glance
| CRA | NIS2 | DORA | |
|---|---|---|---|
| Legal form | Regulation — directly applicable | Directive — applies through national transposition | Regulation — directly applicable |
| What it regulates | Products with digital elements made available on the market (Article 2(1)) | Entities of the types in its Annexes I and II (NIS2, Art. 1(2)(b)) | Network and information systems supporting the business processes of financial entities (DORA, Art. 1(1)) |
| Who has obligations | Manufacturers, authorised representatives, importers, distributors, open-source software stewards | Essential and important entities (NIS2, Art. 3) | Financial entities listed in DORA Art. 2(1)(a)–(t); ICT third-party service providers are also listed in its scope (Art. 2(1)(u)) |
| Core obligations | Essential cybersecurity requirements for the product and vulnerability handling (Annex I), conformity assessment, CE marking | Cybersecurity risk-management measures (NIS2, Art. 21) and reporting of significant incidents (Art. 23) | ICT risk management, major ICT-related incident reporting, resilience testing, ICT third-party risk management (DORA, Art. 1(1)) |
| Dates | Applies from 11 December 2027; Article 14 from 11 September 2026; Chapter IV from 11 June 2026 (Article 71(2)) | Member States had to adopt measures by 17 October 2024 and apply them from 18 October 2024 (NIS2, Art. 41) | Applies from 17 January 2025 (DORA, Art. 64) |
Incident and vulnerability reporting compared
The three texts contain reporting duties that look similar but are triggered by different events and addressed to different recipients.
What the text requires
CRA: a manufacturer notifies actively exploited vulnerabilities in its product and severe incidents having an impact on the security of the product simultaneously to the CSIRT designated as coordinator and to ENISA, via a single reporting platform: early warning within 24 hours, then a notification within 72 hours, then a final report (14 days after a corrective measure for vulnerabilities; one month after the incident notification for incidents) (Article 14(2), Article 14(4)).
NIS2 (Directive (EU) 2022/2555, Article 23): Member States ensure that essential and important entities notify their CSIRT or competent authority of significant incidents affecting the provision of their services — an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report not later than one month after the incident notification.
DORA (Regulation (EU) 2022/2554, Article 19): financial entities report major ICT-related incidents to their competent authority. The time limits for the initial notification and reports are determined by regulatory technical standards developed under DORA Article 20, not set in Article 19 itself.
Our interpretation
In our reading, one event can trigger several duties. If a software vendor discovers that attackers are exploiting a flaw in its product, it reports under the CRA as manufacturer. A bank using that product and suffering a major incident reports under DORA; a hospital in the same situation may report under the national law transposing NIS2. The CRA defines "incident" and "CSIRT designated as coordinator" by reference to NIS2 (Article 3, point (43), Article 3, point (51)), which keeps the vocabulary aligned, but the duties remain distinct.
How the CRA describes its relationship with NIS2 and DORA
The CRA's recitals explain the intended complementarity:
- NIS2 entities may require the products they use to meet stricter requirements than the CRA as part of their supply chain security measures, and Member States can impose such additional requirements under NIS2 (Recital 13).
- The CRA aims to facilitate compliance of digital infrastructure providers with the supply chain requirements of NIS2 by ensuring that the products they use are developed securely and receive timely security updates (Recital 24).
- The CRA
will facilitate the compliance with supply chain security obligations of entities that fall within the scope of Regulation (EU) 2022/2554 and Directive (EU) 2022/2555 that use products with digital elements Recital 125
. - For cloud computing services such as SaaS, PaaS and IaaS, recital 12 points to NIS2 rather than the CRA, unless the cloud solution is the remote data processing solution of a product (Recital 12).
On the NIS2/DORA side, the official texts provide that, for financial entities identified as essential or important entities under national rules transposing NIS2, DORA is considered a sector-specific Union legal act for the purposes of Article 4 of NIS2 (DORA, Article 1(2)). Under NIS2 Article 4, where sector-specific acts require equivalent risk-management or notification measures, the corresponding NIS2 provisions do not apply to those entities.
Supply chain: where the texts meet
NIS2 requires entities' risk-management measures to include, among others, supply chain security and security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure (Directive (EU) 2022/2555, Article 21(2)(d) and (e)). DORA requires financial entities to manage ICT third-party risk as an integral component of ICT risk and states that they remain fully responsible for compliance when they use ICT services (Regulation (EU) 2022/2554, Article 28(1)).
The CRA works upstream of those duties: it makes the products themselves subject to security requirements, a support period and vulnerability handling before they reach those entities.
Fictional example — Two companies, three texts
Orbit Payments (fictional) is a payment institution in the EU. It uses a firewall appliance from Basalt Networks (fictional manufacturer).
- Basalt Networks is the manufacturer under the CRA: the firewall is listed in class II of Annex III, so a third-party conformity assessment procedure applies, and Basalt must report actively exploited vulnerabilities under Article 14.
- Orbit Payments is a financial entity under DORA: it manages its ICT risk, including the risk linked to its ICT providers, and reports major ICT-related incidents to its competent authority.
- Depending on national rules, NIS2 provisions on risk management and reporting may not apply to Orbit Payments because DORA is the sector-specific act — a point Orbit should check against its national law.
Uncertain / awaiting guidance
This page does not describe national transpositions of NIS2, which differ between Member States, nor the DORA technical standards on reporting deadlines. Check the national law that applies to your organisation and the published DORA technical standards before relying on a specific deadline.
Good practice (recommendation, not a legal requirement)
If your organisation is both a product manufacturer and an entity under NIS2 or DORA, map each reporting duty separately — trigger, recipient, deadline, content — and design one internal escalation process that feeds all of them. This is a practical suggestion, not a legal requirement.
What to do next
Identify which roles your organisation holds — manufacturer under the CRA, essential or important entity under NIS2, financial entity under DORA — and read the reporting provisions that apply to each role.