Cyber Resilience Act: Reporting Since September 11, 2026

Article 14 of the Cyber Resilience Act has applied since September 11, 2026. Manufacturers of covered products with digital elements must 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 14-day period therefore does not automatically run from the first signal; a single internal deadline that ignores the reporting condition could be wrong for one of the two paths. The coordinating CSIRT may also request an intermediate report. The 24- and 72-hour periods are maximum limits. Article 14 also requires these reports without undue delay. An early warning that is ready should therefore not be withheld simply because an internal calendar still shows time remaining.

As an operating recommendation, teams can separate unresolved technical questions from available information and attach subsequent findings to the existing case. That recommendation follows from staged reporting; it is not an additional prescribed report format. 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.

The responsible authority also follows statutory allocation rules. For a manufacturer with its main establishment in the EU, Article 14(7) directs reporting to the coordinating CSIRT of that member state; the relevant location is where decisions about product cybersecurity are predominantly made. The provision contains further criteria for other establishment arrangements. The applicable allocation should be clarified in advance, without assuming that the location of a single server determines the reporting authority.

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

According to the Commission, ENISA's Single Reporting Platform has been operational since 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 also change after 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.

Platform access is personal: ENISA describes EU Login with multifactor authentication and primary or additional authorized representatives of the manufacturer. A saved draft is not visible to other representatives.

This creates a practical task when another representative takes over. A handoff cannot assume that the replacement representative can open the same private draft. Required case information and responsibilities need to be available through a designated internal handoff process. Internal preparation of product-version information or case details can be automated; actual submission takes place through the platform interface. Platform timers and reminders do not remove the manufacturer's responsibility for statutory deadlines.

For a platform outage, ENISA calls for submission through the SRP once it becomes available again. Where urgent communication is needed, the responsible CSIRT should be contacted directly. That contact does not replace the later SRP submission. Operational preparation should therefore also establish how to record a failed submission attempt and follow up on the outstanding report. This is a derived operating recommendation, not an additional statutory exemption from reporting.

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 arrangements for substitute staff, 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. It can also establish whether an older build can be traced under time pressure to the product version customers actually received.

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