CRA Article 14 Incident Reporting: A Step-by-Step Guide
Article 14 of the CRA introduces legally binding timelines for reporting actively exploited vulnerabilities to ENISA. Miss a deadline and you face enforcement action. This guide explains exactly what to report, when, and how.
When do Article 14 obligations apply?
Article 14 reporting obligations apply from 11 September 2026 — fifteen months before the full CRA compliance date of December 2027. This early start date was inserted to give ENISA time to build and operate the European Vulnerability Database (EUVD) and for manufacturers to establish internal reporting processes.
Article 14 is triggered when a manufacturer becomes aware that a vulnerability in one of their products is being actively exploited. This is distinct from discovering a vulnerability that is not yet exploited — those must still be remediated under Annex I Part II, but the 24h/72h timelines do not apply.
What counts as "actively exploited"?
A vulnerability is actively exploited when there is credible evidence that a threat actor has used the vulnerability against at least one real target in the wild. This includes: confirmed exploitation attempts in your product telemetry, CISA KEV catalogue listings, ENISA or national CSIRT alerts, or credible threat intelligence from your vendors or ISAC. Proof-of-concept exploits alone may not constitute active exploitation — context matters.
The Article 14 Reporting Timeline
Manufacturer becomes aware
The clock starts when the manufacturer first has reason to believe that a vulnerability in their product is being actively exploited in the wild. This could be via internal monitoring, a researcher disclosure, a CSIRT notification, or media reporting.
Early Warning to ENISA
Submit an early warning via the EUVD platform (euvdb.europa.eu). The early warning must indicate: (1) the product concerned, (2) that an exploited vulnerability has been identified, and (3) a preliminary description. This is a heads-up — detailed analysis is not yet required.
Detailed Report
Submit a detailed report updating the early warning with: full product identification (name, version, affected components), CVE identifier if assigned, severity assessment (CVSS score), current exploitation status, geographic scope of exploitation, mitigation advice or workarounds already deployed, and corrective action timeline.
Final Report
Once the vulnerability is remediated and a security update is available, submit a final report confirming: the root cause of the vulnerability, the corrective action taken, the security update version, and the distribution mechanism (auto-update, advisory, etc.). The final report closes the incident in the EUVD system.
Where to Submit Reports
Reports must be submitted to ENISA via the European Vulnerability Database (EUVD) at euvdb.europa.eu. Manufacturers must register for an EUVD account in advance — do not wait until you have an incident.
In parallel, you must notify the national CSIRT of the member state where you are established. Each EU member state has a designated CSIRT — a list is maintained by ENISA. Many CSIRTs have their own reporting portals; some accept reports by email.
Where a vulnerability may affect critical infrastructure or critical entities under NIS2, you may also need to coordinate with the relevant competent authority under that directive. CRA and NIS2 reporting are separate obligations — meeting one does not automatically satisfy the other.
What to Include in Each Report
- Product name and version
- Nature of the incident (exploited vulnerability)
- Preliminary impact assessment
- Any immediate mitigations applied
- CVE identifier (if assigned)
- CVSS score and vector
- Affected component(s) from SBOM
- Exploitation status and scope
- Geographic spread
- Root cause analysis (preliminary)
- Fix timeline estimate
- Root cause (confirmed)
- Security update version
- Update distribution method
- Date patch became available
- User communications sent
- Lessons learned summary
Building an Internal Incident Response Process
To meet the 24-hour early warning window reliably, manufacturers need a functioning detection and escalation process before an incident occurs. Key elements include:
- Monitoring: Subscribe to vulnerability feeds (NVD, ENISA, GitHub Advisory) for all SBOM components. Enable telemetry on deployed products where technically feasible.
- Escalation: Define who has authority to trigger an Article 14 notification. Delays often happen when no one owns the decision.
- Templates: Prepare draft report templates in advance. Under pressure, you do not want to work out what fields ENISA needs for the first time.
- Communication: Prepare a user notification template that can be issued promptly alongside the ENISA early warning.
- Rehearsal: Run a tabletop exercise before September 2026. Simulating an exploited vulnerability will expose gaps in your process while there is still time to fix them.
CRAReady's Incident Reporting module manages all three Article 14 stages with automated deadline alerts — early warning, detailed report, and final report workflows built in.
Need help implementing this? Try CRAReady →