Twenty-four hours sounds generous until a clock is running through a Saturday night. The teams that handle it well aren't faster on the day — they've moved almost all the work to before the day, so the 24 hours is spent executing a plan, not building one.
When the clock starts
The 24-hour clock starts when you become aware of an actively exploited vulnerability affecting your product, or a severe incident with security impact. "Aware" is the trigger, so how you detect and confirm awareness matters — the detail of the vulnerability trigger is in what counts as actively exploited. From that moment, the early warning is due within 24 hours.
The first 24 hours, step by step
- Log the awareness. Record when and how you became aware — the clock's start time is itself something you may need to evidence.
- Classify the stream. Actively exploited vulnerability, severe incident, or both? They run separate clocks (see the two streams).
- Assess: does it affect our product? The critical, hardest step — is the exploited vulnerability actually reachable and exploitable in your product? This is where reachability and exploitation evidence earn their place, because guessing here is what you can't afford.
- Decide reportability. If it's actively exploited and affects your product, it's reportable. The decision is the manufacturer's; the tooling surfaces the candidate with evidence, it doesn't decide for you.
- Draft from the template. Populate the pre-approved early-warning template — not a blank page.
- File to the coordinating CSIRT via the Single Reporting Platform, and log what was filed, when, and to whom.
What has to be prepared in advance
Four things can't be created inside the 24 hours: an on-call rota that covers weekends and holidays; your coordinating CSIRT identified and any onboarding done (see CSIRT routing); pre-approved templates for both streams and all three stages; and a fast, defensible way to assess whether a product is affected. Prepare these and the 24 hours is executable. Skip them and it isn't.
After the early warning
The early warning is the start, not the end. A fuller notification follows within 72 hours, and a final report after that — 14 days for a vulnerability once a corrective measure is available, a month for a severe incident. Keep the streams and their clocks distinct, and keep an immutable log of every filing. The whole three-stage obligation is laid out in the reporting pillar.
Frequently asked
What has to happen within 24 hours under the CRA?
From becoming aware of an actively exploited vulnerability or a severe incident, you must submit an early warning to your coordinating CSIRT via the Single Reporting Platform within 24 hours. It’s a brief notification that you’re aware of the event — not a full analysis.
How detailed does the 24-hour early warning need to be?
Minimal. The early warning signals awareness and the nature of the event; the fuller assessment comes at 72 hours and the complete report later. The point of the 24-hour step is speed, not completeness.
How do you meet a 24-hour clock that ignores weekends?
By preparing before it starts: an on-call rota, a known coordinating CSIRT, pre-drafted templates, and — critically — a fast, defensible way to decide whether your product is actually affected. The 24 hours is for executing a rehearsed process, not inventing one.