1. Confirm the clock before you write
- Case type is set: actively exploited vulnerability or severe incident.
- Awareness date/time is recorded (who decided it, and why).
- For a vulnerability: date/time a corrective or mitigating measure became available is recorded (starts the 14-day final-report clock).
- For a severe incident: date/time the 72-hour incident notification was submitted is recorded (starts the one-month final-report clock).
- Final-report due date is calculated and on a calendar. Open the deadline calculator
- You have decided whether relevant information was already provided (if yes, the case file states what and when).
2. Shared close-out checks (both tracks)
- 24-hour early warning submission reference and time are in the case file.
- 72-hour notification submission reference and time are in the case file.
- Earlier reports and any CSIRT status update under Article 14(6) were reconciled — no contradictions on product, versions, impact or mitigations.
- Users informed under Article 14(8) where required, with notice date and channel recorded. User notification guide
- Coordinating CSIRT route under Article 14(7) is still correct for this manufacturer. Which CSIRT?
- Evidence supporting timeline, impact and measures is linked or attached. Evidence log
- Assigned Representative who will submit on the SRP is named and available.
3. Actively exploited vulnerability — Article 14(2)(c) contents
Due no later than 14 days after a corrective or mitigating measure is available, unless already provided. Narrative context: final report deadlines and contents.
- Description of the vulnerability, including its severity and impact.
- Where available, information about any malicious actor that exploited or is exploiting the vulnerability (or an explicit note that none is available).
- Details about the security update or other corrective measures made available to remedy the vulnerability (version, release date, how users get it).
- Affected product and versions match the early warning and vulnerability notification.
4. Severe incident — Article 14(4)(c) contents
Due within one month after the 72-hour incident notification, unless already provided.
- Detailed description of the incident, including its severity and impact.
- Type of threat or root cause likely to have triggered the incident.
- Applied and ongoing mitigation measures.
- What is confirmed vs still under investigation is labelled clearly (no invented certainty).
5. After you submit
- SRP submission confirmation saved in the case file.
- Internal owners know the notification can no longer be edited after the final report.
- Any remaining product or process follow-up has an owner and a date.
- Browser or shared backup of the case record is exported for retention.
Questions people ask
- Is this the official CRA final report form?
- No. Official submission is through ENISA's Single Reporting Platform. This checklist helps you confirm deadlines, Article 14 contents and your case record before you open the platform.
- When is the final report due for an actively exploited vulnerability?
- No later than 14 days after a corrective or mitigating measure is available, unless the relevant information has already been provided (Article 14(2)(c)).
- When is the final report due for a severe incident?
- Within one month after the 72-hour incident notification, unless the relevant information has already been provided (Article 14(4)(c)).
- Do I still need a final report if I already sent everything?
- Article 14 says the final report is required unless the relevant information has already been provided. Record what was already filed and what remains, so the case file shows why you closed or continued the chain.
- Can VexRoute file the final report for me?
- No. The free desk tracks the final-report deadline and keeps draft text in your browser. You still submit through ENISA's Single Reporting Platform.