This page reflects our reading of Cyber Resilience Act, Article 14(2) as of . It is not legal advice. Review process.
The final report closes out the case. Its deadline is the one place a vulnerability case and an incident case genuinely diverge — get this distinction right before you start drafting:
- Vulnerability case: due 14 days from the corrective or mitigating measure becoming available — not from awareness, and not from notification.
- Incident case: due 1 calendar month from when the 72-hour notification was submitted, clamped to the end of the month if the calendar date doesn't exist (a notification submitted on 31 January is due 28 or 29 February, not 3 March).
Before you start
- You need a case in
notification_submitted. If you haven't filed the notification yet, see File the 72-hour notification. - For a vulnerability case, you need a corrective or mitigating measure's availability date recorded — the final deadline can't be computed without it, and the case shows why the countdown isn't running until you do.
- You need
cases.submitpermission.
Steps
- Open the case. If it's a vulnerability case and the fix-availability date isn't recorded yet, record it now — that's what starts this deadline.
- Click Start final report. The case moves to
final_drafting. - Declara pre-fills what it can from your product, case, and prior-stage data. Review every field. If anything changed since you filed the notification, this is where the correction is carried forward — there's no way to edit a submitted stage directly.
- Click Generate packet for the HTML view and PDF.
- Copy the packet fields into the CRA Single Reporting Platform web form yourself.
- Return to the case and click Mark submitted, with an SRP reference number or an offline-filing note.
What you should see
The case moves to final_submitted, then to closed. This is a terminal state —
the case doesn't move again.
Which deadline applies to your case
Check the case's type before you assume which basis governs the final report. A vulnerability case that's mistakenly treated as running on the 1-month incident basis (or vice versa) will show the wrong countdown. If the case type looks wrong, that's a data problem to fix before drafting, not something to work around in the packet.