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.
Screenshot of the European Commission's official Cyber Resilience Act reporting page (digital-strategy.ec.europa.eu/en/policies/cra-reporting, captured 2026-10-06): the regulation's own description of who must report, within what window and through which platform.
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.
Netics editorial diagram of the reporting sequence as described in the Commission's page and the practitioner guidance: the clock runs from verified awareness, and the first two stages differ only in how much detail they carry.
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.
Screenshot of ENISA's official Single Reporting Platform page (enisa.europa.eu, captured 2026-10-06): the single route through which manufacturers file the early warning, the notification and the final report.
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.
Netics editorial warning card on the transitional provisions: the substantial-modification exemption in Article 69(2) governs the conformity obligations, while Article 69(3) carves the reporting duty out of it.
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.
Originally published on the Netics blog.
Top comments (0)