What Article 14 asks for
- Actively exploited vulnerability (Article 14(2)(c)): at least a description of the vulnerability, including its severity and impact; where available, information about any malicious actor that exploited or is exploiting the vulnerability; and details about the security update or other corrective measures made available to remedy the vulnerability.
- Severe incident (Article 14(4)(c)): at least a detailed description of the incident, including its severity and impact; the type of threat or root cause likely to have triggered the incident; and applied and ongoing mitigation measures.
Both provisions require the final report unless the relevant information has already been provided.
This page does not describe an official submission form. Use what ENISA's Single Reporting Platform asks for when you submit.
Start with the correct clock
For an actively exploited vulnerability, the clock starts when a corrective or mitigating measure is available, not when you became aware. Record when the security update, workaround, configuration change or other measure became available.
For a severe incident, the clock starts from the 72-hour incident notification. Record when that notification was submitted, not just when the team first became aware. CRA Article 14 reporting deadlines explained
Case record for an actively exploited vulnerability
- affected product or product family;
- affected versions, components, firmware, builds or services;
- description of the vulnerability, its severity and impact;
- what is known about exploitation;
- where available, information about a malicious actor that exploited or is exploiting the vulnerability;
- the security update or other corrective measure made available, and when;
- user remediation instructions;
- evidence supporting the timeline and impact assessment;
- remaining open follow-up, if any.
Keep it factual. If malicious-actor information is not available, record that rather than inventing certainty.
Case record for a severe incident
- affected product or product family;
- incident timeline;
- detailed incident description, its severity and impact;
- affected users, systems, functions or data as currently understood;
- type of threat or likely root cause;
- applied mitigation measures and ongoing mitigation measures;
- user or customer communication status;
- evidence supporting the root-cause and impact assessment;
- remaining corrective actions and owners.
If the root cause is still under investigation, be precise about what is likely, what is confirmed and what remains open.
Reconcile what you already submitted
Before submitting, compare the final report against:
- the 24-hour early warning;
- the 72-hour vulnerability or incident notification;
- any status update the coordinating CSIRT asked you for;
- your internal incident record and user communication record;
- the security update or mitigation release notes.
The goal is not to repeat every sentence. It is to avoid gaps, contradictions and outdated facts across the reporting chain. CRA 24-hour early warning: what to send first · CRA 72-hour notification: what to include
Keep the reporting route in the case file
Article 14 reports go through ENISA's Single Reporting Platform to the CSIRT designated as coordinator. Under Article 14(7) that is the CSIRT of your main establishment in the EU, where decisions on the cybersecurity of your products are mainly taken. With no main establishment in the EU, the order is the Member State of the authorised representative, then the importer, then the distributor (in each case the one handling the highest number of your products), then the Member State where most of your users are. The final report comes late in the chain, but the record should still show who filed, where and when. Which CSIRT do you notify under CRA Article 14?
Questions people ask
- When is the CRA final report due?
- For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available. For a severe incident, within one month after the 72-hour incident notification. In both cases the final report is required unless the relevant information has already been provided.
- What goes in the final report for an actively exploited vulnerability?
- Article 14(2)(c) asks for at least a description of the vulnerability, including its severity and impact; where available, information about any malicious actor that exploited or is exploiting the vulnerability; and details about the security update or other corrective measures made available to remedy the vulnerability.
- What goes in the final report for a severe incident?
- Article 14(4)(c) asks for at least a detailed description of the incident, including its severity and impact; the type of threat or root cause likely to have triggered the incident; and applied and ongoing mitigation measures.
- Is the final report the same for vulnerabilities and incidents?
- No. The two tracks close on different dates and ask for different facts. The vulnerability report is tied to when a corrective or mitigating measure is available; the incident report is tied to when the 72-hour incident notification was submitted.
- Does VexRoute file the official final report?
- No. Article 14 reports are submitted through ENISA's Single Reporting Platform. VexRoute's free desk helps you track the final-report deadline and keep your case record in one place.