One Incident, Two Reporting Channels: CRA and NIS2 Since 11 September 2026
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act. Anyone also in scope of NIS2 now serves two reporting duties with their own triggers, deadlines and channels.
Article 14 of the Cyber Resilience Act has applied since 11 September 2026. Manufacturers of products with digital elements must now report actively exploited vulnerabilities and severe security incidents. The rest of the regulation only applies from 11 December 2027, so the reporting duty comes more than a year early. It expressly covers products placed on the market before that date as well.
For many companies this is not their first reporting duty. Essential and important entities under the German NIS2 Implementation Act have been reporting significant incidents to the BSI since December 2025. A company that sells software as a product and is itself a NIS2 entity now carries two duties that look alike but do not overlap.
What the CRA requires
Reports go through the Single Reporting Platform that ENISA put into operation on 11 September. A single submission reaches both the CSIRT designated as coordinator and ENISA. For Germany, according to the BSI, that is CERT-Bund within the BSI. No prior registration is required.
The deadlines are staged:
- Early warning: without undue delay, and at the latest 24 hours after the manufacturer becomes aware.
- Notification: at the latest after 72 hours, with initial information on the nature, impact and corrective measures.
- Final report: for actively exploited vulnerabilities, no later than 14 days after a corrective or mitigating measure is available; for severe incidents, within one month of the notification.
There is also a duty that often gets lost in the discussion: under Article 14(8), the manufacturer informs affected users about the vulnerability or incident and about available mitigations. The regulation’s penalty provisions only apply once it is fully applicable from December 2027. The duty itself, however, applies today.
Why one report does not replace the other
The CRA and NIS2 differ in their subject. The CRA attaches to the product: a vulnerability counts as actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. That can happen at a customer without the manufacturer’s own infrastructure being affected. NIS2 attaches to the entity: under Section 2 no. 11 of the German BSI Act, an incident is significant if it causes or can cause severe operational disruption or financial loss, or considerable damage to others.
This leads to three situations. An exploited flaw in a shipped product must be reported under the CRA, but not necessarily under NIS2. An outage of your own operations must be reported under NIS2, but does not necessarily involve a product. And an attack on your own environment through a product vulnerability can trigger both, with two reports through two channels: the BSI portal for NIS2 and the ENISA platform for the CRA. In Germany both end up at the BSI, but not in the same case file.
One picture, two assessments
Two reporting channels are manageable; two versions of events are not. Keeping a separate timeline for each duty will sooner or later produce contradictory timestamps. What works is a shared incident register with one timeline and two separate checks: is a product affected and is there active exploitation? Are operations significantly disrupted or has a third party suffered considerable harm?
Three points decide whether this holds up in a real incident. First, a clearly defined moment of awareness, because both 24-hour deadlines depend on it. Second, a named function that owns both assessments and is not appointed only once the incident is under way. Third, templates for both channels, so the early warning does not fail over formalities.
The timeline almost always starts with an observation: an outage, an expired certificate, a suspicious change to DNS or headers. Perstat, our product for monitoring and security posture, records such events with timestamps and thereby provides the start of that timeline. Whether and where a report is required remains the company’s decision.
Two reporting duties do not call for two organisations. They call for one timeline that stands up to both.