Since 11 September 2026, the obligation laid down in Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act, has been in force. The ENISA Single Reporting Platform (SRP) is now the only legally recognised channel for notifying an actively exploited vulnerability or a serious incident affecting your products. Teams that have not yet tested the portal reach this deadline at an operational disadvantage: the first alert can come at any time.
The SRP: a single, non-substitutable channel
Article 14 of the CRA is precise on this point: notification takes place exclusively through the ENISA SRP platform. Neither an email to France's national cybersecurity agency (ANSSI), nor a report through a national portal, nor a declaration to a third-party body counts within the meaning of the regulation. The platform automatically relays your notification to the competent national CSIRT. For manufacturers established or active in France, this CSIRT is the CERT-FR of ANSSI.
This single centralised channel is a change of habit for teams familiar with NIS2 processes, which go through national authorities. Under the CRA, the flow runs from ENISA to the CERT-FR, not the reverse. A notification submitted through any other channel is not counted as compliant.
Three deadlines, depending on the nature of the event
Article 14 distinguishes two categories of events to be notified. The first is the actively exploited vulnerability: a flaw for which there is evidence of exploitation in real conditions, not merely proof-of-concept code or theoretical analysis. The second is the serious incident: a security breach of the product that causes significant disruption or unauthorised access to data.
For each, the sequence is identical in structure, but the deadlines for the final report differ. For an actively exploited vulnerability: early warning within 24 hours of discovery, full notification within 72 hours, and a final report no later than 14 days after a fix or mitigation measure becomes available. For a serious incident, the early warning and full notification deadlines remain 24 and 72 hours, but the final report may be submitted within one month.
In its impact assessment of October 2022, the European Commission estimated that the CRA would cover more than 160,000 manufacturers worldwide. The great majority of them had never submitted a notification through the SRP before today.
What "actively exploited" means in practice
The notification obligation begins as soon as the manufacturer "becomes aware" of the active exploitation. This wording matters: it does not assume that the exploitation is publicly documented, nor that your product has been confirmed as affected in a specific incident. A report from a researcher, a notice from a customer, an observation in your telemetry logs, or an entry in the CISA KEV (Known Exploited Vulnerabilities) catalogue are all possible starting points.
The CISA KEV list is a strong signal, but it does not automatically trigger the obligation. It is your own awareness that your specific product is affected that starts the 24-hour clock. A manufacturer that sees a CVE affecting a library it integrates, and verifies that the CVE is actively exploited in the wild, is in a notification situation.
A concrete example: the IoT manufacturer facing its first deadline
A manufacturer of industrial network gateways receives a report from a researcher at 9:00 a.m. this morning: a vulnerability in the authentication component of its firmware version 4.2 is being exploited in industrial networks in Northern Europe. It has until 12 September at 9:00 a.m. to submit an early warning on the SRP. The early warning does not require a full analysis: it must state the product concerned, the approximate nature of the vulnerability and the populations potentially affected.
If the manufacturer does not have an active SRP account at 9:00 a.m., creating the account, getting to grips with the interface and drafting the alert must all be completed in under 24 hours. Teams that tested the portal during the preparatory period have a structural one-hour head start. The others start now.
What your team must check today
Four operational elements must be verifiable without delay. The first is access: one or more team members have an active SRP account, tested, with the rights needed to submit a notification. The second is process: who decides to notify, on what basis, and under whose authority within the organisation. The third is an early warning template with the fields required by the SRP. The fourth is the internal definition of what constitutes an "actively exploited vulnerability" for your product lines.
The coordinated vulnerability disclosure (CVD) policy, whose formalisation was the priority in the days before this deadline, is the natural supporting document for this process. Teams that have not yet formalised it will find the structural elements in the article on the CVD policy that software publishers have not yet formalised.
The real difficulty: deciding with partial information
The 24-hour early warning is designed to work with incomplete information. The regulation does not require a root cause analysis or an operational fix within that deadline: it requires an initial declaration that allows ENISA and the CERT-FR to contextualise the threat. The full 72-hour notification allows impact details to be added. The 14-day final report documents the measures taken.
The real difficulty is organisational: deciding to notify, under pressure and with incomplete information, within 24 hours, is an exercise that cannot be improvised on the day of an incident. Manufacturers that simulated this process, even on paper, arrived at 11 September with measurable preparation.
Article 14 of the CRA has been in force since this morning. The SRP is open. The next 24-hour clock will start at the next discovery of active exploitation, whether or not your organisation is ready.