CRA reporting timeline: 24 hours, 72 hours and the final report
The Cyber Resilience Act's reporting deadlines are elapsed time from awareness — 24 hours for the early warning and 72 hours for the notification — followed by a final report whose trigger differs: 14 days after a fix is available for exploited vulnerabilities, one calendar month after the notification for severe incidents.
By the Vellaci teamPublished Updated 5 min readOperational guidance, not legal advice
Key facts
- Clock start
- The moment the manufacturer becomes aware (recorded with timezone)
- Early warning
- +24 h
- Notification
- +72 h
- Final report (vulnerability)
- Fix available + 14 days
- Final report (incident)
- Notification + 1 calendar month
- Weekends and holidays
- Count. No pause, no extension.
Two case types, two final-report triggers
Both actively exploited vulnerabilities and severe incidents share the 24-hour early warning and 72-hour notification from awareness. They differ on the final report.
- Vulnerability: final report no later than 14 days after a corrective or mitigating measure becomes available. Until such a measure exists, no final-report timer runs — but the vulnerability-handling duty to remediate without delay does.
- Incident: final report within one month after the 72-hour notification. One month is a calendar month, not 30 days: a notification submitted on 31 January leads to a final report due by 28 (or 29) February; one submitted on 15 March is due by 15 April.
Worked example 1 — exploited vulnerability
Awareness: Monday 5 October 2026, 09:15 CEST (Europe/Brussels), confirmed by the security lead after a customer's incident responder shares indicators matching a KEV-listed CVE in a shipped component.
Early warning due: Tuesday 6 October 2026, 09:15 CEST.
Notification due: Thursday 8 October 2026, 09:15 CEST.
Fix released: Tuesday 20 October 2026, 18:00 CEST → final vulnerability report due Tuesday 3 November 2026, 18:00 CET. Note the daylight-saving change on 25 October: the deadline stays at 18:00 local time, which is one hour later in UTC than it would have been in CEST. Compute in the organisation's IANA timezone, never in fixed offsets.
Worked example 2 — severe incident
Awareness: Friday 29 January 2027, 17:40 CET, when the on-call engineer confirms that the update server distributed a tampered package to devices in three Member States.
Early warning due: Saturday 30 January 2027, 17:40 CET — a Saturday; the runbook's deputy submits.
Notification submitted: Sunday 31 January 2027, 16:00 CET (within the 72-hour window ending Monday 1 February, 17:40 CET).
Final report due: one calendar month after the notification — Sunday 28 February 2027, 16:00 CET. Adding 30 days would have produced 2 March, which is late.
Worked example 3 — no fix yet
Awareness of exploitation on 12 May 2027 at 08:00 CEST; early warning and notification follow at 08:00 on 13 and 15 May. The corrective measure is a firmware update that ships on 30 June 2027 at 10:00 CEST. The final report is due 14 July 2027, 10:00 CEST. Between 15 May and 30 June no final-report timer runs, but the 72-hour notification should already describe mitigations users can apply, and a mitigating measure (a configuration workaround published on 20 May) would itself have started the 14-day clock — which is why the record must state precisely which measure was 'available' and when.
The 'unless already provided' nuance
Article 14 says the 72-hour notification is due 'unless the relevant information has already been provided'. If your early warning already contained everything the notification requires, you may not need a separate submission — but in practice the initial assessment and the measures sections are rarely complete at hour 24. Treat the notification as an update to the early warning, and keep both as frozen revisions so the sequence is auditable.
Timeline at a glance
| Moment | Vulnerability case | Incident case |
|---|---|---|
| T0 — awareness | Recorded with timezone and confirming person | Recorded with timezone and confirming person |
| T0 + 24 h | Early warning | Early warning (incl. whether malicious acts suspected) |
| T0 + 72 h | Notification | Notification |
| Fix available (F) | Starts the 14-day final-report timer | — |
| F + 14 days | Final report | — |
| Notification + 1 calendar month | — | Final report |
| Continuous | Inform impacted users; remediate; update | Inform impacted users; contain; remediate |
Several products, one event
When one exploited component affects several products, awareness is a single moment and the clocks are shared: one early warning describing all affected products and versions, one notification, and — for the vulnerability case — a final report 14 days after the corrective measure for the last affected product ships, or separate final reports per product if fixes arrive far apart and you prefer to close each thread. Keep one case with all products linked so the Member States list and the measures section stay consistent across submissions.
After hours and across borders
Awareness at 17:00 on a Friday puts the early warning at 17:00 on Saturday. The runbook therefore needs a deputy for the assigned representative, platform credentials held by at least two people, and a decision rule for who confirms awareness when the security lead is unreachable. Teams split across time zones should agree the organisation's reference timezone in advance and record every timestamp with its offset; the regulation does not prescribe a timezone, but inconsistency inside a case is what invites questions.
Use the calculator
The free CRA deadline calculator on this site uses the same versioned deadline engine as the Vellaci product, including calendar-month arithmetic and timezone handling across daylight-saving transitions. Inside Vellaci, the same engine runs as a background job that persists each deadline with the rule version and source timestamp that produced it, so a later change of awareness time recalculates everything with an audit trail.
Frequently asked questions
- What if awareness turns out to be earlier than first recorded?
- Correct the awareness time with a reason; the deadlines recalculate and the change is audited. Report on the corrected timeline and say so in the notification — a documented correction is defensible; an undocumented one is not.
- Do we count hours or working days?
- Hours. 'Within 24 hours' is elapsed time.
- Which timezone applies?
- The regulation does not prescribe one. Compute in the organisation's timezone for operations and show UTC alongside for the record; be consistent within a case.