Skip to content
CRA Reporting Desk

CRA Article 14 vs NIS2 incident reporting: do you file twice?

If your incident response process already has a NIS2 clock built in, the CRA's 24-hour/72-hour/final-report cascade can look like a duplicate of something you already do. It isn't. CRA Article 14 and NIS2 Article 23 are separate reporting regimes with separate triggers, separate recipients, and no provision that lets a filing under one satisfy the other. Here's exactly where the two actually diverge, and what that means when a single incident could trigger both.

The short version

  • No substitution mechanism. Nothing in Article 14 treats a NIS2 report as meeting a CRA duty, or the reverse — they're independent obligations even when triggered by the same event.
  • Same clock shape, different clocks. Both use a 24h / 72h / final-report cascade, but each runs from its own "becoming aware" trigger and carries its own content requirements.
  • Different recipients. CRA Article 14 goes to your coordinating CSIRT and ENISA via the Single Reporting Platform. NIS2 goes to your national CSIRT or competent authority via your Member State's own channel.
  • Different scope logic. CRA Article 14 is product-centric and sector-agnostic; NIS2 is entity-centric and sector-specific (Annexes I and II). Being in scope for one doesn't put you in scope for the other.
  • In scope for both? Run both clocks, file to both recipients, and don't assume one closes out the other without confirming with counsel.
Track your Article 14 clockCheck your Article 14 deadlines

There's no CRA provision that lets a NIS2 filing stand in

Article 14's substantive paragraphs (1 through 8) don't reference NIS2 or treat any other Union reporting regime as an alternative route. The only NIS2 references in Article 14 are in the delegated- and implementing-act paragraphs (9 and 10), which require the Commission to cooperate with the CSIRTs network set up under NIS2 when it writes the technical rules — that's institutional cooperation between regulators, not a rule that lets your NIS2 filing double as your CRA filing. Treat the two as separate until you have specific guidance saying otherwise.

The clocks share a shape, not a trigger

NIS2 Article 23 runs an early warning within 24 hours of becoming aware of a significant incident, a fuller notification around 72 hours, and a final report roughly a month later. CRA Article 14 runs the same three-stage cascade for actively exploited vulnerabilities and severe incidents tied to a product you manufacture. The resemblance is almost certainly why teams assume one process covers both — but "becoming aware" is defined against each regime's own trigger (a significant incident affecting your operations, versus an actively exploited vulnerability or severe incident affecting a product), so the same real-world event can start one clock, both clocks, or neither, depending on what it actually hit.

Two different front doors

A CRA Article 14 notification goes to your coordinating CSIRT and to ENISA, through the CRA Single Reporting Platform — see which CSIRT applies and the SRP registration process. A NIS2 notification goes to your national CSIRT or competent authority through your own Member State's NIS2 reporting channel, which in most Member States is a different system run by a different authority. Submitting through one platform does not place your report in front of the other regime's recipient, even if the content overlaps.

Who's actually in scope for each

CRA Article 14 catches manufacturers of products with digital elements placed on the EU market — broad, sector-agnostic coverage built around the product, not your industry. NIS2 scope runs the other way: Annexes I and II list essential and important entities by sector — energy, transport, banking, health, digital infrastructure, specific manufacturing categories — not "any manufacturer of a connected product." A software company with no sector-specific NIS2 exposure can still have a full Article 14 duty for its products. A NIS2-in-scope hospital or utility has no CRA duty unless it's also manufacturing a qualifying product with digital elements. Standalone SaaS often sits in NIS2 as a cloud computing service while sitting outside the CRA product definition — unless the backend is remote data processing for a product you ship; see Article 14 for SaaS and remote data processing. Check your own sector against the current NIS2 annexes directly rather than assuming either regime's scope mirrors the other's.

If you're in scope for both

Run both clocks from the moment you become aware, measured against each regime's own trigger test, and file to each regime's own recipient. Don't let a NIS2 submission stand in for your Article 14 report, or the reverse, without specific confirmation that's allowed — we didn't find a rule that says it is. What you can share across both processes is your internal timeline: what you knew, when you knew it, and what you did next. The evidence log is built to capture exactly that, and it's the same underlying timeline both clocks are measured against, even though the filings themselves stay separate. If personal data was also breached, add GDPR Article 33 as a third track — see CRA Article 14 vs GDPR breach notification.

Questions people ask

Does filing a NIS2 incident report also satisfy my CRA Article 14 duty?
No. Article 14's eight substantive paragraphs don't name NIS2 or any other Union act as an alternative route, and nothing in the Regulation treats a NIS2 notification as meeting an Article 14 duty. They're separate obligations to separate recipients, even when they're triggered by the same underlying event. Don't assume one filing closes out the other without checking with counsel.
Why do the two clocks look identical — 24 hours, 72 hours, and a final report?
NIS2 Article 23 uses the same cascade shape (early warning, then a fuller notification, then a final report) for significant incidents at the entity level. CRA Article 14 reuses that shape for actively exploited vulnerabilities and severe incidents at the product level. The timing structure looks the same because it was clearly modeled on it — but "becoming aware," the content required at each stage, and the recipient are defined separately in each instrument. Matching shapes isn't the same as matching clocks; track each one against its own trigger event.
Who actually receives each report?
CRA Article 14 reports go to your coordinating CSIRT and ENISA, through the CRA Single Reporting Platform. NIS2 Article 23 reports go to your national CSIRT or competent authority, through whatever national reporting channel your Member State has set up for NIS2 — a different portal, in a different system, run by a different authority in most Member States. Filing on one platform does not put your report in front of the other's recipient.
What actually triggers each one?
CRA Article 14 is product-centric: an actively exploited vulnerability in a product with digital elements you manufacture, or a severe incident with impact on that product's security. NIS2 Article 23 is entity-centric: a "significant incident" affecting your own network and information systems, judged by criteria like severe operational disruption, financial loss, or considerable damage to others. The same root cause — a breach, an exploited flaw — can trip both tests at once if it hits both a product you make and your own operations, or trip only one if it's purely product-side with no operational impact on you, or vice versa.
Does NIS2 even apply to us if we're a software or connected-product manufacturer?
Not automatically. NIS2 scope runs by sector — Annexes I and II list essential and important entities such as energy, transport, banking, health, digital infrastructure, and specific categories of manufacturing, not "manufacturers of products with digital elements" as a class. CRA Article 14 scope is much broader and catches most manufacturers placing connected products on the EU market regardless of sector. Plenty of CRA-in-scope manufacturers have no NIS2 exposure at all, and plenty of NIS2-in-scope entities (a hospital, a utility) have no CRA exposure unless they also manufacture a qualifying product. Check your own sector against the current NIS2 annexes rather than assuming either regime implies the other.
We're in scope for both — what should our process actually do?
Run both clocks from the moment you become aware, against each regime's own trigger test, and file to each regime's own recipient — don't let one submission stand in for the other unless you have specific written confirmation it does. Keep a single internal timeline of what you knew and when (see the evidence log), since "awareness" timing is what both clocks actually run from, even though the two reports themselves are separate filings.

Track your Article 14 clock

NIS2 doesn't replace the CRA chain. Use the free desk to track the 24-hour, 72-hour and final report deadlines for a product case, or check a single case on the calculator. No sign-up; your data stays in your browser. Official CRA filing still goes through ENISA's Single Reporting Platform.

Track your Article 14 clockCheck your Article 14 deadlines

Workflow support, not legal advice. Whether a given incident triggers a CRA Article 14 duty, a NIS2 Article 23 duty, both, or neither — and whether any filing under one regime could ever be read as satisfying the other in your specific case — is a legal and factual determination for qualified counsel. NIS2 references above are drawn from cross-checked secondary sources summarizing Directive (EU) 2022/2555, not a direct fetch of the Directive text; EUR-Lex direct fetch was unavailable at draft time for both instruments. Confirm against the Official Journal texts (CRA on EUR-Lex; NIS2 on EUR-Lex) before relying on this for a live case.