The mandatory reporting obligations under the Cyber Resilience Act (Regulation (EU) 2024/2847) (the “CRA“) are due to take effect on 11 September 2026. Accordingly, entities developing, importing or distributing products with digital elements (“PDEs“) in the EU have a narrow window left to ensure their vulnerability and incident reporting processes are ready for compliance with these new obligations.
The CRA complements the NIS 2 Directive by introducing mandatory cybersecurity requirements for PDEs to provide a more comprehensive security framework in the EU. It shifts product security to a proactive obligatory framework, requiring security by default and design as well as product security lifecycle obligations. By making cybersecurity an essential component of product safety, the CRA forces businesses to view cybersecurity as a gateway requirement for a product’s entry into the EU market.
For a more in-depth analysis of the CRA, see our previous insight, EU Cyber Resilience Act Comes Into Force.
What products are in scope of the CRA?
For a product to be considered within the scope of the CRA, it must meet the following four cumulative criteria:
- Is the product a PDE? A PDE is any software or hardware product, and its remote data processing solutions, that connects directly or indirectly to a network (e.g. laptops, smart devices, OS, mobile apps, Industrial IoT). This includes software and hardware components being placed on the market separately. It also includes standalone software, software intended for integration into hardware devices, software placed on the market together with a hardware product, as well as various hardware products such as laptops, machinery, and foundational components.
- Is the product being “made available” on the EU market? ‘Making available on the market’ involves the supply of a PDE for distribution or use in the EU in the course of a commercial activity, regardless of whether it is for payment or free of charge. While free and open-source software that is not supplied in the course of a commercial activity does not fall within this requirement, it is important to be aware that the CRA provides for a lighter compliance regime for open-source software products.
- Is the product’s intended (or reasonably foreseeable) use that it is to be connected to a device or network? The logical or physical data connection can occur directly (e.g., via USB cable or a logical connection) or indirectly (e.g., via a host system).
- Does the product fall into the limited exemptions? Limited exemptions apply, including for products already regulated under sector-specific EU legislation (such as medical devices, marine equipment, aviation products and motor vehicles).
The CRA applies to economic operators established both within and outside the EU, regardless of whether the PDE is manufactured in the EU.
If a product falls within scope of the CRA, manufacturers must assess its classification under the CRA’s risk-based classification system. The classifications are as follows:
- Default PDEs includes all other PDEs not classified as Important or Critical PDEs;
- Important Class I PDEs (as listed in Annex III CRA) including standalone and embedded browsers, network management systems, physical and virtual network interfaces;
- Important Class II PDEs (as listed in Annex III CRA) including firewalls, intrusion prevention systems, tamper-resistant microprocessors and microcontrollers; and
- Critical PDEs (as listed in Annex IV CRA) including hardware devices with security boxes, smart meter gateways with smart metering systems, and smartcards or similar devices.
The classification of the PDE determines the relevant conformity assessment procedure (i.e., self-assessment or third party assessment) to be used to evaluate whether the PDE is in conformity with the essential cybersecurity requirements set out in Annex I of the CRA.
Which economic operators fall within scope of the CRA?
The obligations under the CRA vary according to each economic operator’s role in the PDE supply chain. The most extensive obligations apply to manufacturers, namely entities that design, develop, or manufacture PDEs (either themselves or through third parties acting on their behalf), and place those products on the EU market under their name or trademark. Manufacturers can appoint an authorised representative to assist with ensuring and documenting compliance, as well as cooperating with market surveillance authorities in the EU.
Importers and distributors are subject to substantially reduced CRA obligations focused on ensuring that the manufacturer and the relevant PDE is in compliance with the CRA and notifying the manufacturer of any vulnerabilities or incidents it becomes aware of. Additionally, both types of economic operators are required to notify non-conformity to the manufacturer and the market surveillance authorities (as appropriate), and under take appropriate corrective measures to ensure conformity.
While not subject to the full manufacturer obligations under the CRA, open-source software stewards, who support the development of free and open-source software that do not meet the four-cumulative criteria set out above, will face a lighter compliance regime under the CRA.
It is important to note that in circumstances where substantial modifications are made to a PDE already placed on the market, economic operators such as importers, distributors or other third parties may be considered to be the manufacturer of the PDE, and subject to manufacturer-related obligations under the CRA.
What are the key manufacturer obligations?
The obligations of manufacturers span the lifecycle of the PDE which starts at the pre-market design and development stage, and continues for the support period (as defined by the manufacturer) or until the company ceases to exist.
The following are some key obligations imposed on manufacturers under the CRA:
- Security by design: Manufacturers must ensure that PDEs are designed, developed and produced to meet the essential cybersecurity requirements set out in Annex I before being placed on the market.
- Risk assessment: Manufacturers must carry out, document and continually update a cybersecurity risk assessment throughout the PDE’s support period.
- Vulnerability handling: Manufacturers must effectively manage vulnerabilities for the duration of the support period, which must run for at least five years, or the product’s expected lifespan if shorter.
- Vulnerability and incident reporting: Manufacturers have mandatory incident and vulnerability reporting obligations (discussed further below).
- Conformity and documentation: Manufacturers must complete the applicable conformity assessment procedure, issue an EU declaration of conformity, affix the CE marking on the PDE, and retain supporting technical documentation for at least ten years.
Vulnerability and Incident Reporting
Mandatory vulnerability and incident reporting obligations will apply to manufacturers from 11 September 2026. These obligations will apply to all in-scope PDEs, including PDEs that have already been placed on the market before the CRA becomes fully applicable on 11 December 2027. In addition, unlike vulnerability handling obligations, which apply only for the duration of a product’s support period, mandatory reporting obligations shall continue to apply, even after the support period for in-scope PDEs has ended.
| Reporter: | Manufacturers |
| What to report? | 1. Actively exploited vulnerabilities (“AEVs”) are vulnerabilities for which there is reliable evidence that no malicious actor has exploited it in a system without permission of the system owner (e.g., where a malicious actor exploits a flaw in the PDE resulting in a security breach impacting its users or any other natural or legal persons).
2. Severe security incidents (“SSIs”) are incidents that negatively affect or are capable of negatively affecting the ability of a PDE to protect the availability, authenticity, integrity or confidentiality of data or functions. |
| Who to report to? | Regulators: Reports must be submitted simultaneously to the European Union Agency for Cybersecurity (“ENISA“) and the relevant Computer Security Incident Response Team (“CSIRT“) via the ENISA’s electronic single reporting platform which will go live on 11 September 2026.
Impacted Users: Manufacturers must inform impacted users (and, where appropriate all users) of the vulnerability or incident, and any risk mitigation and corrective measures they can take. If manufacturers fail to do so in a timely manner, the CSIRT will notify the users instead. |
| What is the timeline? | Early Warning Notification without undue delay and in any event within 24 hours of becoming aware.
Vulnerability Notification (unless the relevant information has already been provided) without undue delay and in any event within 72 hours of becoming aware. Final Report (unless the relevant information has already been provided)
|
Penalties for Non-Compliance
Enforcement sits with Member State market surveillance authorities, which have broad powers to investigate, restrict, withdraw, or recall non-compliant products. While not yet formally designated, the National Cyber Security Centre of Ireland is anticipated to be the market surveillance authority for Ireland.
The CRA establishes the following three-tiered fines structure:
- Tier 1 – Fines up to €15 million or 2.5% of global annual turnover, whichever is higher, for non-compliance with the essential cybersecurity requirements and the core manufacturer obligations (including vulnerability and incident reporting).
- Tier 2 – Fines up to €10 million or 2% of global annual turnover, whichever is higher, for infringements of other obligations such as failure of compliance with importer and distributor duties, and failure to cooperate with market surveillance authorities.
- Tier 3 – Fines up to €5 million or 1% of global annual turnover, whichever is higher, for the provision of incorrect, incomplete or misleading information to market surveillance authorities or notified bodies.
The CRA provides two narrow fines-related exemptions. Microenterprises and small enterprises are shielded from administrative fines for missing the 24-hour Early Warning Notification deadline under Article 14 referenced above. Open-source software stewards are excluded from the fines regime entirely.
Timeline for implementation
- 11 September 2026 – The mandatory vulnerability and incident reporting obligations will come into effect.
- 11 December 2027 – The remaining provisions will come into full effect. Any products that do not comply by this date cannot be lawfully placed on the EU market.
Economic operators will feel some relief that the CRA does not have full retroactive effect. Where PDEs are placed on the market before 11 December 2027, they will not be subject to the requirements of the CRA (except for the mandatory vulnerability and incident reporting obligations). However, if such PDEs are subject to post-market changes after that date which are considered a substantial modification (i.e., a change that alters the cybersecurity risk level or the intended purpose of the PDE, and was not accounted for in the original risk assessment), the full scope of the CRA obligations will apply.
Next steps
Unlike the NIS 2 Directive, the CRA offers no size or revenue-based exemptions, so its practical impact will be substantial even where existing cybersecurity practices can be leveraged. In-scope economic operators will have to adapt to the new requirements, monitor and report incidents and vulnerabilities, and face significant potential penalties for non-compliance. Therefore, all natural and legal persons placing, or intending to place, products in the EU market should be assessing now as a priority whether such products are in scope of the CRA.
Contact us
If you have any questions on anything contained in this article or require CRA compliance advice, please contact any member of our Technology and Innovation Group or your usual Matheson contact.
