CRA reporting deadlines: 24 hours, 72 hours, 14 days
What the Cyber Resilience Act reporting clocks measure, when they start, why they run in parallel, and what to have ready before the obligation begins.
From 2026-09-11 the Cyber Resilience Act stops being a project for next year. Reporting obligations start on that date, they apply to products already sold, and the first clock runs for 24 hours.
Three deadlines, one trigger
| Deadline | What you send | Counted from |
|---|---|---|
| 24 hours | Early warning: that something is happening, with whatever you know | The moment you become aware |
| 72 hours | Notification: what it is, which product, what you are doing about it | The same moment |
| 14 days | Final report for an actively exploited vulnerability | The same moment |
| 1 month | Final report for a severe incident | The same moment |
All four run from the same instant, not from each other. Filing the early warning does not restart anything. This is the single most common misreading, and it costs two days of the schedule to the person who makes it.
What starts the clock
Awareness. Not confirmation, not triage, not a fix. The moment a reasonable person in your company knew that a vulnerability in your product is being actively exploited, or that a severe incident affecting its security has happened, the clock is running.
That has a practical consequence for how you watch your dependencies. If a component you ship appears in the CISA catalogue of known exploited vulnerabilities on a Friday evening and nobody looks until Monday, you have spent most of the first window on a weekend. The awareness test does not care that the office was closed, but it does care whether your process was capable of noticing.
The final report is not a formality
The 14-day report describes the vulnerability, its severity and impact, and the corrective measures you made available. In other words it presumes you shipped a fix. Two weeks is comfortable for a dependency bump and uncomfortable for anything requiring a coordinated release with downstream integrators, which is exactly the case where a small vendor is slowest.
For a severe incident the final report is due within 1 calendar month. Calendar, not thirty days: an incident on 31 January is due on 28 February. If you are computing deadlines in code, this distinction is a real bug waiting to happen.
Time zones and the sixteen-hour trap
Deadlines are absolute instants, not local dates. A vulnerability confirmed at 18:00 in Berlin is due at 18:00 the next day in Berlin, which is the middle of the night for a distributed team in California. Teams that store deadlines as dates and render them in the reader's own zone discover the gap the first time the two disagree, and they discover it late.
Store the instant in UTC, render it in the operator time zone, and show the remaining time rather than the target time. Remaining time cannot be misread.
What to have ready before the date
- A named person and a named backup. A rota with one name is a rota that fails during a holiday.
- A current inventory of what ships inside each product, so that a vulnerability report can be answered with which of our products, not with we will check.
- A monitoring path that notices exploitation the day it becomes public rather than the week.
- A draft of the early warning. Filling a template under pressure is a different activity from writing one.
- A record of what you did and when. The obligation is to report; the ability to show that you reported on time is a separate problem, and it is yours.
Where reports go
Reports are submitted through the single reporting platform run by ENISA together with the CSIRT designated as coordinator. Check the current submission route before you need it rather than at hour twenty of a twenty-four hour window.