Cyber Resilience Act Reporting Starts 11 September 2026: The 24h, 72h and Final-Report Clocks
Published August 2026 by Solarc Labs
11 September 2026 is a real operational deadline
The Cyber Resilience Act does not wait until its full 11 December 2027 application date for every obligation. Article 14 reporting obligations apply from 11 September 2026. The European Commission states that manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements from that date. That makes incident-readiness a current operating problem, not a 2027 policy project. Teams in scope need a way to capture when they became aware of a potentially reportable event, preserve enough evidence for triage and put the statutory clocks in front of the people who own the decision.
The first two clocks are 24 hours and 72 hours
For an actively exploited vulnerability or a severe security incident, the reporting process begins when the manufacturer becomes aware of the event. The Commission and ENISA describe an early warning due without undue delay and in any event within 24 hours, followed by the fuller vulnerability or incident notification within 72 hours. A readiness workflow therefore needs an immutable awareness timestamp and a visible clock. If the team cannot reconstruct when awareness occurred, it may be impossible to tell whether the 24-hour or 72-hour window is already running.
The final-report clock depends on what happened
The later deadline is not the same for both event types. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after the main notification. Those are workflow states, not reasons to auto-submit. The incident owner still needs to distinguish the event type, confirm scope and decide what information is appropriate for the regulatory report.
Prepare the evidence packet before the incident exists
A useful tabletop asks what the team would need at hour one: affected product and versions, deployment footprint, evidence of exploitation or impact, awareness source and timestamp, initial severity facts, containment or mitigation status, owners and the record of each decision. It should also identify who is authorised to use the CRA Single Reporting Platform and who provides legal or regulatory review when the facts are ambiguous. The goal is to reduce information-reconstruction time during a real event. It is not to turn a generic security alert into an automatic regulatory conclusion.
CRA Incident Desk is readiness tooling, not a reportability oracle
CRA Incident Desk is designed for bounded incident-readiness and tabletop work: awareness timestamps, evidence capture, preparation clocks and human handoff. It does not make the legal determination that an event is reportable, and this article is not legal advice. It also does not replace ENISA's Single Reporting Platform, a CSIRT, legal counsel or the manufacturer's own incident-response authority. Use the readiness guide to rehearse the states and evidence before 11 September, then validate the actual reporting process against the latest Commission and ENISA guidance for the organisation and product in scope.
Primary sources
Sources used for this article
Continue the job