Europe Starts a 24-Hour Clock for Exploited Vulnerabilities
Article 14 of the Cyber Resilience Act has applied since 11 September 2026: manufacturers report actively exploited vulnerabilities and severe incidents within 24 hours, then 72 hours, then
TL;DR
- The Cyber Resilience Act is the EU regulation that sets cybersecurity requirements for products with digital elements sold in the European Union, and Article 14 is the part that obliges manufacturers to report exploited vulnerabilities and severe incidents to national authorities.
- Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, has applied since 11 September 2026, while the rest of the regulation waits until 11 December 2027.
- Two events start the clock: an actively exploited vulnerability in a product with digital elements, and a severe incident affecting the security of that product. A published CVE on its own does not.
- The sequence is fixed: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure becoming available, or within one month of the 72-hour notification for a severe incident.
- Reporting happens once, through ENISA's CRA Single Reporting Platform, addressed to the coordinating CSIRT of the member state where the manufacturer has its main establishment and made available simultaneously to ENISA.
- The Article 69(3) derogation reaches products placed on the market before 11 December 2027 whether or not they are ever substantially modified, so a catalogue sold years ago belongs in scope.
- The penalty ceiling of 15 million euro or 2.5 per cent of worldwide turnover arrives with the rest of the regulation in December 2027, fifteen months after the duty itself.
- The deadlines run in calendar hours counted from awareness, so a verification finished on Friday evening places the early warning at Saturday evening at the latest, weekends and holidays included.
- The escalation path the deadline assumes is organisational: name the competent coordinating CSIRT, decide who can classify a fact as an actively exploited vulnerability and start the clock, keep a product inventory that doubles as the upstream contact list, and timestamp the receipt of each report and the assessment that concluded.

What changed on 11 September 2026
The European Commission's own page states it plainly: "As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements." The same page records the asymmetry inside the regulation. Article 71 of Regulation (EU) 2024/2847 does not switch everything on at once: Chapter IV, on the notification of conformity assessment bodies, applied from 11 June 2026, Article 14 on manufacturer reporting applied from 11 September 2026, and the regulation as a whole applies from 11 December 2027.
That ordering has a practical consequence beyond the calendar. The duty to report arrives fifteen months before the penalty regime that backs it and before market surveillance starts, which means the obligation is real from the first day even though its enforcement teeth arrive later. The Commission's page also settles who reports what: manufacturers report now, and open-source software stewards carry their own reporting obligations under Article 24(3) from 11 December 2027.
Two triggers decide whether the clock starts
Article 14 applies to two situations, and the practitioner guidance is careful about both. The first is an actively exploited vulnerability: a vulnerability contained in the product for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. The second is a severe incident, defined in Article 14(5) as an incident that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions, or that has led or could lead to the introduction or execution of malicious code.

Everything else stays in ordinary vulnerability handling. A published CVE is not a trigger, even at a high severity score, as long as no exploitation of the product is known. Server-scanner findings, internally discovered vulnerabilities and penetration-test results belong to internal remediation. The Commission's July guidance adds a definition worth designing around: awareness begins once an initial assessment gives the manufacturer a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has occurred. The assessment itself is not optional, and it is the step that determines when the 24 hours start running.
The three deadlines, counted from awareness
The sequence is short, and each stage has a defined content. The early warning is due without undue delay and in any event within 24 hours of becoming aware, and carries basic identification: the notification type, the manufacturer or steward name, the product and a title, plus the member states where the product has been made available where that is already known, and for incidents whether unlawful or malicious acts are suspected. The fuller notification is due within 72 hours and adds the general nature of the vulnerability and of the exploit, an initial assessment, the corrective or mitigating measures taken and the measures users can take, along with the sensitivity the manufacturer attaches to the information.
The final report closes the case. For a vulnerability it is due no later than 14 days after a corrective or mitigating measure becomes available, which is a deadline attached to the fix rather than to the incident; for a severe incident it is due within one month of the 72-hour notification. The guidance is explicit that these are calendar hours: a verification finished on Friday evening puts the early warning at Saturday evening at the latest, holidays included. Two further duties run alongside the filing. Under Article 14(8) the manufacturer must inform affected users, and where appropriate all users, without undue delay, and if it does not, the CSIRTs that received the notification may do so instead. Where the exploited component came from a third party, the manufacturer must also notify that component's manufacturer or maintainer.

The transitional rule that reaches products already sold
This is the part of the regulation most likely to be read past. Article 69(2) sets the general transitional rule: products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified after that date, which reads as a comfortable exemption for an existing catalogue. Article 69(3) then makes an express derogation for Article 14, and the practitioner analysis is blunt about the effect: the reporting obligations apply to all in-scope products with digital elements placed on the market before 11 December 2027, whether or not they are ever modified.
The two rules therefore run on different axes. A product shipped in 2025 may never need CE marking under the Act, and still be reportable if a vulnerability in it is actively exploited and the manufacturer becomes aware of that on or after 11 September 2026. There is no retroactivity in the other direction: exploitation the manufacturer already knew about before the reporting date does not have to be notified, because the duty attaches to the moment of awareness.
Building the escalation path the deadline assumes
A 24-hour deadline is an organisational requirement before it is a technical one, and the analysis is direct about where the risk sits: the first notification is often filed late because a security team establishes active exploitation without anyone knowing that an external filing clock exists, or because the legal function learns of a confirmed exploitation only after the window has closed. The order of work that follows from the sources is unglamorous. Identify which coordinating CSIRT is competent on the basis of the EU main establishment. Confirm who inside the organisation can characterise a fact as an actively exploited vulnerability and start the clock. Keep an inventory of supported products that fall in scope, including the ones sold years ago, because that inventory is also the contact list for the upstream notification duty. Timestamp the receipt of every report and the moment the assessment concluded, since that is what "becoming aware" is measured against. And treat the case file as something that will be requested later: the CSIRT may ask for status updates at any time, and a maintained timeline turns that request into an export.

For teams that run their own infrastructure, the same discipline shows up on the monitoring side. A reporting chain that depends on someone noticing an exploitation eventually fails on detection latency, which is where infrastructure monitoring with plain-language alerts does its part: the CRA clock starts when the organisation knows, and knowing earlier is the only stage that can be improved in advance. Our reading of the GTIG exploitation data describes the volume that makes triage the scarce skill, and the Ubuntu container escape is a useful case study of a public exploit arriving before a patch, which is precisely the condition Article 14 is written for.
Sources
Source: Cyber Resilience Act — Reporting obligations — digital-strategy.ec.europa.eu/en/policies/cra-reporting, European Commission, retrieved 2026-10-06 (the requirement from 11 September 2026 for manufacturers to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements, the early warning within 24 hours and full notification within 72 hours, the final report no later than 14 days after a corrective measure is available or within a month of the 72-hour notification for severe incidents, reporting once through the CRA Single Reporting Platform addressed to the CSIRT of the main establishment and made available simultaneously to ENISA, the CSIRT sharing with other CSIRTs where the product has been made available, the SRP operational as of 11 September 2026 established by ENISA under Article 16, and open-source software stewards subject to reporting obligations under Article 24(3) from 11 December 2027 in accordance with Article 71(2)). Source: CRA Reporting: 24h, 72h and 14-day deadlines (Article 14) — cyberresilienceact.eu/reporting.html, retrieved 2026-10-06 (the two triggers of an actively exploited vulnerability and a severe incident, the criteria in Article 14(5), the three-stage sequence with the clock running in calendar hours including weekends and public holidays, the Article 69(3) derogation applying Article 14 to all in-scope products placed on the market before 11 December 2027, the absence of retroactivity for exploitation known before 11 September 2026, the contents of the 24-hour, 72-hour and final reports, the limited availability of particularly exceptional circumstances treatment on the 72-hour notification of an exploited vulnerability, and the platform accepting only mandatory notifications under Articles 14 and 24). Source: Cyber Resilience Act: reporting starts 11 September 2026 — lawandtechnology.eu, retrieved 2026-10-06 (Article 71's three commencement dates with Chapter IV from 11 June 2026 and Article 14 from 11 September 2026, the Article 64 ceiling of 15 million euro or 2.5 per cent of worldwide annual turnover applying with the rest of the regulation from 11 December 2027 and therefore fifteen months after the duty to report, the Article 69(2) substantial-modification rule and the Article 69(3) express derogation, the Article 14(8) duty to inform users and the CSIRT's power to inform them if the manufacturer does not, the requirement to notify through the coordinating CSIRT of the member state of main establishment simultaneously to ENISA, the Article 14(10) implementing act on notification formats not yet adopted as at 31 July 2026, the Commission guidance published on 27 July 2026 as Communication C(2026) 5252, and the state of the implementing acts). Source: The CRA's September 11 Reporting Deadline — interlynk.io/resources/cra-september-2026-reporting-deadline, retrieved 2026-10-06 (the reporting obligation covering products already placed on the EU market, the meaning of becoming aware as an initial assessment giving a reasonable degree of certainty, the three-stage timeline, and the requirement to notify the manufacturer or maintainer of an affected third-party component).
Source: European Commission CRA reporting page — digital-strategy.ec.europa.eu, retrieved 2026-10-06; Article 14 deadline guidance — cyberresilienceact.eu, retrieved 2026-10-06; legal analysis of the commencement and transitional provisions — lawandtechnology.eu, retrieved 2026-10-06; manufacturer summary of the September deadline — interlynk.io, retrieved 2026-10-06. Figures: screenshots of the official Commission reporting page and ENISA's Single Reporting Platform page, captured 2026-10-06, plus two Netics editorial diagrams rendered from the same sources.