ENISA 24-hour reporting under the CRA: exact steps when a vulnerability is exploited
From 11 September 2026, manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours. What triggers the duty, the 24h/72h/final-report sequence, what each notification contains, and how to be ready before it happens.
Not sure if you’re in scope?
Run the free 3-minute scope check for your product and get your risk class, deadlines and obligations.
Check if the CRA applies to youOf everything the Cyber Resilience Act introduces, the reporting obligation is the part that changes your operations first — and the part you cannot improvise. From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product has 24 hours to file an early warning. Not 24 business hours. Not "as soon as reasonably possible." Twenty-four hours, weekends included.
This guide walks through exactly what triggers the duty, what you file when, and the small amount of preparation that makes the difference between a routine notification and a missed deadline.
Not sure the CRA applies to your product? Run the free scope check first.
What triggers the reporting duty
Two events, defined in Article 14 of the regulation:
- An actively exploited vulnerability in your product — meaning there is evidence someone is using it in the wild, not merely that a CVE exists. A published vulnerability nobody is exploiting does not trigger a report (you still have to fix it under your vulnerability-handling duties, but the 24-hour clock doesn't start).
- A severe incident having an impact on the security of the product — for example a compromise of your update infrastructure or build pipeline.
The duty applies to products already on the market, including everything you shipped before 2026. And "becoming aware" is a low bar: a customer email, a researcher's disclosure, a post naming your product, an alert from your own monitoring — any of these can start the clock at any hour.
The reporting sequence
All notifications go through the single reporting platform to ENISA and the CSIRT of your member state:
| Deadline | What you file | What it contains |
|---|---|---|
| Within 24h of awareness | Early warning | That an actively exploited vulnerability (or severe incident) exists; the member states where the product is available. Minimal by design — you are not expected to have answers yet. |
| Within 72h | Vulnerability / incident notification | General information about the product, the nature of the exploit, any corrective or mitigating measures taken or available, and — for vulnerabilities — technical details where known. |
| Within 14 days (vulnerability) or 1 month (incident) | Final report | Full description, severity and impact, root cause where established, and the corrective measures rolled out. |
Two practical notes. First, the early warning is deliberately lightweight: regulators would rather hear "we know something is wrong" in hour 20 than a polished report in hour 40. File early with what you have. Second, for vulnerabilities the clock pauses on nothing — coordinate your fix and your disclosure in parallel, not in sequence.
What "ready" actually means
Teams that miss the window don't miss it because the form is hard. They miss it because hour 1–20 disappears into questions that should have been answered in advance:
1. Who owns this? One named person files the notification, with one named backup. Decided now, written down, with their contact details — not discussed in the incident channel while the clock runs.
2. Does this affect us? You cannot assess a vulnerability report against your product without knowing what's inside it. An up-to-date SBOM turns "are we affected?" from days of archaeology into minutes of lookup.
3. Where does the report go? Know your national CSIRT in advance (in Belgium the CCB, in Germany BSI/CERT-Bund, in the Netherlands NCSC-NL, and so on) and have the reporting platform bookmarked with an account where registration is possible.
4. What do we say? Pre-filled templates with your company details, product identifiers and support contacts mean the 24-hour filing is a fill-in exercise, not a writing exercise.
5. Have we rehearsed once? A one-hour drill — fake vulnerability, run the playbook, file a mock notification internally — surfaces every gap while it's free to fix. Do it before September, not during your first real incident.
What happens if you don't report
Non-compliance with the reporting obligations carries fines up to €10 million or 2% of worldwide turnover (the general CRA maximum of €15M/2.5% applies to the core product requirements). But the sharper consequence is practical: a missed notification discovered later — by a market surveillance authority, or by a customer's lawyers after an incident — converts a manageable security event into a regulatory one.
There is also a quiet upside to doing this well: the same readiness (SBOM, monitoring, a rehearsed playbook) is most of what the December 2027 full-compliance deadline demands anyway. September is not an extra project; it's the first milestone of the one project. Our compliance checklist sequences the whole path.
The one-page playbook, summarised
- Awareness (any channel, any hour) → responsible person notified immediately
- Hour 0–4: assess against the SBOM — are we affected, is it exploited?
- Hour 4–20: file the early warning via the reporting platform (ENISA + national CSIRT)
- Hour 24–72: investigate, mitigate, file the 72h notification
- Day 3–14: fix, roll out the security update, file the final report
- Log everything — the trail is part of your technical documentation
Get the foundation in place before September: check your product's scope and class free — three minutes, no signup.