When does the 14 day final report clock actually start?

What the law actually says

This is the deadline people get wrong most often, because it isn’t a fixed number of days from when you found out. Article 14(2) of Regulation (EU) 2024/2847 (the Cyber Resilience Act) sets out three submissions for an actively exploited vulnerability (AEV). Point (c) requires “a final report, no later than 14 days after a corrective or mitigating measure is available.” This is a distinct anchor from the other two AEV deadlines in the same paragraph: the early warning notification is due “within 24 hours of the manufacturer becoming aware” of it, and the vulnerability notification is due “within 72 hours of the manufacturer becoming aware” of the vulnerability. Only the final report’s clock is tied to a fix, not to awareness.

Article 14(4) sets out the parallel obligations for a severe incident (SI). Point (c) requires “a final report, within one month after the submission of the incident notification under point (b),” where point (b) is the 72-hour incident notification. So the SI final report’s clock starts from a submission timestamp the manufacturer controls directly, not from any remediation milestone. Nothing in Article 14(4)(c) or in ENISA’s own guidance qualifies this as a “calendar” month specifically; the text and ENISA’s FAQ both just say “one month.”

Confirming this against ENISA’s own SRP materials

The ENISA Single Reporting Platform (SRP) glossary carries a dedicated field for this exact anchor, titled “Date when corrective or mitigating measure has been available” and defined as “Date and time when the mitigating measure has been available.” It is optional at the Early Warning and 72-hour stages but becomes required at Final Report. That lines up with treating the corrective-measure date as its own tracked timestamp, separate from the awareness timestamp.

The ENISA SRP FAQ makes the operational consequence explicit. For AEVs, it states: “no counter is currently implemented, as the Final Report deadline depends on the date and time when a corrective or mitigating measure becomes available,” a date that is not known in advance and can arrive well after, or even independently of, the 72-hour notification. For SIs, by contrast, the FAQ states: “the counter displays a due date one month after submission of the 72-hour Severe Incident Notification,” a fixed, calculable countdown from a known timestamp.

Why the two notification types use different anchors

An AEV’s final report exists to document the remediation: the report must include “details about the security update or other corrective measures that have been made available to remedy the vulnerability” (Article 14(2)(c)(iii)). That content cannot exist before a fix exists, so gating the clock on the corrective-measure date is a substantive requirement, not an arbitrary choice.

An SI’s final report has no equivalent dependency. Its required content is a detailed description of the incident, the likely threat or root cause, and “applied and ongoing mitigation measures” (Article 14(4)(c)(iii)), all of which can be described a month out regardless of whether the incident is fully remediated. So there is no reason to wait for a fix, and the regulation instead anchors the SI final report to a fixed, already-known reference point: the 72-hour notification’s submission timestamp.

Practical implication

For an AEV case, do not start the 14-day countdown from the awareness timestamp or from when the 72-hour notification was submitted. The countdown only starts, and the final report only becomes due, once a corrective or mitigating measure is actually available; until then, per the ENISA FAQ, the SRP platform does not run an automatic counter toward that deadline at all. For an SI case, the 1-month countdown starts as soon as the 72-hour incident notification is submitted, independent of remediation status, and the platform does display a computed due date for it.

Unsettled: ENISA’s own platform shows no live countdown for the AEV final report, since the fix date isn’t known in advance. That’s a gap in ENISA’s tooling, not a change to the 14-day deadline itself: track it yourself.