Reporting to ENISA and CSIRTs
This obligation arrived first, on 11 September 2026, and its breach is the most visible: the deadlines are short, public and verifiable.
The two triggers
| Trigger | Definition |
|---|---|
| Actively exploited vulnerability contained in the product | A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner |
| Severe incident having an impact on the security of the product | An incident that negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of data or functions |
What “actively exploited” means
- The existence of a public proof-of-concept exploit does not, on its own, establish active exploitation.
- Conversely, exploitation observed at a single customer is enough.
- A high severity score is not a criterion: a critical vulnerability never exploited does not trigger the obligation; a medium-severity vulnerability being exploited does.
The delicate point is reliable evidence: consistent indicators of compromise, logs, forensic analysis, a credible report from a customer or a CERT. The decision must be documented, including when it concludes there is no active exploitation.
The channel
Reports go through the single reporting platform (SRP) established and operated by ENISA. They are routed to the CSIRT designated as coordinator of the Member State concerned and to ENISA.
The manufacturer must therefore, in advance: register on the platform, hold live named accounts for on-call staff, and have tested submission.
The three stages — actively exploited vulnerability
| Deadline | Deliverable | Content |
|---|---|---|
| ≤ 24 hours of becoming aware | Early warning | Indication of the Member States in which the product was made available; where applicable, suspected malicious character |
| ≤ 72 hours | Vulnerability notification | General information on the product, nature of the vulnerability, corrective or mitigating measures taken and those users can apply |
| ≤ 14 days after a corrective measure is available | Final report | Description of the vulnerability, severity and impact, information on the threat actor where available, details of the fix |
The three stages — severe incident
| Deadline | Deliverable | Content |
|---|---|---|
| ≤ 24 hours | Early warning | Indication of the suspected malicious character of the incident |
| ≤ 72 hours | Incident notification | Assessment of the incident, severity, impact, indicators of compromise where available |
| ≤ 1 month | Final report | Detailed description, severity and impact, type of threat or likely root cause, mitigation measures applied and ongoing |
Informing users
Independently of reporting to authorities, the manufacturer informs, without undue delay, the affected users — and, where applicable, all users — of the vulnerability or incident and of the corrective or mitigating measures they can apply.
That information does not wait for the final report. It is distinct from the publication of a security advisory under Annex I, Part II, point 4, which follows once the fix is available.
Voluntary reporting
The Regulation allows voluntary reporting of vulnerabilities, incidents, near misses or cyber threats, even outside any obligation. A voluntary report imposes no additional obligation on its author.
Practical consequence for your decision rule. Where there is serious doubt about the qualification, reporting is the default position: a voluntary report costs nothing in law; a missed report does not.
Confidentiality and delayed dissemination
Reported information is protected: authorities and ENISA handle it while preserving trade secrets and intellectual property rights, and use it only for the purposes provided for.
A coordinating CSIRT may also delay dissemination of a notification to other authorities, for a limited time and on justified cyber risk grounds — typically where dissemination would widen the risk before a fix is available.
The extended time scope
This is the most frequently missed point:
The Article 14 reporting obligations apply also to products placed on the market before 11 December 2027, by derogation from the general transitional regime.
Your legacy portfolio has therefore been in scope since 11 September 2026, even though it has neither a CRA CE marking nor technical documentation. That means knowing, for every product still deployed at customers: which versions are in circulation, which components they contain, and how to reach the users.
Do not confuse
The CRA / NIS 2 / GDPR comparison table is in Interplay with other legislation. A single event can trigger all three notifications, to three different recipients.
The operational run-through — cell, roles, templates, on-call, exercises — is in 24 h / 72 h / 14 d procedure; the legal decision to report is in Reporting duties.