EU CRA vs DORA vs NIS2: how the three EU cybersecurity laws compare

If you build software that’s sold or used in Europe, you’re probably already tracking one EU cybersecurity law. The hard question is whether you’re tracking the right one. The EU has three flagship cyber regulations now in force, and I keep seeing them confused, even in compliance documentation written by the affected companies.

This post is a high-level comparison of the EU Cyber Resilience Act (CRA), the Digital Operational Resilience Act (DORA), and the NIS2 Directive. The aim is to make it obvious, at a glance, which one applies to which kind of organisation, what each one requires, and what to do if more than one applies to you (which is increasingly common).

Section 1: What is the EU CRA?

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU’s horizontal cybersecurity regulation for products with digital elements. It entered into force on 10 December 2024 and applies in full from 11 December 2027. A subset of the obligations, vulnerability reporting under Article 14, applies earlier, from 11 September 2026.

What the CRA covers, in one sentence: any hardware or software product that has digital elements, is sold or made available on the EU market, and can be connected to a device or network. That includes operating systems, mobile apps, IoT devices, smart-home appliances, microcontrollers, password managers, web browsers, and most modern industrial equipment. It explicitly does not cover services provided over a network (those land under NIS2) or financial services (DORA).

Core obligations the CRA imposes on manufacturers:

• Essential cybersecurity requirements: products must be designed, developed, and produced to ensure an appropriate level of cybersecurity (Annex I)
• Vulnerability handling process: including a software bill of materials (SBOM), coordinated disclosure policy, and security update mechanism (Article 13)
• Vulnerability and incident reporting: to ENISA and the national CSIRT, on a 24h / 72h / 14-day cadence (Article 14)
• Conformity assessment: self-assessment for default-class products, notified-body involvement for Class I and Class II
• CE marking and Declaration of Conformity: the same legal mechanism used for product safety regulations like the Machinery Directive
• Technical documentation: kept for at least 10 years and made available on request

Penalties for non-compliance go up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

For a deeper introduction, see What is the CRA?.

Section 2: EU CRA vs DORA

DORA is the Digital Operational Resilience Act, Regulation (EU) 2022/2554. It entered into force in January 2023 and has applied in full since 17 January 2025, meaning DORA is already live and being enforced while the CRA is still in its transitional period.

DORA and the CRA are sometimes described as overlapping. They aren’t, really. They’re aimed at completely different layers of the stack. DORA regulates the operational resilience of financial entities: their ability to continue operating despite an ICT failure, cyber-attack, or disruption from a third-party provider. The CRA regulates the products those entities (and everyone else) use.

A bank using a CRA-compliant database product still has to satisfy DORA on top, because DORA is asking about the bank’s incident response, business continuity, and third-party risk management, not about the database’s source code.

Side-by-side: EU CRA vs DORA

Dimension	EU CRA	DORA
Legal instrument	Regulation (directly applicable)	Regulation (directly applicable)
Who it regulates	Manufacturers of products with digital elements	Financial entities + their critical ICT third-party providers
Trigger	Placing a product on the EU market	Being a regulated financial entity (banks, insurers, asset managers, crypto-asset service providers, etc.)
Subject of regulation	Software/hardware products	Operational ICT processes and resilience
Key deliverable	CE marking + Declaration of Conformity + SBOM + tech doc	ICT risk management framework + register of information + resilience testing
Reporting cadence	24h / 72h / 14 days for active vulnerabilities	24h / 72h / 1 month for major ICT-related incidents
Regulator	National market surveillance authorities; ENISA coordinates	Sectoral financial regulators (EBA, EIOPA, ESMA) at EU level; competent national authorities
Penalty ceiling	Up to €15M or 2.5% global turnover	Up to 1% of average daily worldwide turnover, accruing daily
Effective date	11 December 2027 (full); 11 September 2026 (vulnerability reporting)	17 January 2025 (already in force)
Conformity gateway	CE marking	Authorisation by financial regulator (already required)

Where they overlap

The interesting case is the financial entity that also makes a product. A trading platform that sells API access, a fintech that licenses risk-scoring software to other banks, a custody provider whose mobile app is downloaded by retail customers: they may face both regimes. The CRA covers the product they sell; DORA covers their internal operations.

Equally important is the critical ICT third-party provider designation under DORA. If your software product is heavily relied upon by financial entities, the European Supervisory Authorities can designate you as critical. That triggers DORA-style oversight in addition to your CRA obligations as a manufacturer. As of mid-2026 the first designations have been made, and the threshold is materially below most large enterprise software vendors’ assumptions.

In short: the CRA is the floor, DORA is the operational layer above it for finance. If you’re a financial entity, you need both. If you sell software to financial entities, you need CRA today and may face DORA-derived obligations indirectly through your customers.

Section 3: EU CRA vs NIS2

NIS2 is Directive (EU) 2022/2555, formally the second iteration of the Network and Information Security Directive. The transposition deadline was 17 October 2024, by which member states had to translate NIS2 into national law. Most missed it; the European Commission opened infringement proceedings against 23 member states in late 2024. By early 2026 the picture is uneven: NIS2 is in force as national law in some member states, partially implemented in others.

This is the biggest practical difference between NIS2 and the CRA: NIS2 is a directive (it must be transposed into 27 separate national laws), while the CRA is a regulation (it applies directly, the same text in every member state). For a multinational, that means NIS2 obligations vary subtly by country; CRA obligations don’t.

NIS2 regulates essential and important entities. Organisations operating in 18 sectors deemed critical to the economy and society. That includes energy, transport, banking, health, drinking water, digital infrastructure, ICT service management, public administration, postal services, waste management, manufacturing, food production, and digital service providers. The threshold is mostly size-based: medium-sized enterprises (50+ employees, €10M+ turnover) operating in any of these sectors are in scope.

Like DORA, NIS2 is about the entity, not the product. A NIS2-regulated hospital using CRA-regulated medical-device software has to satisfy NIS2 obligations on its operations and its supply chain; the device manufacturer has to satisfy the CRA on the device.

Side-by-side: EU CRA vs NIS2

Dimension	EU CRA	NIS2
Legal instrument	Regulation (directly applicable)	Directive (transposed nationally)
Who it regulates	Manufacturers of products with digital elements	Essential and important entities in 18 sectors
Trigger	Placing a product on the EU market	Being designated essential or important by a member state
Subject of regulation	Software/hardware products	Operations of regulated entities + their supply chain
Key deliverable	CE marking + DoC + SBOM + tech doc	Risk management measures + incident reporting + supply chain security
Reporting cadence	24h / 72h / 14 days for active vulnerabilities	24h early warning / 72h incident notification / 1 month final report
Regulator	National market surveillance authorities; ENISA	Designated competent authorities + national CSIRTs; ENISA coordinates EU-wide
Penalty ceiling	Up to €15M or 2.5% global turnover	Up to €10M or 2% (essential); €7M or 1.4% (important)
Effective date	11 December 2027 (full); 11 September 2026 (vulnerability reporting)	Transposition deadline 17 October 2024, varies by member state
Compliance gateway	CE marking	Registration with national authority + management body accountability

Where they overlap

Three real-world overlaps:

Supply chain transitivity. NIS2 explicitly requires regulated entities to manage cybersecurity risks in their supply chain (Article 21). In practice, that means NIS2-regulated entities are starting to demand CRA-style evidence (SBOMs, vulnerability handling policies, secure development claims) from their software vendors now, before the CRA itself is in force. The CRA effectively becomes a procurement baseline well before its 2027 effective date because NIS2 customers ask for it.

Reporting for software vendors that are themselves NIS2-regulated. A managed cloud provider, an ICT service management firm, or a digital infrastructure operator can be a NIS2 essential/important entity and a CRA manufacturer simultaneously. Same vulnerability, different reporting obligations to overlapping authorities. Coordinating those filings is non-trivial; ENISA’s Single Reporting Platform is meant to help, but only for the CRA side.

Definitional drift. “Significant cybersecurity incident” under NIS2 and “actively exploited vulnerability” under the CRA aren’t the same thing, and getting the threshold wrong means filing too much (regulator fatigue) or too little (penalties). Most legal teams now produce a single internal classification policy that maps both.

Section 4: Summary, which regime applies to me?

Use this rough decision flow:

1. Do you make or distribute software or hardware products in the EU market? → CRA applies.
2. Are you a regulated financial entity, or do financial entities depend critically on your services? → DORA applies (and CRA may also apply to your products).
3. Are you medium-sized or larger and operating in one of the 18 NIS2 sectors? → NIS2 (transposed in your member state) applies.
4. None of the above? → You’re probably outside the scope of all three, but check your product against the CRA’s product-with-digital-elements definition. The bar is low.

Many organisations sit in two or three of these categories. The good news is that the underlying security disciplines (risk management, vulnerability handling, incident response, supply chain transparency) overlap heavily across all three regimes. A mature programme satisfies all of them; the differences are in what you have to file, to whom, and on what schedule.

One-line summary of each

Law	One-line summary
EU CRA	Cybersecurity rules for the products you sell
DORA	Operational resilience rules for the financial sector
NIS2	Cybersecurity rules for operators of essential and important services

If you’re new to the CRA specifically, start here. If you’ve already mapped your CRA scope and need the practical artefacts, the SBOM tutorial and the compliance guide are the next steps. For deadlines across all three regimes, the deadlines tracker is updated as ENISA and the European Commission publish new guidance.