NIS2 and CRA: what overlaps, what doesn't, and how to manage both

The short answer

NIS2 and CRA share six core security obligations. If you are an essential or important entity under NIS2 and you also manufacture products with digital elements, you can build one compliance programme that satisfies both — but the two regulations have different scopes, timelines and enforcement bodies, so they cannot be collapsed into a single audit.

Who this applies to

You are dual-regulated if you meet both of these conditions:

A medical device manufacturer selling a connected product to EU hospitals is a typical dual-regulated entity. So is a cloud service provider that also ships embedded software in networking equipment.

• NIS2 scope — You operate a service in an essential or important sector (energy, transport, banking, health, digital infrastructure, ICT service management, etc.) as defined in Annex I and II of Directive 2022/2555.
• CRA scope — You place a product with digital elements on the EU market (hardware or software with network connectivity, either directly or indirectly).

The 6 shared obligations

| Obligation | NIS2 reference | CRA reference |

|---|---|---|

| Vulnerability handling policy (CVD) | Art. 21(2)(e) | Annex I Part II §1 + Art. 14 |

| Security incident response process | Art. 21(2)(c) | Annex I Part I §2(8) |

| Software Bill of Materials (SBOM) | Art. 21(2)(e) — implied | Annex I Part II §1 |

| Supply chain security assessment | Art. 21(2)(d) | Annex I Part I §2(3) |

| Access control and authentication | Art. 21(2)(i) | Annex I Part I §2(2) |

| Cryptography and encryption policy | Art. 21(2)(h) | Annex I Part I §2(4) |

For these six areas, a single policy document, a single evidence artefact, and a single gap assessment can satisfy both regulations — provided both regulatory frameworks are mapped in the assessment.

Where they diverge

| Dimension | NIS2 | CRA |

|---|---|---|

| Subject | Entities (organisations) | Products (hardware/software) |

| Enforcement | National competent authority (NCA) per Member State | Market surveillance authority (MSA) |

| Incident notification | NCA + CSIRT within 24h/72h/1 month | ENISA within 24h/72h/14 days (Art. 14) |

| Key deadline | In force since October 2024 (transposition deadline) | Art. 14 from 11 September 2026; full obligations from December 2027 |

| Penalty regime | Up to €10M or 2% global turnover (essential entities) | Up to €15M or 2.5% global turnover |

| Certification path | ENISA EUCS for cloud; sector-specific schemes | CE marking via self-assessment or third-party audit (risk class dependent) |

The one-SBOM approach

The most efficient dual-compliance approach is to treat the SBOM as the shared evidence anchor:

A single SBOM — maintained, signed, and updated on each release — satisfies the primary evidence requirement for both regulations.

• Generate one machine-readable SBOM (SPDX 2.3+ or CycloneDX 1.5+) per product release.
• Map SBOM to CRA Annex I Part II §1 for the product obligation.
• Reference the same SBOM in your NIS2 supply chain security documentation under Art. 21(2)(d).
• Version-control the SBOM so both regulatory frameworks have a dated, auditable artefact.

CVD policy: one document, two regulatory references

Your coordinated vulnerability disclosure (CVD) policy must cover:

Under CRA Art. 14, this policy must be operational by 11 September 2026. Under NIS2 Art. 21, it is required now (in force since October 2024).

One policy document, referencing both obligations, is sufficient. Do not maintain two separate CVD policies.

• A public disclosure channel (email or web form)
• An acknowledgement timeline (typically 5 business days)
• A triage and patch timeline
• A responsible disclosure timeline (typically 90 days before public disclosure)

Incident notification: two parallel workflows

This is the main area where dual-regulated entities must run two separate notification workflows, because the recipients differ:

| Step | NIS2 | CRA (Art. 14) |

|---|---|---|

| 24h early warning | National CSIRT | ENISA via national authority |

| 72h incident report | National CSIRT + NCA | ENISA (intermediate report) |

| Final report | 1 month — NCA | 14 days — ENISA |

Your incident response runbook must include both notification tracks. The triggering conditions are also different: NIS2 covers significant incidents affecting service continuity; CRA Art. 14 covers actively exploited vulnerabilities in your product.

Common mistakes in dual-compliance programmes

1. Treating NIS2 and CRA as the same obligation.

They share obligations but have different scope, enforcement bodies, and timelines. Mapping one without the other creates gaps at audit.

2. Building two separate compliance programmes.

Duplicating artefacts (two SBOMs, two CVD policies, two gap assessments) creates version drift and maintenance overhead. One programme, dual-mapped.

3. Missing the CRA Art. 14 deadline (11 September 2026).

Many dual-regulated entities focus on NIS2 (already in force) and treat CRA as a 2027 problem. Article 14 vulnerability reporting is a 2026 deadline.

4. Incorrect scope assessment.

NIS2 scope is determined by sector + size thresholds. CRA scope is determined by product characteristics. Both must be independently assessed — you cannot infer CRA applicability from NIS2 applicability or vice versa.

Tools available on NexCyber

• NIS2 Applicability Checker — confirm NIS2 scope in 2 minutes
• CRA Scope Checker — confirm CRA applicability and risk class
• 144-obligation gap assessment — maps CRA, NIS2, DORA, AI Act and RED in one assessment (account required)

Further reading

This page provides regulatory guidance for informational purposes. It is not legal advice. For compliance decisions, consult the applicable national competent authority or a qualified legal adviser.

NexCyber — EU Market Access Compliance Platform

• CRA Article 14 — vulnerability reporting workflow
• SBOM requirements under CRA Annex I
• NIS2 Directive — obligations overview