CRA Article 14: The 24-Hour Reporting Clock Meets IR Reality
12.09.2026 crameldepflichtincident-responsenis2
Yesterday, on September 11, 2026, something went live that many European IR teams had spent months preparing for—and still underestimated: the reporting obligation under Article 14 of the Cyber Resilience Act (CRA). From now on, manufacturers of “products with digital elements” must report actively exploited vulnerabilities and severe incidents to ENISA and the competent national CSIRT within 24 hours. Anyone who thinks this is purely a legal or product-security compliance exercise is missing the point: the clock starts the moment anyone in the organization becomes aware—and that’s exactly what turns Article 14 into an incident response process problem.
The Cascade: 24 Hours, 72 Hours, 14 Days
The reporting mechanism follows a clear structure. Within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident, organizations must submit an “early warning” to ENISA, followed within 72 hours by a detailed notification. For vulnerabilities, a final report follows within 14 days; for severe incidents, within one month. The technical mechanics run through a single platform: manufacturers submit one notification through the Single Reporting Platform to the relevant coordinating CSIRT and to ENISA, which is then shared with other relevant CSIRTs as appropriate—avoiding the need for separate filings at the member state level.
For IR teams, this means the trigger isn’t confirmation of an incident by the SOC—it’s the first moment of suspicion anywhere in the organization. That’s precisely where the operational challenge lies: the reporting process begins when the manufacturer becomes aware of the actively exploited vulnerability or severe security incident, which makes internal escalation particularly important. A tip-off can surface first with a developer, a support agent, or a customer-facing team, long before it ever reaches the SOC.
Distinguishing CRA from NIS2—and Why Both Can Apply at Once
Organizations that already have NIS2 reporting processes shouldn’t mistake CRA for redundant paperwork. Under NIS2, the trigger is a significant incident affecting service continuity, while under the CRA it’s the discovery of an actively exploited vulnerability in a product, demanding rapid, coordinated disclosure to prevent widespread harm. The two regimes can overlap: a CRA report concerns an actively exploited vulnerability or severe incident in a product and goes via CSIRT and ENISA, while a NIS2 report concerns a significant incident affecting services under the national regime—one event can trigger both. Playbooks need to reflect the routing difference: CRA reports go through the Single Reporting Platform that ENISA is building, into the CSIRT of the manufacturer’s main establishment, then to ENISA and other affected national CSIRTs.
Notably, the obligation applies retroactively to products already on the market: legacy products are in scope for reporting even though they’re exempt from full compliance—the reporting duty applies to everything already on the market.
What IR Teams Need to Do Right Now
In practice, this means classic incident response plans need CRA-specific triggers bolted on. Guidance points to updating incident response plans and vulnerability management policies to reflect CRA-specific triggers and timelines alongside NIS2, GDPR, and other applicable requirements, preparing notification templates in advance, and maintaining an internal incident log capturing the awareness timestamp, classification decision, and submission record. On top of that, a workable triage process is essential: it doesn’t need to be fully Annex I-compliant by the deadline, but it must be functional—monitoring, disclosure channels, and a triage process that can assess severity quickly.
For SOC and IR leadership, the takeaway is unambiguous: Article 14 isn’t a legal department side project. It’s a new escalation discipline that must synchronize development, support, security, and legal on a shared 24-hour cadence—starting now, not after the next incident.
← Back to overview