A question is circulating through corporate legal and security teams as the CRA's reporting duties draw closer: if we report a breach under NIS2, are we covered under the Cyber Resilience Act too? The European Commission's answer is no, and the reason is worth getting right before the first real incident forces the point. NIS2 and the CRA both run a 24-hour clock and a 72-hour clock off the same starting gun. They are still two different duties, owed by two different parties, to two different places.
Picture an industrial gateway inside a water-treatment plant, hit by an attacker exploiting a firmware flaw. That one event can start both clocks at once. The plant operator, as an essential entity, owes a report under NIS2 Article 23 because its service is significantly disrupted. The gateway's manufacturer owes a separate report under CRA Article 14 because a vulnerability in its product is being actively exploited. Same intrusion, two obligations that do not know about each other.
Which clock is which
The two regimes rhyme on cadence and diverge on everything that determines who files and where. Read the duty-holder row first: that is where the "one filing covers both" idea falls apart.
| CRA — Article 14 | NIS2 — Article 23 | |
|---|---|---|
| Duty-holder | The manufacturer of the product with digital elements | The essential or important entity operating the service |
| What triggers it | An actively exploited vulnerability, or a severe incident affecting the product's security | A significant incident affecting the service the entity provides |
| Where it goes | The coordinating CSIRT and ENISA, via the single reporting platform (Article 16) | The entity's own national CSIRT or competent authority |
| Cadence | 24h early warning → 72h notification → final report | 24h early warning → 72h notification → final report within one month |
The cadences look like twins. They are not measuring the same thing. NIS2 is asking an operator to account for disruption to a service the public relies on. The CRA is asking a producer to account for a weakness in a product it placed on the market. One protects the running of critical operations; the other protects the security of the things those operations are built from.
The destinations pull apart in the same way. NIS2 keeps the operator with its own national CSIRT or competent authority, the body that already supervises it. The CRA routes the manufacturer's notification into a single reporting platform that ENISA operates under Article 16, feeding the coordinating CSIRT and ENISA together. Two reports can describe the identical intrusion and never land in the same place. And the resemblance thins further past the 72-hour mark: the final-report clocks are not even the same length, since the CRA's vulnerability track runs its final report on a different deadline from the incident track and from NIS2's one-month deadline. The full drill on the CRA's own clock, including what belongs in each submission, lives in the 24-hour early-warning walkthrough.
Why one filing does not discharge both
The trap is assuming that a single well-written report, sent to a single authority, satisfies whatever else might be watching. It does not, and the gap widens for exactly the firms most exposed: those that both build connected kit and operate with it.
If your company manufactures that gateway and also runs a regulated plant, a single attack makes you the CRA duty-holder and the NIS2 duty-holder simultaneously. Two hats, one legal person, two filings owed to two destinations on two independent triggers. Sending the operational report to your national authority under NIS2 leaves the product-side duty to the coordinating CSIRT and ENISA completely unmet, and vice versa. Neither regulator is looking at the other's inbox.
There is a third recipient the org chart tends to forget entirely: the users. The CRA obliges the manufacturer to inform the product's affected users of the exploited vulnerability and any mitigations they can apply, a communication that runs alongside the regulator filing rather than instead of it. A firm wearing both hats therefore has to move on three fronts from one event, and the triage question is not "who do we call" but "which of these duties has this specific event triggered, and on whose clock." Answer that wrong under time pressure and the missed filing is discovered later, by the regulator, from the other regulator's records.
That is the gap to design against now, while the deadline is still ahead of you rather than behind. The forensic facts underneath both reports are the same facts: what happened, when you knew, which units were affected, what you are doing about it. So build one incident pipeline that captures that evidence once and can emit both filings, addressed correctly, on their own clocks. You can model your own dual-duty position in the conformity workspace, and the product-security half is grounded in the statute. For the fuller picture of where the CRA, NIS2, and the AI Act overlap on a single machine, the tri-directive evidence map traces exactly where the evidence reuses and where the borders stay hard.
The instinct to consolidate is right; the shortcut is not. Align the pipeline so one investigation feeds two reports. Do not file once and call it covered, because the two clocks are counting for two different regulators who will each notice the silence on their own line.