"The 24-hour deadline only starts once we know what exactly happened." This sounds like sound engineering sense: understand first, then report. Under the Cyber Resilience Act it is still wrong, and in practice it reliably leads to missed deadlines that would have been easy to avoid.
What does the staged model in Article 14 mean?
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents. Article 14 CRA does not require a single, complete report, but three stages:
- Early warning within 24 hours of becoming aware. It is deliberately kept brief: the affected product, the fact of the active exploitation or the incident, and where applicable the affected member states.
- Notification within 72 hours with general information on the vulnerability or incident, an initial assessment, and remedial measures already taken or planned.
- Final report, for vulnerabilities no later than 14 days after a corrective measure becomes available, and for severe incidents within one month of the 72-hour notification.
You report once, via the ENISA Single Reporting Platform (ENISA being the EU Agency for Cybersecurity). The report goes to the CSIRT designated as coordinator for the member state where the manufacturer has its main establishment, and to ENISA at the same time as a matter of principle. The platform is currently being built and is meant to be operational by the deadline. Which cases are reportable at all is broken down in our practical guide to the EU CRA reporting obligations.
The decisive point: the clock starts with awareness. Awareness here does not mean the arrival of a tip in your inbox, but the moment your initial assessment establishes with sufficient certainty that active exploitation is present. That initial assessment, however, may not be deferred: it has to happen without undue delay and be documented seamlessly, otherwise an earlier point in time applies in case of doubt. What does not start the clock: the completion of the root-cause analysis, sign-off by the legal department, the finished patch.
Why waiting for the full analysis is dangerous
The reflex "understand first, then report" comes from a world in which reports had to be complete. The CRA reverses this logic: the early warning may be incomplete, that is exactly what it was created for. After 24 hours the legislator wants not a forensic opinion but a signal, so that CSIRTs and ENISA can spot waves of attacks early.
Anyone who nevertheless waits for full clarity risks two things:
- An avoidable missed deadline. Analysing an actively exploited vulnerability almost always takes longer than 24 hours. Anyone who makes it a precondition for reporting breaches the deadline structurally, in every single case.
- A documentation problem. The point in time of awareness can be reconstructed later, for instance via monitoring alerts, ticketing systems, or emails. If a weekend of analysis work sits between awareness and report, it is there in black and white in your own systems.
The typical scenario: Friday, 4:30 pm, monitoring reports that a firmware component has appeared in the CISA Known Exploited Vulnerabilities Catalog. The security team plans the clean analysis over the weekend and the report for Monday. By Monday the 24-hour deadline has been blown for two days, and the 72-hour deadline along with it.
Myth vs. Fact
Myth: The 24-hour deadline only begins once the vulnerability has been fully analysed and understood.
Fact: The deadline runs from awareness of the active exploitation. Within 24 hours only a deliberately incomplete early warning is due. The substantive depth follows in stages: notification after 72 hours, final report after 14 days or one month respectively.
Concrete consequences for your reporting process
1. Define the verification step in writing. Set out how a tip becomes established awareness: which inputs are checked (monitoring hits, CERT advisories, customer and researcher reports), who assesses without undue delay, who establishes the result, and how arrival, start of assessment, and verification are documented with timestamps. It is precisely this documentation that later shows your deadline only began with verification, and that the assessment nonetheless ran promptly.
2. Prepare an early-warning template. The early warning needs few details: product, type of event, contact data. A prepared template that can be filled out in 30 minutes when it counts takes the terror out of the deadline. Clarify access to the Single Reporting Platform in advance and set up deputisation rules, so the process does not fail because someone is on holiday.
3. Rehearse the sequence under realistic conditions. Simulate a finding on a Friday afternoon: how long does it take from the monitoring alert to the early warning being sent? Who decides when management is unreachable? A single dry run exposes more gaps than ten process documents. The foundation for even knowing which components sit in which products is your vulnerability management based on a complete SBOM. A starting point is the guide to vulnerability management and the SBOM guide.
What does this mean for your CRA roadmap?
On 11 September 2026 the staged model goes live. The reporting process, including the trigger definition, templates, and platform access, has to be in place beforehand and rehearsed at least once.
On 11 December 2027 full CRA applicability follows, with conformity assessment and CE marking for products newly placed on the market.
The ability to report within 24 hours is not an isolated compliance topic but the hardest practical test of your entire vulnerability management. How the two deadlines translate into a plan is shown in the CRA compliance roadmap 2026/2027. The consequences of missed deadlines are covered in the article on CRA fines and penalties.
Frequently asked questions
What if the early warning later turns out to be a false alarm? Then you correct it in the 72-hour notification or the final report. An early warning that proves unfounded is not a breach. A missing report that proves justified is.
Does the deadline also run on weekends and public holidays? Yes. The 24 hours know no business hours. That is precisely why the process needs deputisation rules and must not hang on a single person.
Whose awareness counts, the intern's or the management's? The CRA looks at the manufacturer's awareness, not at a hierarchy level. What matters is the completion of the initial assessment with sufficient certainty, not the arrival of a tip. But: internal forwarding paths and a delayed assessment do not push the deadline back, they only create the accusation of having become aware too late.
Do we have to report to several authorities in parallel? As a rule, no. The report runs via the Single Reporting Platform to the CSIRT designated for your member state and is made available to ENISA at the same time as a matter of principle. Note, however, that other regimes, such as NIS2 for your own corporate IT, may have their own reporting paths.
What belongs in the 72-hour notification, and what does not yet? General information on the vulnerability or incident, severity and impact as far as known, measures taken and planned. Full forensics belong in the final report, not in the 72-hour stage.
Conclusion
The CRA's staged model is not a harassment but a concession: no one demands complete analyses within 24 hours, only a fast, brief signal. The deadline only becomes dangerous for companies that treat it like a classic full report or improvise the process only when it counts.
An automated compliance platform like Kunnus helps you interlock exploitation signals, SBOM matching, and reporting templates so that the 24 hours are enough, before the deadline tips from theory into practice. A starting point is our free CRA compliance check.
Every Friday I debunk a CRA myth here.