Reporting an exploited vulnerability within 24 hours
Updated 27 October 2026
Since 11 September 2026, a manufacturer that learns a vulnerability in its product is actively exploited must report it within 24 hours. Here is the process, what each submission contains, and templates ready to fill in.
When do you have to report?
Article 14 of the CRA covers two situations:
- An actively exploited vulnerability: there is reliable evidence that an attacker exploited the flaw on a system without its owner’s permission. A flaw that was only discovered, or fixed before any exploitation, is not reported on this basis.
- A severe incident affecting the product’s security: it compromises or may compromise the availability, authenticity, integrity or confidentiality of the product’s data or functions, or allows malicious code to be introduced.
The deadline runs from the moment the manufacturer becomes aware of the exploitation or incident. An alert received on Friday evening must be able to go out on Saturday.
The three steps
| Step | Deadline | Expected content |
|---|---|---|
| Early warning | 24 hours | The exploited vulnerability (or the incident, stating whether it seems caused by a malicious act) and, where known, the Member States where the product is available. |
| Notification | 72 hours | General information about the product, nature of the exploit and the vulnerability, corrective measures taken and measures users can take, how sensitive you consider the information. |
| Final report | 14 days after a fix is available (vulnerability) · 1 month after the notification (incident) | Description of the vulnerability, severity and impact, information on the attacker where known, details of the fix. For an incident: root cause, type of threat, measures applied and ongoing. |
The process, step by step
- 1. Qualify. Confirm the exploitation (KEV, CERT, customer, logs) and identify the affected products and versions with the SBOM.
- 2. Send the early warning on ENISA’s single reporting platform. One submission is enough: it reaches the coordinating CSIRT of your country (in France, ANSSI’s CERT-FR; in Germany, the BSI) and ENISA at the same time.
- 3. Complete within 72 hours with the notification: product, versions, nature of the flaw, workarounds.
- 4. Inform affected users without undue delay of the vulnerability or incident and the measures to take, if needed in a structured, machine-readable format.
- 5. Fix, release the security update, then send the final report within 14 days.
The CSIRT may ask for an intermediate report. Keep a dated record of each step: it is what the authority will ask for in an inspection.
Downloadable templates
Three plain-text templates to fill in, then copy into the reporting platform’s form. They follow the fields required by Article 14, for an exploited vulnerability and for a severe incident.
- Early warning (24 h) Download · .txt
- Notification (72 h) Download · .txt
- Final report Download · .txt
With CheckOps
When a vulnerability from the KEV catalog, or marked exploited in the EUVD, affects a version of your products, CheckOps opens a CRA report with its three deadlines, prefills the fields (product, versions, component, CVE, available fix) and warns you before each deadline. The texts export for ENISA’s platform and the history stays in the technical file.
Frequently asked questions
Can a small company be fined for missing the 24 hours?
Not for the early warning alone: the CRA excludes fines against micro and small enterprises for that deadline. The 72-hour and final report deadlines, and the obligation to report, still apply to them.
Do I have to report a flaw found internally and never exploited?
Not under Article 14. It is fixed as part of vulnerability handling; you may also report it voluntarily to the CSIRT.
Source: Regulation (EU) 2024/2847, Official Journal of the European Union of 20 November 2024. This guide summarises the text and is not legal advice. Read the regulation on EUR-Lex