Mandatory vulnerability and incident reporting requirements under the Cyber Resilience Act (CRA) apply from 11 September 2026. Manufacturers placing products with digital elements on the EU market, ranging from smartphones to industrial IoT, must now comply with these obligations, including in respect of products already on the market.
The EU Cyber Resilience Act's vulnerability and incident reporting requirements are now live
Overview
Background: what is the CRA?
The reporting obligations arrive more than fifteen months ahead of the CRA's full application date of 11 December 2027. The CRA makes cybersecurity a condition of market access for products with digital elements ("PDEs") in the EU. It will require security-by-design and security-by-default, ongoing vulnerability management for at least five years (or the product's expected lifespan if shorter), and a cybersecurity risk assessment maintained throughout the support period. It also requires conformity assessment, CE marking, and the retention of technical documentation for at least ten years.
Is the product in scope?
The reporting obligations apply to all PDEs within the scope of the CRA. Four criteria determine whether a product is in scope:
-
Is it a PDE?
A PDE is any software or hardware product and its remote data processing solutions, including components placed on the market separately. Where a hardware product is designed to work with specific software from the same manufacturer (for example, a fitness wearable and its companion app), they together constitute the PDE even if the software is downloaded separately. Remote data processing also forms part of the PDE where the manufacturer is responsible for it and the product could not perform one of its functions without it, such as a cloud back-end that enables remote control of a smart home device. Conversely, software that is only accessed remotely through a browser, rather than supplied to the user for local execution, is not itself a PDE.
-
Is it being made available on the EU market in the course of a commercial activity?
This includes supply free of charge where the manufacturer monetises other services through the product or requires processing of personal data beyond what is needed for security or interoperability. Free and open-source software (as that term is defined in the CRA) that is not monetised falls outside the CRA. (Open-source software stewards will be subject to limited reporting obligations from 11 December 2027.)
-
Is its intended or reasonably foreseeable use to connect to a device or network?
The connection can be direct or indirect, physical or logical. A product that connects to the internet over Wi-Fi, communicates with another device via Bluetooth, or connects indirectly as part of a larger system that is itself connected is within scope.
-
Does it fall outside the limited exemptions (e.g. medical devices, motor vehicles, aviation products, spare parts, national security or defence)?
The exemptions must be assessed carefully, product by product. A manufacturer in the automotive sector, for example, may well have products outside the type-approval framework, such as diagnostic devices, charging infrastructure or aftermarket software that are within the scope of the CRA.
There are no size or revenue-based exemptions and the CRA applies to economic operators established both within and outside the EU.
Who must report?
The reporting obligations that apply from September 2026 only apply to manufacturers: entities that design, develop, or manufacture PDEs, whether themselves or through third parties, and place those products on the EU market under their own name or trade mark.
Group entities should confirm where manufacturer responsibility lies. Under the full CRA, an importer or distributor that places a PDE on the market under its own trade mark or substantially modifies a PDE already on the market will be treated as a manufacturer. However, these deemed manufacturer provisions do not appear to apply from September 2026.
What events are reportable?
Manufacturers of PDEs must report two categories of event: actively exploited vulnerabilities ("AEVs") and severe incidents ("SIs").
Reportable events
- An AEV is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner.
- An SI is an incident that either: (i) negatively affects, or is capable of negatively affecting, the ability of a PDE to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or (ii) has led, or is capable of leading, to the introduction or execution of malicious code in a PDE or in the network and information systems of a user of that PDE.
These reporting obligations apply to all in-scope PDEs, including products already placed on the market before 11 September 2026. Unlike the vulnerability handling obligations, which continue only for the length of a product’s support period, the reporting obligations continue to apply after a PDE is no longer supported.
When does the clock start?
A manufacturer is not deemed to have become aware of a reportable event the moment it detects a suspicious event or receives a third-party report. The Commission's Guidance on the CRA clarifies that the 24-hour notification window opens only when, following an initial assessment, the manufacturer has a reasonable degree of certainty that an AEV or SI has occurred (although it emphasises the need for prompt investigation, particularly where the vulnerability may pose a significant risk).
A manufacturer that knew about a vulnerability before 11 September 2026 but had no knowledge of it being actively exploited has no obligation to report retrospectively. However, if active exploitation of that vulnerability is subsequently discovered after 11 September 2026, the reporting clock starts at that point.
Notification timeline
There are three stages of reporting for each type of event, with manufacturers facing a tight 24-hour deadline for the initial report:
-
Reporting stage:
Early Warning
Reporting triggers and deadline:
Without undue delay; in any event within 24 hours of becoming aware of AEV or SI
Content of report:
For AEVs: indication of Member States where the product has been made available.
For SIs: whether unlawful or malicious acts are suspected; Member States where the product has been made available.
-
Reporting stage:
Vulnerability / Incident Notification
Reporting triggers and deadline:
Without undue delay; in any event within 72 hours of becoming aware of AEV or SI
Content of report:
General information about the product and the nature of the vulnerability or incident; initial assessment; corrective or mitigating measures taken and available to users; sensitivity of the notification.
-
Reporting stage:
Final Report (AEV)
Reporting triggers and deadline:
No later than 14 days after a corrective or mitigating measure is available
Content of report:
Description of the vulnerability, its severity and impact; information on any malicious actor involved; details of the security update or corrective measures made available.
-
Reporting stage:
Final Report (SI)
Reporting triggers and deadline:
Within one month of submission of the 72 hr incident notification
Content of report:
Detailed description of the incident, its severity and impact; likely threat type or root cause; applied and ongoing mitigation measures.
Where the required information has already been provided at an earlier stage, it need not be repeated at a subsequent stage. The CSIRT initially receiving the notification may also request an intermediate report on relevant status updates.
Where to report
Reports are submitted via the European Union Agency for Cybersecurity ("ENISA")'s electronic Single Reporting Platform simultaneously to ENISA and to the relevant Computer Security Incident Response Team ("CSIRT"), which is the national body designated under NIS 2 to coordinate responses to cybersecurity incidents. See ENISA's FAQs on the SRP.
Manufacturers with an EU establishment must notify the CSIRT of the Member State where decisions related to the cybersecurity of their products are predominantly taken. Where that cannot be determined, the relevant Member State is the one in which the manufacturer has the highest number of employees in the EU.
Manufacturers with no EU establishment must notify the CSIRT of the Member State determined by a priority order set out in Article 14(7): first the Member State of the authorised representative (if one exists, as the appointment of an authorised representative is not mandatory), then the importer, then the distributor, and finally the Member State with the highest number of users - in each case by reference to the highest volume of the manufacturer's products. Manufacturers without an EU establishment should map their distribution structure in advance to identify the correct CSIRT before an incident occurs.
Third-party component vulnerabilities
Where an AEV originates in a third-party component integrated into the manufacturer's product, the manufacturer must still report it. However, where a manufacturer is aware that a third-party component contains a vulnerability that is either unreachable, or has not been exploited in its specific product, mandatory reporting is not triggered, although it can report on a voluntary basis.
Notifying users
Manufacturers must also inform affected users and, where appropriate, all users of the vulnerability or incident and of any available risk mitigation and corrective measures. The Guidance clarifies that this obligation is to be applied in a risk-based and proportionate manner: targeted notification of directly affected users may be appropriate, particularly for products used in sensitive or essential environments where public disclosure of technical detail could itself increase cybersecurity risk. Where a manufacturer fails to notify users in a timely manner, the relevant CSIRT may, where it considers this proportionate and necessary, step in to inform users.
Penalties
Non-compliance with the reporting obligations falls within Tier 1 of the CRA's fines structure: fines of up to €15 million or 2.5% of global annual turnover (whichever is higher). Microenterprises and small enterprises are shielded from administrative fines specifically for missing the 24-hour Early Warning notification deadline.
Practical steps
The 24-hour early warning deadline leaves no room to build processes after an incident occurs. Manufacturers need dedicated procedures for receiving, assessing, and escalating information about potential vulnerabilities and incidents - procedures that work under pressure around the clock. Responsibility must be clearly allocated for deciding whether the reporting threshold is met, for filing notifications, and for managing communication with affected users.
Manufacturers should also prepare for platform access in advance. Registration on the platform itself is only required when a notification is due, but setting up access should not wait until that moment.
A single incident will frequently engage reporting obligations under the CRA, NIS 2, and GDPR simultaneously, each with different deadlines, recipients, and content requirements. Unless and until a consolidated reporting channel is introduced pursuant to the Digital Omnibus, manufacturers should map how CRA notifications will be coordinated with these parallel obligations - ideally as part of a single incident response process.
Manufacturers that rely on third-party components for core product functionality should also review whether their supplier contracts require prompt disclosure of vulnerability and incident information. The 24-hour deadline does not pause while a manufacturer waits for information from a component supplier.
Get in touch
Read Louisa Chambers Profile
-
Louisa Chambers
- Head of Technology & Commercial Transactions
- +44 20 7295 3344
- Email Me
