The CRA final report clock does not start when you become aware

Almost every summary of the Cyber Resilience Act's reporting duty presents it as three deadlines counted from the same moment: an early warning within 24 hours, a notification within 72 hours, a final report within 14 days. The first two are right. The third is wrong, and wrong in a way that matters on the day.

Article 14 of Regulation (EU) 2024/2847 has applied since 11 September 2026. Here is what it says, and where the 14 days actually starts.

Two tracks, three deadlines each

Article 14 sets up two separate reporting tracks. Paragraph 1 creates the duty to notify an actively exploited vulnerability in a product with digital elements. Paragraph 3 creates the duty to notify a severe incident having an impact on the security of such a product. Neither paragraph says anything about timing. The deadlines live in paragraphs 2 and 4, each of which opens "for the purposes of the notification referred to in paragraph 1" (or 3) and lists three items.

For an actively exploited vulnerability, Article 14(2):

For a severe incident, Article 14(4):

The two final reports have different anchors, and neither of them is awareness.

What that means for a vulnerability

Article 14(2)(c) reads, in its operative part: the final report is due "no later than 14 days after a corrective or mitigating measure is available". The measure is the anchor. Not the exploit, not the discovery, not the 72-hour notification.

Three consequences follow, and the field gets all three wrong.

The final report deadline may not exist yet. If you have filed the early warning and the notification and you are still working on a fix, there is no date. Not a distant date, no date. A tool that prints "final report due 25 September" fourteen days after you became aware has invented a deadline the Regulation does not set. A tool that prints "no deadline until a corrective measure is available" is reading the text.

A workaround starts the clock, not only a patch. The wording is "corrective or mitigating measure". A documented configuration change, a feature you tell customers to disable, a network rule: if it mitigates the exploitation and you have made it available, the 14 days have started, whether or not the code fix is ready. Teams that assume the clock waits for the release will be late.

The date you have to record is when the measure became available, not when you shipped it. A patch that is built on Monday, published on Wednesday and announced on Friday: the honest reading is Wednesday, the day a user could obtain it. Write that day down at the time, because in the final report you will be describing it.

What that means for an incident

Article 14(4)(c) runs from the submission of the 72-hour notification, and the period is "one month", a calendar month rather than 30 days. The final report does not have a deadline until the notification is filed, and once it is, the deadline is fixed by the filing time and nothing else.

Calendar months have an edge case that a spreadsheet gets wrong. A notification submitted on 31 January is answered by 28 February (29 in a leap year), because 31 February does not exist and the month ends where it ends. Software that adds 30 days lands on 2 March; software that adds a month with naive date arithmetic rolls over into March. Both quietly hand you days you do not have. Our calculator clamps to the end of the month, and it is the same function the product runs rather than a copy written for the page.

Why awareness is still the moment that matters most

None of this makes the awareness timestamp less important. It anchors two of the three deadlines on both tracks, and the Commission's guidance of 27 July 2026 puts the bar for awareness at a reasonable degree of certainty that a vulnerability in your product is being actively exploited: not the first rumour, not completed forensics. "Actively exploited" itself is defined in Article 3(42) as a vulnerability "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner", which rules out theoretical vulnerabilities and unexploited proofs of concept.

So the record you need is three timestamps, not one:

1. when you became aware, in the Commission's sense;
2. when you submitted the 72-hour notification;
3. when a corrective or mitigating measure became available.

The first starts the early warning and notification clocks. The second starts the incident final report. The third starts the vulnerability final report. A procedure that captures only the first will produce a confident and wrong final report date, and a company that misses the real one is in the top penalty tier under Article 64(2), alongside the Annex I requirements themselves.

The short version to put in your procedure

• 24 hours and 72 hours run from awareness, on both tracks.
• The vulnerability final report runs 14 days from a corrective or mitigating measure being available. Until one is, there is no deadline, and you should say so rather than print one.
• The incident final report runs one calendar month from the 72-hour notification.
• Record all three anchor moments as they happen, because the report will ask for them.

Where the report goes is the other half of the question, and the answer is a specific team in a specific member state, chosen by a rule about your company rather than about the incident.

Sources

• Regulation (EU) 2024/2847, Article 14(1) to (4), read from the consolidated text on EUR-Lex; Article 3 for the definition of an actively exploited vulnerability; Article 64(2) for the penalty tier; Article 71(2) for the application date.
• European Commission guidance C(2026) 5252 of 27 July 2026, on the meaning of awareness and of active exploitation.

This is not legal advice. Article 14 is short, and the paragraph references above are so you can check the reading rather than take it.