Ready, respond, report: the Cyber Resilience Act’s reporting regime is here

The reporting obligations included in Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (the Cyber Resilience Act or CRA), enter into application on 11 September 2026 with the broader CRA framework entering into application on 11 December 2027.

The CRA is an EU regulation that establishes mandatory cybersecurity requirements for certain products with digital elements placed on the EU market. These reporting obligations apply to certain vulnerabilities and incidents affecting product security.

CRA reporting regime applies from Friday, 11 September

As of 11 September 2026, the CRA’s vulnerability and incident reporting regime applies to manufacturers of relevant products with digital elements placed on the EU market, including relevant products that were already placed on the EU market before that date.

For many businesses, that means 11 September is an operational deadline rather than a distant compliance milestone.

Which events must be reported?

Manufacturers must report two categories of security event: actively exploited vulnerabilities contained in their products with digital elements, and severe incidents impacting the cybersecurity of those products. The concept of an actively exploited vulnerability is narrower than a generic software flaw because the CRA distinguishes between a vulnerability, an exploitable vulnerability and an actively exploited vulnerability supported by reliable evidence of exploitation without the system owner’s permission. By contrast, a zero-day vulnerability with no evidence of prior malicious exploitation does not trigger mandatory notification on that basis alone.

The reporting obligation also extends to severe incidents affecting product security. An incident is treated as severe where it negatively affects or is capable of negatively affecting the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code in the product or in the user’s network and information systems (e.g. an attacker compromising the manufacturer’s release channel for security updates).

When does the reporting clock start?

An important practical question is when a manufacturer became “aware” of a reportable event. The Commission’s guidance indicates that awareness arises once the manufacturer has reached a reasonable degree of certainty, following an initial assessment, if necessary, that an actively exploited vulnerability or severe incident has occurred. This assessment period is permitted, but must be carried out as soon as possible.

In practice, awareness may be triggered by customer or partner reports, threat intelligence about exploitation, notifications from government cybersecurity agencies, internal monitoring and telemetry, or other reliable evidence that exploitation or a severe incident has occurred. Businesses should ensure that incoming security signals are routed quickly to the teams responsible for triage and escalation.

What must be filed and when?

If an event qualifies as a reportable security event, the manufacturer must notify the designated coordinating CSIRT and ENISA through the Single Reporting Platform. The first step is an early warning, which must be submitted within 24 hours after the manufacturer becomes aware of the event. At a minimum, that early warning must identify the EU member states where the manufacturer is aware that the product has been made available. For severe incidents, it must indicate whether the incident is suspected of being caused by unlawful or malicious acts.

The second step is the event notification, which must be filed within 72 hours after awareness. That notification must provide general information about the product, an initial assessment of the event, any corrective or mitigating measures already taken, any steps users can take, and the manufacturer’s view of the sensitivity of the reported information.

The final reporting step depends on the type of event. For an actively exploited vulnerability, the manufacturer must submit a final report no later than 14 days after a corrective or mitigating measure has been made available. For a severe incident affecting product security, the final report is due within one month after the event notification. In both cases, the final report goes well beyond a placeholder notice and must include substantive information about the vulnerability or incident, its severity and impact, and the mitigating or corrective action taken.

User communication will also matter

The CRA reporting regime is not only about reporting to regulators. Once a manufacturer becomes aware of a reportable security event, it must also inform affected users or all users about the event and, where necessary, the mitigating and corrective measures to be deployed. Depending on the nature of the product and the risk, this reporting may require tailored communications to particular customers rather than a generic public statement.

The reporting infrastructure remains a practical focus

There is an added complication for businesses. The Single Reporting Platform is not yet accessible. ENISA expected that the platform would be operational by 11 September 2026 and has published supporting materials on registration, reporting flows and expected data fields.  Manufacturers will need an authorised individual acting as an Assigned Representative, using an EU Login account, and the relevant CSIRT-C will validate that representative’s ability to report on the manufacturer’s behalf.

What should businesses do now?

The immediate priority is governance. Manufacturers should define clear ownership and escalation procedures for vulnerability and incident assessments, so that the business can quickly determine whether a reportable security event has occurred and when the awareness clock has started. They should also prepare the information needed for the 24 hour, 72 hour and final notifications, including the product, EU member state availability and mitigation details that ENISA expects to collect through the platform.

Businesses should also identify the appropriate coordinating CSIRT, nominate an Assigned Representative, and put in place a process for notifying affected users and communicating mitigation steps. More broadly, manufacturers should map their product portfolio and confirm which products with digital elements fall within this scope since reporting obligations will apply from September 2026 (even though the rest of the CRA regime largely follows later).

For manufacturers of in-scope products, 11 September 2026 is best understood as the date when CRA incident response ceases to be purely internal and becomes a regulatory reporting function. Organisations that wait for the platform to go live before assigning responsibilities, testing escalation routes and preparing user communications risk losing valuable time once the first reportable event arises.