Why your final CRA report isn't due 14 days after you find the bug

If you've read Article 14 once and walked away thinking "24 hours, 72 hours, then 14 days," you have the third number half right. There are two final-report clocks under the Cyber Resilience Act, not one, and neither of them starts when you became aware of the problem. Get this wrong and you either file early on incomplete information or file late on a deadline you didn't know had already started.

The short answer

For an actively exploited vulnerability, the final report is due within 14 days of a corrective or mitigating measure becoming available — not 14 days after awareness, and not 14 days after the 72-hour notification.Art. 14⁠(2)⁠⁠(c)⁠ For a severe incident, the final report is due within one calendar month of submitting the 72-hour notification.Art. 14⁠(4)⁠⁠(c)⁠ Two different events start two different clocks, and a case can sit for weeks between the 72-hour stage and the moment the final clock even begins.

Why a fix, not awareness, starts the vulnerability clock

The early warning and the notification both run from awareness, so it's natural to assume the final report does too. It doesn't, on purpose: a vulnerability can be disclosed and actively exploited long before anyone has a fix ready, and a report that's required to arrive on a fixed schedule regardless of whether a remedy exists would either force a manufacturer to invent a placeholder measure or force the authority to read a report that repeats "nothing to add" indefinitely. Instead, the clock is silent — legitimately, not by oversight — until a corrective or mitigating measure becomes available, and then a manufacturer has 14 days to write it up.

That silence is where the practical risk lives. Nothing in the platform prompts you when a fix ships; you have to know it happened and record the moment. A release that patches the vulnerability, a mitigation that's been validated as sufficient, a compensating control your engineering team confirms closes the exposure — any of these can be the trigger, and the 14 days start counting the day it does, not the day someone remembers to check.

Why "one month" for an incident is not "30 days"

The incident final report runs from a point you control directly: when you submitted the 72-hour notification. That's simpler to track, but the arithmetic still trips people up. "One month" is calendar-month arithmetic, not a fixed 30-day span — a notification submitted on 31 January is due 28 or 29 February, not 3 March. Software that reaches for a 30-day duration instead of calendar-month addition will compute a final-report deadline that's wrong by up to three days, in either direction depending on which months are involved. It also means the recorded submission timestamp is worth protecting carefully: ENISA's platform has no API, a named person files by hand, and if that submission time is fuzzy or backdated, the final deadline inherits the same uncertainty.

Two lessons for whoever owns this internally

Record the trigger event, not just the case. A vulnerability case needs a timestamped "fix available" fact independent of the awareness timestamp; an incident case needs the actual filing time of the 72-hour notification, not the deadline it was measured against. If your tracking only stores "when we became aware," you have no way to compute either final deadline correctly.

Treat the gap between notification and final report as real, not idle. For a vulnerability with no fix yet, that gap can run for months, and it's tempting to treat an open case with no due date as low priority. It isn't — the final-report clock can start at any moment a fix lands, with no advance notice, and a manufacturer who isn't watching for that moment finds out about the 14-day window on day nine.

This is exactly the distinction Declara's clock engine is built around: it computes both deadlines from the actual triggering event you record, on UTC instants that don't drift with daylight saving time, and it tells you plainly when a final deadline is legitimately unknown rather than guessing. Read the full mechanics, including the CSIRT that receives each stage, on Article 14, in plain language, or check where your product's clocks currently stand with the five-question scope check.