Cyber Resilience Act: 24-Hour Reporting Starts in September 2026

Article 14 of the Cyber Resilience Act applies on September 11, 2026. Manufacturers of covered products with digital elements must then report actively exploited vulnerabilities and severe incidents affecting the security of the product in stages. The early warning is due without undue delay and no later than 24 hours after awareness; the more detailed notification is due no later than 72 hours after awareness. The root-cause analysis and remediation do not have to be complete for the first message.

For an actively exploited vulnerability, the CRA requires reliable evidence that a malicious actor exploited it without the system owner's permission. A general report about a third-party component does not establish that the reporting condition exists in the manufacturer's product. According to the Commission's non-binding guidance, the assessment should include whether the vulnerable code is reachable in the released product and whether exploitation occurred there. The second reporting path covers a severe incident affecting product security. Article 14 refers to an actual or potential compromise of the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. Introduction or execution of malicious code in the product or a user's system can also qualify. For this incident type, malicious origin does not have to be conclusively established at the outset.

A CVE entry, supplier notice, or unusual log signal therefore does not automatically start the clock in every case. It still requires prompt assessment. The Commission guidance treats awareness as the point at which that initial assessment reaches a reasonable degree of certainty that the statutory condition is met. The guidance is not binding, but it reflects the Commission's current interpretation. A later internal approval milestone does not move an awareness point established on that basis.

Deadlines and Report Stages

The early warning contains only the limited information required at that time. Within 72 hours, the manufacturer adds general information, an initial assessment, and corrective or mitigating measures already taken. An actively exploited vulnerability requires a final report no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final deadline is one month after the 72-hour notification. The coordinating CSIRT may also request an intermediate report.

Because the evidence changes during an investigation, a chronological case record can retain when the signal was received, the evidence reviewed, the assumed awareness time, affected product releases, and later corrections. Hypotheses remain labeled as such. The CRA does not prescribe this exact record format; it is an operational compliance recommendation.

Product Releases and Technical Evidence

The CRA entered into force on December 10, 2024, but its duties begin at different times. Article 14 applies in September 2026; most requirements for development, product documentation, and conformity follow in December 2027. The Commission's non-binding guidance says the reporting duty also reaches products placed on the market before the general application date and may continue beyond the support period. That interpretation does not make every other CRA obligation retroactive. For a new reporting case, however, the manufacturer still needs to determine which released version contains which component. A version-specific software bill of materials can shorten that search, but it does not prove code reachability or active exploitation. VEX can record a technical status such as affected, not affected, under investigation, or fixed. It does not make the regulatory decision for the manufacturer.

Single Reporting Platform

ENISA's Single Reporting Platform is scheduled to be operational on September 11, 2026. According to its FAQ updated August 3, access uses EU Login and an API for automated submissions is not planned at this stage. An EU Login account may be prepared in advance. ENISA recommends initiating platform registration and validation only when a concrete reporting need arises, so the responsible CSIRTs are not burdened unnecessarily. Operating instructions may still change before launch, making a link to current platform documentation more durable than fixed screenshots in a runbook. The platform also does not replace technical response or any other reporting route that may apply to the organization and incident.

After becoming aware, the manufacturer must inform affected users and, where appropriate, all users about the vulnerability or incident and, where necessary, available measures. Unlike the 24- and 72-hour reports, Article 14(8) does not use a specific without-delay deadline. The Commission guidance describes timely, risk-based, and proportionate communication. The audience and level of detail therefore depend on the case.

A dry run can test whether coverage, product archives, the initial technical assessment, and platform access work together. It does not present an invented incident as fact; it tests the organization's handoffs and decisions. One practical question is enough to expose weak preparation: can an older build be traced to the product version that customers actually received while the reporting clock is running?

Note: This assessment is not a substitute for a review of the specific case.