CRA vulnerability reporting: the 24-hour, 72-hour, and 14-day clocks (Article 14)
From 11 September 2026 manufacturers must report actively exploited vulnerabilities within 24 hours of awareness. How the Article 14 early warning, 72-hour notification, and final report work, and why the hard part is operational.
From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting the product's security, must file an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days for exploited vulnerabilities or 1 month for severe incidents. Reports go to the CSIRT designated as coordinator and to ENISA.
That is Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, in one paragraph. The regulation entered into force on 10 December 2024, and this reporting obligation is the first hard deadline on the calendar, arriving more than a year before the full essential requirements apply on 11 December 2027. For the broader requirement set, see our Cyber Resilience Act framework page; for how the dates fit together, see the CRA timeline.
What are the three Article 14 clocks?
All three clocks start at the same moment: when you become aware. They are cumulative stages of one report, not three separate incidents.
| Clock | Deadline from awareness | What you file |
|---|---|---|
| Early warning | 24 hours | A first signal that a vulnerability in your product is being actively exploited, or that a severe incident has occurred. Minimal detail, enough to trigger coordination. |
| Notification | 72 hours | General information about the product, the nature of the exploitation or incident, and any corrective or mitigating measures taken or available to users. |
| Final report | 14 days (actively exploited vulnerability) or 1 month (severe incident) | A description of the issue and its severity and impact, what is known about exploitation, and the corrective measures or security update made available. |
The two final-report deadlines are the detail teams most often get wrong: 14 days for an actively exploited vulnerability, 1 month for a severe incident. Everything upstream of the final report is identical for both.
Who do the reports go to?
To the CSIRT designated as coordinator for your member state and to ENISA. Submission runs through the single reporting entry point that ENISA operates, so in practice you file once and both recipients receive it. Non-EU manufacturers selling into the EU carry the same obligation; where you are headquartered does not change the clock, as we cover in does the CRA apply outside the EU.
What does "becoming aware" actually mean?
Operationally, it means the first moment anyone in your organisation has knowledge of the active exploitation or the incident, through any channel. A researcher emailing your coordinated-disclosure address, a customer support ticket describing compromised devices, an entry appearing in an exploited-vulnerabilities catalog for a component you ship, or your own telemetry flagging anomalous behaviour all start the clock. Two consequences follow. First, awareness is organisational, not departmental; a report sitting unread in a support queue for three days does not delay the deadline. Second, the 24 hours are calendar hours. Vulnerabilities are published and exploited on Fridays and holidays, and the clock runs through the weekend.
What must be in each report?
The stages are deliberately proportionate to how much you can know at each point.
- The early warning (24 hours) exists to get coordination moving, not to be complete. You indicate that a vulnerability in your product is being actively exploited, or that a severe incident has occurred, and where relevant which member states are affected. Filing an early warning with incomplete information is expected; missing the window is the failure mode.
- The notification (72 hours) fills in the picture: which product and versions are affected, the general nature of the exploit or incident, its severity, and the corrective or mitigating measures you have taken or that users can take in the meantime.
- The final report (14 days or 1 month) closes the loop: a full description of the vulnerability or incident, its severity and impact, information about the exploitation or malicious actor where available, and the security update or other corrective measures you have made available.
Why is this an operations problem, not a legal problem?
Because every input to those reports is produced by engineering and operations, not by counsel. To file a credible early warning within 24 hours you need three capabilities running before anything happens: detection that recognises active exploitation against components you have actually shipped, triage that can tell within hours which fielded devices and firmware versions are affected, and a drafting pipeline that turns that triage into a submission, including on a Saturday. A lawyer can review a report in an hour; nobody can reconstruct three years of component inventory in one. This is the same conclusion as our CRA compliance checklist, where the reporting process is the item most teams are missing, and it is one place where automation genuinely changes the shape of the work, which is why Scadable's Watchtower exists.
What do I owe my users?
Reporting to authorities is only half of Article 14. Manufacturers must also inform impacted users, and where appropriate all users, about the actively exploited vulnerability or severe incident and about corrective measures they can apply, without undue delay. In practice that means your reporting pipeline needs a user-facing branch: an advisory, the affected versions, and the update or mitigation, published in step with the fix rather than months later. If your product cannot deliver that fix to fielded devices, the advisory is an admission rather than a remedy, which is why the update mechanism and the reporting process belong to the same pipeline. The same evidence also feeds your technical file, covered in CRA technical documentation.
How should a team prepare before 11 September 2026?
Work backwards from the 24-hour report. Inventory what you have shipped, keep an SBOM per product line, wire exploitation-aware monitoring to it, name an owner for the reporting decision, and run one full drill: simulated awareness on a Friday evening, early warning drafted within 24 hours, notification within 72. Teams that have run the drill once tend to find the gaps are in data availability, not in willingness.
Frequently asked questions
What is Article 14 of the Cyber Resilience Act? Article 14 sets the manufacturer reporting obligations. From 11 September 2026, an actively exploited vulnerability in your product, or a severe incident affecting its security, must be reported on a fixed clock, starting with an early warning within 24 hours of becoming aware.
What are the CRA reporting deadlines? Three clocks run from the moment of awareness. An early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days for an actively exploited vulnerability or within 1 month for a severe incident.
Who do CRA reports go to? To the CSIRT designated as coordinator for your member state and to ENISA, submitted through the single reporting entry point ENISA operates. You file once and the submission reaches both.
When does the 24-hour clock start? When the manufacturer becomes aware, through any channel. A support ticket, a researcher email to your disclosure address, an internal detection, or a customer call all count. The clock does not wait for legal review or for the issue to be confirmed exploitable in your lab.
Do I have to report every CVE in my product? No. The Article 14 clock triggers on active exploitation of a vulnerability in your product, or on a severe incident affecting its security, not on every disclosed CVE. You still need monitoring good enough to recognise active exploitation quickly, because awareness starts the clock.
Do I also have to tell my users? Yes. Alongside the CSIRT and ENISA reports, manufacturers must inform impacted users, and where appropriate all users, about the vulnerability or incident and about corrective measures they can apply, without undue delay.
Where Scadable fits
Scadable is the compliance engine for connected-product companies, and its Watchtower runs this exact pipeline: a continuous KEV and OSV sweep against the components you have actually shipped, incident clocks that start at awareness, staged drafts for the 24-hour, 72-hour, and final reports, and the fix moving in parallel so the final report has something to say. It identifies what is actively exploited, fixes it, files the report, and keeps you certified. Run the free two minute CRA readiness check to see which obligations apply to your product, or book a walkthrough.