CRA incident reporting: the 24h / 72h / 14-day clock
The CRA reporting duty runs on a fixed clock — early warning in 24 hours, notification in 72 hours, final report in 14 days, weekends included. When the clock starts, what each stage contains, and who you report to.
Not sure if you’re in scope?
Run the free 3-minute scope check for your product and get your risk class, deadlines and obligations.
Check if the CRA applies to youIn short
Under the EU Cyber Resilience Act, the reporting clock starts the moment you become aware of an actively exploited vulnerability or a severe incident. From that instant you have three fixed deadlines: an early warning within 24 hours, a vulnerability or incident notification within 72 hours, and a final report within 14 days. All three run on calendar time — weekends and holidays included — and all go to ENISA through its single reporting platform plus the relevant national CSIRT. This applies from 11 September 2026.
Most of the CRA reporting obligation comes down to one question people get wrong under pressure: when does the clock actually start, and how much time do I really have? The answer is not "a few days." It is a three-stage sequence measured in calendar hours from the moment of awareness, and each stage has its own deadline that keeps running through the night, the weekend and the public holiday.
This guide is about the mechanics of that clock. For the step-by-step playbook — who files, how to register, what readiness looks like — see our companion guide on ENISA 24-hour reporting. Here we focus on the timeline itself.
Not sure the CRA applies to your product? Run the free 3-minute scope check first.
When does the clock start?
The clock starts the moment you become aware of one of two things (Article 14 of Regulation (EU) 2024/2847):
- An actively exploited vulnerability in your product — meaning there is evidence it is being used in the wild, not merely that a CVE has been published.
- A severe incident having an impact on the security of your product — for example a compromise of your build pipeline or update infrastructure.
“Becoming aware” is a low bar and it is the single most important thing to get right, because it anchors all three deadlines. A customer email, a researcher’s disclosure, a forum post naming your product, or an alert from your own monitoring can each start the clock — at any hour, on any day. There is no grace period for confirming the report first: awareness of a credible signal starts the count. Deciding whether a given vulnerability is genuinely exploited is exactly the judgement covered in our vulnerability triage guide.
Note that a published vulnerability nobody is exploiting does not start this clock. You still have to fix it under your vulnerability-handling duties, but the 24-hour early warning is reserved for active exploitation and severe incidents.
The three-stage clock
Once the clock starts, three notifications fall due in sequence, each with more detail than the last:
| Stage | Deadline from awareness | What the notification contains |
|---|---|---|
| 1. Early warning | Within 24 hours | That an actively exploited vulnerability or severe incident exists, and the member states where the product is available. Deliberately minimal — you are not expected to have answers yet, only to raise your hand. |
| 2. Notification | Within 72 hours | General information about the product, the nature of the exploit or incident, any corrective or mitigating measures taken or available, and an initial severity assessment. |
| 3. Final report | Within 14 days (vulnerabilities) | A full description, the severity and impact, the root cause where established, and the corrective measures rolled out. For severe incidents, the final report is due within one month. |
Two things about how the clock runs trip teams up:
It is calendar time, not business time. Twenty-four hours means twenty-four hours — not one working day. If you become aware at 18:00 on a Friday, the early warning is due by 18:00 on Saturday. The 72-hour and 14-day windows behave the same way. Weekends and public holidays are inside the count, not paused around it.
The stages are cumulative, not alternatives. Filing the early warning does not discharge the duty; it opens it. The 72-hour notification and the final report still fall due afterward, each measured from the same moment of awareness — not from when you filed the previous stage.
Who do you report to?
All three notifications go to the same two places, through one channel:
- ENISA, via the single reporting platform the CRA establishes for this purpose. One submission, one account, the same platform for every stage.
- The CSIRT of the member state where your main establishment sits (in Belgium the CCB, in Germany BSI/CERT-Bund, in the Netherlands NCSC-NL, and so on).
You do not choose between them and you do not file twice by hand — the platform routes to the relevant CSIRT. The practical prerequisite is knowing your national CSIRT in advance and holding a registered account before an incident, so stage 1 is a login-and-submit, not a sign-up-under-pressure.
The clock runs on calendar time, so a Friday-night disclosure can burn most of the 24-hour early-warning window before anyone is even watching the deadline.
Nordchecks starts the 24h/72h/14-day clock the moment you log an incident, counts down each deadline, and pre-fills every stage's notification for ENISA and your national CSIRT.
Try Nordchecks freeWhat is and isn't reportable
Not every security event starts this clock. The trigger is narrow by design:
- Reportable: an actively exploited vulnerability (evidence of exploitation in the wild), or a severe incident affecting the security of your product. These start the 24-hour clock.
- Not reportable on this clock: a newly published CVE with no evidence of exploitation, a vulnerability you find and fix internally before anyone exploits it, or a routine bug with no security impact. These belong to your ordinary vulnerability-handling process, not the incident clock.
The distinction matters because over-reporting and under-reporting both carry cost: flooding ENISA with non-exploited CVEs wastes everyone’s time, while missing a genuine exploitation is a compliance failure. Getting the triage decision right is what keeps the clock honest.
How the clock fits the rest of the CRA
This reporting duty applies from 11 September 2026, and it covers products already on the market — including everything you shipped before 2026. It is the first CRA obligation to bite, well ahead of the December 2027 full-compliance deadline. If you are mapping the whole phased timeline, our CRA deadlines guide sets out how the two dates relate.
The good news is that being ready for the clock and being ready for 2027 draw on the same foundation: a current SBOM so you can assess impact fast, live vulnerability monitoring so you become aware early, and pre-filled templates so filing is a fill-in exercise rather than a writing one. A dedicated CRA compliance tool keeps that foundation in one place, so the clock is something you watch rather than something that catches you out.
Get the foundation in place before September: check your product’s scope and class free — three minutes, no signup.