CRA vs NIS2: products versus organisations, and how the reporting duties fit together
NIS2 (Directive (EU) 2022/2555) imposes risk-management and incident-reporting duties on organisations in critical sectors; the Cyber Resilience Act (Regulation (EU) 2024/2847) imposes security, vulnerability-handling and reporting duties on products placed on the EU market. A manufacturer can be subject to both, and the two reporting regimes run on similar clocks to different recipients.
By the Vellaci teamPublished Updated 4 min readOperational guidance, not legal advice
Key facts
- NIS2 regulates
- Entities (organisations) in Annex I and II sectors — their systems and services
- CRA regulates
- Products with digital elements — their design, vulnerability handling and reporting
- NIS2 reporting
- Significant incidents: early warning 24 h, notification 72 h, final report 1 month (Art. 23)
- CRA reporting
- Exploited vulnerabilities and severe product incidents: early warning 24 h, notification 72 h, final report 14 days after fix / 1 month (Art. 14)
- Recipients
- NIS2: national CSIRT or competent authority · CRA: coordinator CSIRT + ENISA via the single reporting platform
- Application
- NIS2: transposed by 17 October 2024 · CRA: reporting 11 Sep 2026, full 11 Dec 2027
Different objects of regulation
NIS2 asks whether your organisation is an essential or important entity — a manufacturer of computers, electronics, machinery or vehicles above the size thresholds often is — and then regulates how you secure your own network and information systems and report incidents affecting your services. The CRA asks whether you place products with digital elements on the market and regulates the products: secure design, an SBOM, vulnerability handling, a support period, conformity assessment, and reporting of exploited vulnerabilities and severe incidents in the product. The same breach of a build server can be a NIS2 incident (your systems) and, if it led to a tampered release, a CRA severe incident (your product).
Reporting compared
| NIS2 Article 23 | CRA Article 14 | |
|---|---|---|
| Trigger | Significant incident affecting the entity's services | Actively exploited vulnerability in the product; severe incident impacting the product's security |
| Early warning | Within 24 h: whether caused by unlawful or malicious acts, cross-border impact | Within 24 h: existence of the event, Member States concerned, (incidents) whether malicious acts suspected |
| Notification | Within 72 h: update, initial assessment of severity and impact, indicators of compromise | Within 72 h: product information, nature of the event, initial assessment, measures taken and available to users |
| Intermediate | On request of the CSIRT/authority | On request of the CSIRT |
| Final report | Within 1 month of the notification | Vulnerability: 14 days after a corrective measure · Incident: 1 month after the notification |
| Recipient | National CSIRT or competent authority | Coordinator CSIRT and ENISA via the single reporting platform |
| Users / recipients of services | Inform recipients where appropriate; notify of cyber threats | Inform impacted users without undue delay (Art. 14(8)) |
One runbook, two channels
- Use one awareness discipline: the same named person confirms awareness, with one timestamp, for both regimes.
- Classify the event on two axes: does it affect our services (NIS2) and does it affect our product's security (CRA)? Both can be true.
- Keep two submission records with their own references, but one fact base — product, versions, indicators, measures.
- Align internal thresholds: NIS2's 'significant' and CRA's 'severe' are different tests; document each decision separately.
- Rehearse a combined scenario: compromised update infrastructure is the canonical case that triggers both.
Who is in scope of what
| Situation | NIS2 | CRA |
|---|---|---|
| Medium-sized manufacturer of industrial controllers sold in the EU | Likely an important entity (manufacturing of electrical equipment / machinery, Annex II) if above the size threshold | Manufacturer of products with digital elements — full obligations |
| Small software vendor (under 50 staff, under €10 m turnover) selling a SaaS-connected device | Usually out of scope (size threshold), unless a Member State designates it | In scope for the device and its remote data processing |
| Cloud service provider | Essential entity (digital infrastructure) | Out of scope for the service itself; in scope for any product it places on the market |
| Open-source foundation | Out of scope | Possibly an open-source software steward (Art. 24) — light-touch regime |
| Distributor reselling devices | Depends on sector and size | Distributor obligations only (Art. 20) |
Obligations compared beyond reporting
NIS2 Article 21 requires risk-management measures at organisation level: policies on risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and development, vulnerability handling and disclosure, cryptography, HR security, access control, asset management and MFA. The CRA's Annex I requires product-level properties and processes. The overlap is real — a secure development lifecycle, a CVD process and asset inventories serve both — but the evidence is different: NIS2 auditors look at your ISMS; CRA authorities look at the product's technical documentation, SBOM and update history.
Where they reinforce each other
NIS2 requires supply-chain security measures, including the security of products and services procured; buyers subject to NIS2 will increasingly ask suppliers for SBOMs, VEX statements, CVD policies and support periods — exactly the artefacts the CRA requires manufacturers to have. A manufacturer that runs CRA vulnerability handling well answers NIS2 customer questionnaires with evidence rather than prose.
Frequently asked questions
- We are not a NIS2 entity. Does the CRA still apply?
- Yes, if you place products with digital elements on the EU market. NIS2 status is irrelevant to CRA scope.
- Do we report the same incident twice?
- If it meets both tests, yes — to different recipients with different content. The single reporting platform for the CRA is not the NIS2 channel.
- Does a NIS2 final report satisfy the CRA final report?
- No. The CRA final report has product-specific content and, for vulnerabilities, a different trigger. Reuse the facts, not the document.