CRA Reporting from 11 September 2026: The 24/72-Hour Clock
Article 14 gives a manufacturer 24 hours at the outside — the duty itself starts the moment you become aware. The part that catches people is not the 24 — it is that the final-report clocks do not run from when you found out, and that none of these deadlines pause at the weekend.
The Cyber Resilience Act — Regulation (EU) 2024/2847 — is mostly a 2027 problem. Its reporting duties are not. Article 14 applies from 11 September 2026, ahead of the main body of the Regulation, and it applies to products already on the market, not only to ones placed after that date.
What it requires is a 24-hour clock. What people get wrong is everything after the first rung.
The two tracks
Article 14 covers two different things, and they are not the same ladder.
An actively exploited vulnerability in a product with digital elements:
- early warning — without undue delay and in any event within 24 hours of the manufacturer becoming aware, indicating where applicable the Member States in which the product has been made available;
- vulnerability notification — within 72 hours of becoming aware, with an assessment of the vulnerability including its severity and impact and, where available, information on any corrective or mitigating measures;
- final report — no later than 14 days after a corrective or mitigating measure is available.
A severe incident having an impact on the security of the product:
- early warning — within 24 hours of becoming aware, including at least whether the incident is suspected of being caused by unlawful or malicious acts;
- incident notification — within 72 hours of becoming aware;
- final report — within one month after the submission of the incident notification.
Side by side, with the third regime most of these firms also carry:
| track | early warning | notification | final report | what the final report is counted from |
|---|---|---|---|---|
| CRA, actively exploited vulnerability | 24 h | 72 h | 14 days | a corrective or mitigating measure being available |
| CRA, severe incident | 24 h | 72 h | 1 month | the submission of the notification |
| NIS2, significant incident | 24 h | 72 h | 1 month | the submission of the notification |
Read the final-report column again, because it is the one that gets built wrong.
The final-report clocks do not start when you find out
Every summary of Article 14 you will read presents it as "24 / 72 / final, from the moment of awareness". The first two rungs are indeed from awareness. The third is not, on either track, and the two are anchored to different events.
On the vulnerability track, the 14 days runs from a corrective or mitigating measure being available. That is an event that may not have happened yet. If you are three days into an actively exploited flaw with no fix and no workaround, your final-report clock has not started — there is no date to miss. A register that shows you "14 days from discovery" is showing you a date nobody is owed. The honest state is not started, plus the thing that will start it.
It also means the clock is, in part, in your hands. Ship the mitigation and you start a 14-day timer.
On the incident track, the month runs from the submission of the notification — the moment you actually sent it, not the 72-hour deadline you were measured against. File at hour 40 and your final report is due a month after hour 40. Filing early moves your later deadline earlier. That is counter-intuitive enough that it is worth stating to whoever is doing the filing at 3am.
NIS2 is the same shape, and it is not the same law
If you are also an essential or important entity, NIS2 (Directive (EU) 2022/2555) Article 23(4) runs alongside:
- (a) early warning within 24 hours of becoming aware of the significant incident;
- (b) incident notification within 72 hours, updating the early warning with an initial assessment;
- (c) an intermediate report on the request of the CSIRT or competent authority — no deadline until they ask;
- (d) a final report not later than one month after the submission of the incident notification;
- (e) where the incident is still ongoing at that point, a progress report then, and a final report within one month of the handling being completed.
One event routinely triggers both regimes at once, off the same moment of awareness, with different provisions and different content requirements. Whatever you use to track this needs to hold more than one ladder per incident.
And the difference that matters procedurally: the CRA is a Regulation and applies directly. NIS2 is a Directive. What binds you is your Member State's transposition — the authority you report to is national, and the detail can vary. Anything claiming to give you your NIS2 deadlines without knowing your Member State is overstating what it knows.
The clocks do not stop at the weekend
There is no working-day carve-out in Article 14 or in Article 23. None. A vulnerability you become aware of at 18:00 on a Friday has an early warning due at 18:00 on Saturday, and a notification due at 18:00 on Monday.
This is the single most common wrong assumption about the regime, and it is a rota problem before it is a legal one. Twenty-four hours means the person who can file has to be reachable, has to have the credentials, and has to know what "we became aware" means for your organisation. A deputy is not optional.
Awareness is the thing you are actually deciding
Every deadline in both instruments counts from becoming aware. Nothing computes that for you. It is an organisational judgement — the moment the organisation, not one engineer, knew — and it is the input that determines every other date.
Which means two practical things. Record it to the minute, not the day: a 24-hour deadline cannot be computed from a date, and rounding to midnight is how a filing becomes late. And decide in advance who makes that call and how fast a detection reaches them, because deciding it during an incident is how the first six hours disappear.
What to have in place before 11 September 2026
- Who files. A named person, a named deputy, out-of-hours contact details, and credentials for the reporting route that are not in one person's head.
- Who decides that something is reportable, and an escalation time from detection to that decision.
- The reporting destination. The CRA routes through the single reporting platform; NIS2 goes to your national CSIRT or competent authority. Write both down now.
- A vulnerability handling record — the CRA expects manufacturers to keep one — with the flag that matters: is it actively exploited, and is a corrective measure available yet.
- Somewhere to record what you actually sent, with the timestamp, the recipient, their reference and the text. That record is the evidence, and it is also what anchors the one-month final-report clock.
If you also build or deploy AI systems, the AI Act's timetable overlaps this one — Article 4 has been binding since February 2025, Article 50 transparency arrived on 2 August 2026, and the high-risk regime was deferred to December 2027.
The honest summary
The 24 hours is the headline and the easy part to understand. The parts that produce a late filing are quieter: a final-report clock that has not started and a register that shows a date anyway; a month counted from the wrong event; a Saturday deadline nobody expected; and an awareness time recorded as a date instead of a moment.
None of that needs an enterprise platform. It needs the clocks computed from the right anchors, and somebody reachable. Cyresora does the first; the second is a rota, and only you can write it.
Cyresora is our self-hosted register for exactly this: every running deadline in hours, worst first, with the provision it comes from and the event it is counted from — including the ones that have not started. It runs on your own server, one payment. Nothing here is legal advice, and NIS2 deadlines are ultimately your Member State's.