Topic · Cyber Resilience Act
What does Cyber Resilience Act reporting require?
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of in-scope products. Both routes have an early warning within 24 hours and a notification within 72 hours of awareness. Their final reports run from different events: remedy availability for a vulnerability, and the incident notification for a severe incident.
01 · Reporting triggers
A severity score does not establish active exploitation.
Actively exploited vulnerability
Article 3(42) requires reliable evidence of malicious exploitation in a system without the owner's permission. A high scanner score or a good-faith proof of concept can warrant urgent investigation without, by itself, establishing that trigger.
Severe incident affecting product security
Article 14(5) covers incidents that affect or can affect protection of sensitive or important data or functions, or that introduce or can introduce malicious code into the product or users' systems. A compromised update channel is one relevant scenario.
Record the facts supporting the applicable trigger and when the manufacturer became aware. A case may involve both routes. Missing facts should be identified in the reporting process; completing a root-cause investigation is not the event that starts the awareness clock.
02 · Event model
24 and 72 hours both count from awareness.
Vulnerability route
A · Awareness of active exploitation Record time and supporting evidence.
- A + 24 hours at latest: early warning, without undue delay.
- A + 72 hours at latest: vulnerability notification, without undue delay, unless the relevant information was already supplied.
R · Corrective or mitigating measure becomes available A separate event. Do not substitute the merge time or assume R happens at A + 72 hours.
R + 14 days at latest → final report Unless the relevant information has already been provided.
Severe-incident route
A · Awareness of the severe incident Record time and supporting evidence.
- A + 24 hours at latest: early warning, without undue delay.
- A + 72 hours at latest: incident notification, without undue delay, unless the relevant information was already supplied.
N · Incident notification submitted Retain the actual submission time and reference.
N + one month at latest → final report Unless the relevant information has already been provided.
These are reporting deadlines, not a single “patch within 72 hours” rule. The receiving CSIRT can also request an intermediate status report. Article 14(8) requires informing impacted users, and where appropriate all users, after becoming aware, including necessary measures they can take. Retain that communication and its supporting evidence alongside the regulatory submission.
Submit through ENISA's Single Reporting Platform, using the appropriate CSIRT endpoint. The platform routes the notification to the coordinating CSIRT and ENISA under the Act's information-sharing rules. Exceptional withholding or delayed dissemination is governed separately; it is not a general extension of the manufacturer's reporting deadline.
03 · Responsible role
Check the duty holder and product scope.
Article 14 manufacturer reporting has applied since 11 September 2026, including for products already made available before the main requirements begin. Establish scope and your role before treating a supplier, contributor or service as the manufacturer.
Open-source software stewards have a separate Article 24(3) duty from 11 December 2027. It concerns exploited vulnerabilities to the extent they are involved in development, and severe incidents affecting the systems they provide for that development. This does not place every open-source contributor on the manufacturer reporting timetable.
04 · Evidence preparation
Prepare a record the reporting owner can use.
The following is an illustrative preparation record for a connected updater. It is not an ENISA form or an observed customer incident. Its purpose is to keep the legal clocks separate from engineering progress.
| Record | Example entry | Evidence or next action |
|---|---|---|
| Awareness | 2 October, 09:00 UTC: product-security owner receives reliable evidence of unauthorised exploitation. | Preserve the original report and the awareness rationale. Early-warning deadline: 3 October, 09:00; notification deadline: 5 October, 09:00. Act without undue delay. |
| Product and exposure | Updater 3.2 confirmed affected; 3.1 remains under investigation. | Record the affected conditions, impact and territory information known at submission. Do not label the untested version unaffected. |
| Requirement and corrective Change | The updater must reject an unsigned package. A patch is proposed. | Link the requirement, vulnerability, source revision and reproducer. A patch or passing test is not yet evidence of remedy availability. |
| Verification and remedy | 6 October, 12:00 UTC: tested update made available for 3.2; distribution evidence retained. | Record actual results and limitations. If this is the first available corrective or mitigating measure, the vulnerability final report is due no later than 20 October, 12:00. An earlier available mitigation would set an earlier anchor. |
| Submission and open work | Named reporting owner, SRP receipt, open 3.1 investigation and unknown user deployment status. | Keep submission, verified fix, available update and confirmed deployment as separate states. |
For the incident route, record when the incident notification was actually submitted to determine the one-month final-report deadline. Also prepare impact and severity, likely cause or threat, applied and ongoing mitigations, and unresolved facts. The reporting owner decides what must be submitted and handles any additional reporting regimes.
Proof today: requirements, hazards, implementation links, Changes and verification records can supply engineering inputs to this preparation. Development direction: automated supported-release tracking, operational incident ingestion and regulatory report preparation. Proof does not currently determine reportability or submit CRA reports. Bring one security Change and the evidence your reporting owner needs to scope a bounded walkthrough.
Sources and scope
Reviewed 2 October 2026. The responsible manufacturer or steward owns the filing and applicability decisions; this page explains the engineering preparation.
- Regulation (EU) 2024/2847: Articles 3(42), 14, 16, 24(3), 69 and 71.
- Commission reporting guidance, updated 11 September 2026; ENISA platform instructions. These support implementation; the regulation is the binding source.
- Delegated Regulation (EU) 2026/881: conditions for cybersecurity-related delay of notification dissemination.