Regulation (EU) 2024/2847, known as the Cyber Resilience Act, applies for the most part on 11 December 2027. One obligation arrives fifteen months earlier: from 11 September 2026, Article 14 requires manufacturers to notify actively exploited vulnerabilities and severe incidents affecting the security of their products. The deadlines are short (24 hours for the first alert) and the obligation covers all in-scope products already on the market, not only those placed on the market after that date (Article 69, paragraph 3). This article sets out who is covered, what must be notified, within which deadlines and what minimal process an SME needs. The scope of the CRA itself (covered products, design requirements, full timeline) is covered in our CRA guide for SMEs.
Who is covered, and from when
The obligation falls on manufacturers of "products with digital elements" placed on the Union market: connected hardware, but also commercial software, including that of a SaaS vendor where the product falls within the regulation's scope. Being an SME changes neither the principle nor the deadlines. According to the Commission's page on the reporting obligations, Article 14 applies from 11 September 2026, while the essential cybersecurity requirements and CE marking wait until 11 December 2027.
The obligation holds whatever the product class, and independently of the conformity assessment regime that will apply to it in 2027. A manufacturer that will be able to self-assess and one that will have to go through a notified body notify under the same conditions and the same deadlines. Product classes and notified bodies are covered in the CRA guide for SMEs.
What must be notified
Two categories of events trigger the obligation. First, any actively exploited vulnerability contained in the product: it is not the discovery of a flaw that triggers the notification, but the knowledge that it is being exploited. Second, any severe incident having an impact on the security of the product; Article 14, paragraph 5, covers in particular incidents that affect, or are capable of affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive data or functions, and those that lead to the introduction or execution of malicious code.
These notifications add to, without replacing, the existing regimes: a single attack can fall under Article 14 of the CRA on the product side, NIS2 on the entity side and Article 33 of the GDPR on the personal-data side, each with its own deadlines and recipients.
The three deadlines
Article 14 organises the notification in three stages. An early warning within 24 hours of becoming aware, with reduced content (the suspected or observed exploitation, the Member States concerned where applicable). A notification within 72 hours, with the general information available on the product, the nature of the exploitation or incident and the corrective or mitigating measures taken or available. A final report, no later than 14 days after a corrective measure is available for an exploited vulnerability, and no later than one month after the notification for a severe incident.
Notifications go through the single reporting platform (SRP) set up by ENISA under Article 16, operational for 11 September 2026. A single submission transmits the notification simultaneously to ENISA and to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment; for France, that role falls to CERT-FR at ANSSI.
The obligation does not stop at the authority: paragraph 8 of Article 14 requires informing the impacted users, and where appropriate all users, of the vulnerability or incident and of the corrective or mitigating measures they can apply.
For questions of interpretation (who counts as a manufacturer, which products fall in scope, how the obligations fit together), the Commission maintains a technical FAQ on CRA implementation, updated in July 2026 from the recurring questions received since the regulation entered into force.
The minimal process to have in place
Meeting a 24-hour deadline is not improvised at the moment of the incident. Four elements form the base. A detection and qualification capability: knowing that a vulnerability is being exploited or that an incident affects the product requires reporting channels (monitoring, customer reports, coordinated vulnerability disclosure) and a written criterion for deciding whether the event falls within the Article 14 categories. A named decision chain: who qualifies, who approves, who files the notification, with a deputy for each role, since the deadline also runs over weekends. Prepared templates: the contents of the three stages are known in advance, and preparing them outside a crisis reduces the work under pressure to filling in the blanks. Finally, an account and verified access on the ENISA platform before the deadline, not on the day of the first incident.
Attaching the obligation to existing incident response
These requirements match practices the generalist frameworks already describe. In NIST CSF 2.0, incident handling belongs to the RESPOND function: qualification and handling in RS.MA (incident management), communication to stakeholders and mandatory reporting in RS.CO. An SME that structures its incident response for NIS2 or for its customers covers most of the process; Article 14 adds precise deadlines, a channel (the ENISA platform) and notification contents to prepare. The corresponding scenario belongs in the risk register, with the regulatory obligation documented as a consequence.
The Komplyo assessment measures the maturity of the RESPOND function, and the generated roadmap ranks incident-management gaps by priority. The free diagnostic (23 questions, around 5 minutes) gives a first reading of that function.