Privacy, Cyber & Data Strategy Advisory | Connected Devices And Software: New EU Cyber Incident Reporting Rules Take Effect

Executive Summary

The EU Cyber Resilience Act’s (CRA) incident reporting rules now require manufacturers of connected devices and software to move quickly from detection to coordinated reporting. Our Privacy, Cyber & Data Strategy Team breaks down the reporting requirements, scope, and other obligations manufacturers, importers, and distributors now face.

• Manufacturers must report actively exploited vulnerabilities and severe cybersecurity incidents
• The reporting process has three stages: an early warning within 24 hours, a detailed notification within 72 hours, and a final report on a timeline that differs depending on the event
• The CRA introduces distinct triggers, channels, and timelines, so companies should review incident management frameworks now

Today, 11 September 2026, the incident reporting obligations under the EU Cyber Resilience Act (CRA) become applicable. While the CRA’s broader requirements will not become fully enforceable until 11 December 2027, manufacturers of connected devices and software within the scope of the CRA must, from today, comply with new obligations to report certain vulnerabilities and cybersecurity incidents affecting their products.

The application of these new incident reporting obligations marks an important milestone in the EU’s efforts to strengthen the cybersecurity of devices and software sold and used across the EU. At the same time, they add a further layer of complexity for companies that may already be subject to incident reporting requirements under other EU digital regulations.

What Is the CRA?

The CRA, adopted in October 2024, is an EU regulation that sets baseline cybersecurity requirements for connected devices and software ‘placed on’ the EU market. Its scope is determined not by sector, but by the nature of the devices and software and the cybersecurity risks they may present.

The CRA introduces essential cybersecurity requirements that apply throughout the life cycle of covered devices and software, from their design and development to their placement on the EU market and ongoing maintenance. These obligations cover topics such as vulnerability management, security updates, security support commitments, and the implementation of corrective measures if cybersecurity risks or vulnerabilities are identified.

Which Connected Devices and Software Does the CRA Cover?

The CRA applies to ‘products with digital elements’ (PDEs), which are hardware products or software intended to have data connections with devices or networks (or which would foreseeably be connected to devices or networks). Examples include:

• Internet of Things (IoT) devices, laptops, network printers, and tablets.
• Smartphone apps (for example, mobile banking applications), desktop applications packaged for local installation, and software drivers.

The regulation adopts a risk-based approach, imposing progressively stricter cybersecurity requirements depending on the level of risk a product may pose, including to users’ health, safety, and security. To this end, it distinguishes between ‘default PDEs’, ‘important PDEs’, and ‘critical PDEs’, with each category subject to a corresponding level of regulatory scrutiny and compliance obligations.

For example, consumer PDEs with security-related functionalities, such as smart door locks, security cameras, baby monitors, alarm systems, connected toys, and wearable health devices, are generally considered ‘important PDEs’ and are therefore subject to enhanced conformity assessment and cybersecurity requirements before being placed on the EU market.

By contrast, PDEs whose compromise could create a significant risk due to their ability to disrupt, control, or cause damage to systems or infrastructure are classified as ‘critical PDEs’. Examples include hardware devices with security boxes, smart meter gateways used in smart metering systems, and smartcards. These PDEs are subject to the most stringent cybersecurity requirements and conformity assessment procedures under the CRA before they can be placed on the EU market.

What Are the CRA’s Main Obligations?

The CRA contains a broad range of obligations beyond the reporting rules. For example, the CRA requires manufacturers of PDEs to:

• Conduct and regularly update cybersecurity risk assessments for their PDEs.
• Design, develop, and manufacture PDEs in compliance with the CRA’s essential cybersecurity requirements.
• Prepare and maintain technical documentation for the PDE.

We described these obligations further in our previous advisory, D-Day for the EU Cyber Resilience Act.

The Incident Management and Reporting Obligations That Enter into Force Today

Effective immediately, manufacturers of PDEs must comply with a range of requirements relating to the identification, management, and reporting of certain vulnerabilities and cybersecurity incidents. Failure to comply with these requirements may expose organisations to regulatory enforcement measures and significant administrative fines.

Which events trigger reporting obligations under the CRA?

Not every cybersecurity event triggers a reporting obligation under the CRA: only certain actively exploited vulnerabilities (AEVs) and severe incidents must be reported. In short:

• An AEV is a vulnerability that is actively being exploited by a malicious actor under real-world operating conditions. For instance, an AEV may arise when a malicious actor has exploited a weakness, susceptibility, or flaw in a PDE, such as a vulnerability affecting its identification or authentication functions, without the authorisation of the system owner.
• A severe incident, by contrast, is a cybersecurity incident that negatively affects, or is capable of negatively affecting, the ability of a PDE to protect its data or functions. For instance, a severe incident may arise when a malicious actor successfully injects malicious code into the channel the PDE manufacturer uses to distribute software updates or security patches to users.

In practice, determining whether a vulnerability or incident falls within one of these categories is not always straightforward. Manufacturers should therefore implement robust processes to detect, investigate, and monitor security-related events affecting their PDEs. In particular, manufacturers should assess them in light of regulatory guidance such as the European Commission’s July 2026 guidance on the application of the CRA.

What should be reported in the event of an AEV or severe incident?

Both AEVs and severe incidents are subject to a three-step reporting process under the CRA. While the overall structure is similar, the applicable deadlines and the information that must be included in each report differ. Manufacturers should therefore ensure that appropriate internal processes are in place to identify the relevant reporting track, gather the required information, and comply with the applicable deadlines.

All notifications must be submitted to both the relevant coordinating computer security incident response team (CSIRT) at the local level and the European Union Agency for Cybersecurity (ENISA) at the EU level through ENISA’s electronic reporting platform using the reporting endpoint designated by the relevant CSIRT.

The key reporting requirements are:

When do the CRA reporting deadlines begin to run?

The text of the CRA does not explicitly set out the circumstances in which a manufacturer is considered to have become aware of an AEV or a severe incident. However, according to regulatory guidance, a manufacturer will generally be considered aware of an AEV or severe incident once it has completed an initial assessment and has a reasonable degree of certainty that a vulnerability affecting the PDE is being actively exploited or that a severe incident has occurred and affects the security of the PDE.

This approach recognises that manufacturers may need some time to investigate suspicious activity and verify the relevant facts before the CRA reporting deadlines begin to run. At the same time, manufacturers are expected to carry out initial assessments without undue delay and determine as quickly as possible whether a reportable AEV or severe incident has occurred.

Which authorities must AEVs and severe incidents be reported to?

If the manufacturer is established in an EU Member State, notifications must be submitted to both ENISA and the CSIRT designated in that EU Member State. If the manufacturer is established in more than one EU Member State, the competent CSIRT will generally be that of the EU Member State where the manufacturer primarily takes decisions on the cybersecurity of PDEs. If this cannot be determined, the competent CSIRT will be that of the EU Member State where the manufacturer employs the largest number of employees within the EU.

If the manufacturer is not established in the EU, notifications must be submitted to the CSIRT of the EU Member State where either:

• The manufacturer’s authorised representative is established.
• The manufacturer’s PDE importer is established.
• The manufacturer’s PDE distributor is established.
• Failing the above, the largest number of users of the PDE are located.

In all cases, notifications must also be submitted to ENISA through its designated reporting platform.

What about PDE users?

Once a manufacturer becomes aware of an AEV or severe incident, it must also inform affected users of the PDE and, where appropriate, all users of the PDE. It may be appropriate to notify all users of the PDE if, for example, the AEV has been addressed or mitigated and disclosure to a broader audience would enable users to verify that corrective measures have been implemented.

The notification to users must explain the AEV or severe incident, the risks it creates, and any steps users can take to protect themselves, including available security updates or other corrective measures. The information must be provided in a format that can be easily processed, shared, and distributed. If the manufacturer does not notify users, the relevant CSIRT may do so directly when necessary.

What’s Next?

The CRA’s reporting requirements require PDE manufacturers to implement robust processes for identifying, assessing, investigating, mitigating, and reporting vulnerabilities and cybersecurity incidents affecting their PDEs. Manufacturers subject to the CRA should therefore review their existing incident management and reporting frameworks to ensure they adequately address the CRA’s specific requirements and reporting timelines.

This review is particularly important for organisations that have already implemented processes to comply with incident reporting obligations under other EU digital regulations, such as the GDPR, NIS2, DORA, the AI Act, or sector-specific cybersecurity frameworks. While there are similarities between these regimes, the CRA introduces its own reporting triggers, deadlines, reporting channels, and substantive requirements, which may require existing processes to be adapted or supplemented.

If you have any questions about the CRA’s vulnerability and incident reporting requirements, the scope of the regulation, or any of the other obligations it imposes on manufacturers, importers, or distributors of PDEs, please do not hesitate to contact our Privacy, Cyber & Data Strategy Team.

Ransomware Fusion Center

Stay ahead of evolving ransomware threats with Alston & Bird's Ransomware Fusion Center. Our Privacy, Cyber & Data Strategy Team offers comprehensive resources and expert guidance to help your organization prepare for and respond to ransomware incidents. Visit Alston & Bird's Ransomware Fusion Center to learn more and access our tools.