Europe’s Cyber Reporting Clock Now Starts at Discovery

Europe’s Cyber Resilience Act has begun to operate before its full product-security regime applies. From 11 September, manufacturers must report actively exploited vulnerabilities and severe incidents affecting products with digital elements. The wider set of obligations arrives in December 2027, but the reporting clock is already running.

The sequence is demanding. A manufacturer must submit an early warning within 24 hours of becoming aware of the issue and a fuller notification within 72 hours. For an actively exploited vulnerability, a final report follows 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 of the 72-hour submission.

Notifications go through a Single Reporting Platform operated by ENISA. The manufacturer reports once to the designated computer-security incident response team in the member state of its main establishment. Unless a narrow cybersecurity exception applies, the receiving CSIRT makes the information available to ENISA and shares it with other national CSIRTs where the product has been sold.

A legal deadline enters the engineering workflow

Cybersecurity teams already triage vulnerabilities and incidents. The new duty adds a regulated classification problem to that work. Engineers must determine what happened; the organization must also decide whether the facts meet the Act’s thresholds and when it became “aware” for the purpose of the clock.

Those decisions cannot wait for a perfectly complete investigation. The 24-hour warning exists because useful coordination often has to begin while facts are still developing. Yet reporting too broadly can move sensitive technical information across multiple authorities before a mitigation is ready. The Act therefore creates a discipline of staged knowledge: disclose what is known, update it as the investigation matures and protect the details whose circulation could worsen the threat.

That discipline requires more than a compliance mailbox. Product telemetry, customer reports, security researchers, managed-service partners and component suppliers can all provide the first credible signal. If those routes do not reach a common decision process, the legal deadline may start in one part of the organization while another part remains unaware.

One portal still connects many institutions

The Single Reporting Platform reduces duplication for manufacturers, but it does not centralize the whole response. National CSIRTs remain the receiving authorities. ENISA operates the platform and supports coordination. Other CSIRTs may need the information because the product is available across borders. Market-surveillance and crisis-management bodies can become relevant as the case develops.

The value of “report once” will therefore depend on routing quality. The platform must identify the correct receiving authority, preserve confidentiality, manage updates and disseminate information quickly enough to support defense without creating a new source of exposure. ENISA has published registration guidance, notification workflows, a list of designated coordinators and a live status page. Those are operational components of the law, not administrative extras.

There is also a deliberate exception. A receiving CSIRT may delay wider dissemination in particularly exceptional circumstances on justified cybersecurity grounds. That safeguard recognizes that rapid sharing can sometimes increase risk. Its credibility will depend on disciplined use: too little restraint may expose exploitable detail; too much will fragment the common operating picture the platform was built to create.

Reporting is not remediation

The first months will generate visible measures of compliance: how many reports arrive, whether deadlines are met and whether the platform remains available. Those figures will not by themselves show whether products become safer.

The more useful evidence will connect notification to action. How quickly did the manufacturer contain the incident, issue a patch or workaround, notify customers and correct weaknesses in its development process? Did CSIRTs combine reports from multiple products into an early view of a shared dependency? Did component suppliers receive enough information to protect downstream users without waiting for public disclosure?

Manufacturers should test those questions now. A tabletop exercise should start with an ambiguous technical report, not a fully labeled “CRA incident”. The exercise should trace who confirms active exploitation, who has authority to notify, how customers are protected, what information can be shared, and how a final report is assembled without distracting the team from remediation.

Europe has created a common reporting door. The security gain will come from the decisions made before and after anyone opens it.