- Petra Jirošová
- 13 min read
The Cyber Resilience Act (CRA) requires manufacturers to report actively exploited vulnerabilities and severe security incidents in products with digital elements. This reporting obligation takes effect on September 11th 2026, considerably earlier than most other CRA requirements. Who does it apply to, what exactly must be reported, and within what deadlines?
Reporting vulnerabilities and incidents under the CRA
The CRA affects a wide range of companies: from manufacturers of smart appliances to importers of low-cost electronics and to software firms. In previous articles we explained who the CRA applies to and what is a product with digital elements. Now we turn to one of the obligations that takes effect earlier than most others – reporting vulnerabilities and incidents.
Much like the czech Cybersecurity Act, the CRA requires certain matters to be reported to the competent authorities. These are primarily actively exploited vulnerabilities and severe security incidents.
The obligation to report actively exploited vulnerabilities and severe incidents applies from September 11th 2026. The remaining obligations set out in the CRA, such as the product security requirements and conformity assessment, will apply from December 2027.
When a vulnerability must be reported
Not every vulnerability has to be reported under the CRA. What matters is whether it meets the conditions for notification. The obligation arises the moment a manufacturer, or an entity in the position of a manufacturer, becomes aware that a vulnerability in its product with digital elements is being actively exploited and that there is reliable evidence of this. In practice, this means that:
- there is evidence of actual exploitation of the vulnerability,
- the vulnerability is being exploited in a real-world environment, not merely in testing,
- it is not just a theoretical or potential threat.
When an incident must be reported
Alongside vulnerabilities, the CRA also addresses severe security incidents. Whereas a vulnerability is a weakness in the product, an incident means there has already been a real impact on the availability, confidentiality, integrity or authenticity of the data or functions of a product with digital elements.
Typical examples include system compromise or a data breach, an outage affecting the product or its key functions, or ransomware spreading through vulnerabilities in the product. Not every incident is automatically subject to the reporting obligation, however. Under the CRA, a severity threshold applies. An incident is severe if it:
- negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions,
- has led or is capable of leading to the introduction or execution of malicious code in the product with digital elements or in the network and information systems of a user of that product.
How can you assess severity on a preliminary basis? These basic questions can help:
- Product security in general: Does the incident affect the security of the product as such?
- Availability: Is the product or any of its functions unavailable or degraded?
- Integrity: Has data or functionality been altered without authorisation, or could it be?
- Confidentiality: Has sensitive data fallen into the hands of someone who should not have access to it?
- Authenticity: Can you trust that the system or communication is what it claims to be?
- Compromise: Could an attacker have gained control over the product or system?
- Malicious code: Was malicious code executed, or could it have been executed, in the product or in the user's system?
Reporting deadlines: 24 hours, 72 hours and the final report
From September 11th 2026, reporting takes place via the Single Reporting Platform (SRP) operated by ENISA. Reports are submitted through this platform, and ENISA handles onward distribution to the relevant authorities. Before logging in for the first time, set up an EU Login, which is used to access the platform.
For both vulnerabilities and security incidents, reporting proceeds in several steps. The first deadline is very short – an early warning must be submitted within 24 hours.
Phase | Deadline | Vulnerability | Incident |
|---|---|---|---|
Early warning | Within 24 hours | • Confirmation that an actively exploited vulnerability exists. • Member States where the product is available. | • Confirmation that an incident has occurred. • Whether unlawful or malicious conduct is suspected. • Member States where the product is available. |
Notification | Within 72 hours | • The technical nature of the vulnerability and the nature of the exploitation. • Corrective or mitigating measures taken or available. • Measures that users can take. • An assessment of the sensitivity of the information reported. | • The technical nature of the incident and its initial assessment. • Corrective or mitigating measures taken or available. • Measures that users can take. • An assessment of the sensitivity of the information reported. |
Final report | Depending on the type of event | Within 14 days of a corrective or mitigating measure being issued • A description of the vulnerability, including its severity and impact. • Information about the malicious actor (where known). • Details of the security updates or corrective measures. | Within 1 month of the notification submitted within 72 hours • A detailed description of the incident, including its severity and impact. • The type of threat or root cause of the incident. • Ongoing mitigating measures. |
Informing users: the obligation does not end with the regulator
Reporting to the regulator is not the only communication obligation. The CRA also requires manufacturers to inform affected users of the product without undue delay. Where affected users cannot be reliably identified, it may be necessary to inform all users. Users should be told:
- which vulnerability or incident affects them,
- what corrective measures the manufacturer has taken or is preparing,
- what they can do themselves to limit the impact.
What to have ready before your first report
The biggest problem with a first report may not be technical but procedural. Companies should be clear in advance above all about who decides that an event meets the conditions for reporting, who actually submits the report, who approves communication to users, and where information about the event will be stored as it comes in, so that the team does not have to track it down after the fact.
The minimum worth having ready:
Access to the single reporting platform – sort out registration in advance and test your access. When the 24-hour clock is running, you do not want to be dealing with logins or permissions.
An internal reporting procedure – determine who assesses the incident or vulnerability, who decides whether the conditions for reporting are met, and who actually submits the report.
An escalation and communication procedure – determine who approves communication to users and who then carries it out.
