Incident Reporting Under the EU Cyber Resilience Act

Background

The EU Cyber Resilience Act (the "CRA") imposes mandatory cybersecurity requirements on products with digital elements ("PDE") across their entire lifecycle. These cybersecurity standards are demonstrated through conformity assessments, technical documentation, and CE marking. 

The CRA complements the broader EU cybersecurity framework e.g. NIS2, EU GDPR and sector-specific rules. While NIS2 addresses the security of networks and information systems operated by service providers and is focused on specific verticals (e.g. cloud providers), the CRA is sector-agnostic and applies to networked products placed on the EU market.  As a result it has a much broader application, particularly as "products" include standalone software such as mobile apps, not just hardware products. 

A central pillar of the CRA is its mandatory incident reporting regime. Manufacturers of PDE must notify the authorities promptly when they become aware of actively exploited vulnerabilities or severe security incidents affecting their PDE. While most CRA obligations take effect on 11 December 2027, the incident reporting obligations under Article 14 apply from 11 September 2026.

Scope of CRA

The CRA applies to any hardware or software product with "digital elements" whose intended or reasonably foreseeable use includes a connection to a network or another device.  It encompasses not only the physical products themselves but also "remote data processing solutions" that support the product's functionality.  It also includes standalone software that is downloaded or installed by users, such as mobile apps.

For the incident reporting obligations under the CRA, the primary compliance responsibility rests with the manufacturer - the entity that develops or manufactures the PDE (or has it developed or manufactured on its behalf) and places it on the EU market under its name or trademark.
Although the wider obligations under the CRA only apply to PDE placed on the market, or substantially modified, after 11 December 2027, the incident reporting obligations apply to PDE that is already on the market on 11 September 2026.  

It's important to define and record the product perimeter for incident reporting, given that it applies to "remote data processing solutions" ("RDPS"), not just hardware and/or mobile apps that form the manufacturer's branded product. RDPS is essentially solutions that the PDE relies upon and without which it could not perform one or more of its functions.  However, only solutions that were designed and developed by the manufacturer, or under its responsibility, are caught. This therefore excludes generic, off-the-shelf third-party solutions (such as standard cloud services or SaaS platforms not specifically designed for the manufacturer) that are not tailor-made for the manufacturer.

For example, if an insurer provides a mobile app hosted on AWS to enable its customers in the EU to access their home insurance policies, change personal details and communicate with the insurer, an incident which affects the mobile app would need to be reported, but not an incident which affects AWS' infrastructure or any generic SaaS solutions which support the app e.g. for customer authentication.

Reporting Requirements

What Must Be Reported

Article 14 creates two distinct reporting duties. Manufacturers must report:

• Actively exploited vulnerabilities - a vulnerability in the product for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission.  Vulnerabilities that are patched prior to exploitation, or which are "exploited" for benign motives (e.g. pen testing, ethical hacking) would not be reportable;
• Severe incidents - an incident that 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 that has led (or is capable of leading) to the introduction or execution of malicious code. 

Who to Report to

All reports are submitted via ENISA's Single Reporting Platform (SRP) - a single-entry point that routes the notification simultaneously to ENISA and to the CSIRT designated as coordinator in the manufacturer's EU member state of main establishment. The receiving CSIRT then disseminates the notification to CSIRTs in member states where the product is available. ENISA has recently published the list of designated coordinators for all member states.

Timelines for Reporting

Each report follows a three-stage process, measured from the moment the manufacturer becomes aware of the reportable event:

Ongoing Obligations

The receiving CSIRT may request intermediate reports about the notified event at any time. Manufacturers must also inform affected users of the event, including, where appropriate, any risk mitigation and corrective measures users can deploy. If a manufacturer fails to inform users in a timely manner, the designated CSIRT may itself provide such information to users where it considers this proportionate and necessary.

Key Takeaways

• Incident reporting obligations under Article 14 apply from 11 September 2026 - well ahead of the broader CRA compliance date of 11 December 2027.
• The reporting obligation covers products already on the market, not just new launches.
• Map your current products and identify which products meet the CRA's definition of a PDE and if any RDPS are in scope.
• Determine your main establishment and designated CSIRT. There is a decision tree process in Article 14(7) for determining the manufacturer's main establishment in the EU, or if there is none, how to identify the CSIRT through other factors.
• Register for ENISA's Single Reporting Platform. Create EU Login accounts for a primary reporter and at least one backup representative.  As the reporter's connection to the manufacturer will need to be validated after setting up their account on the SRP, and as reporters don't need to be validated to file initial notifications, ENISA's preference is that the SRP account is activated only when a notification needs to be submitted, to avoid overloading the CSIRTS.
• Establish reporting protocols. With a 24-hour early warning deadline, there is no time to design a process during a live incident. Establish clear escalation protocols, designate key stakeholders, and prepare internal templates.
• Maintain incident logs that include information on when the manufacturer became aware of the reportable event.
• Don't wait to start preparations for the wider and more onerous CRA obligations that apply from 11 December 2027.  These include cybersecurity standards in design, development and production, conformity assessments, third party due diligence, production of technical documentation and information for users and vulnerability management protocols.