CRA Vulnerability Reporting: What IoT Manufacturers Need to Know Before September 2026

Estimated reading time: 12 minutes

The first EU Cyber Resilience Act (CRA) vulnerability reporting obligations begin on September 11, 2026. On that date, manufacturers of products with digital elements on the EU market must report actively exploited vulnerabilities and severe security incidents to EU authorities.

This reporting mandate falls under Article 14 of the CRA. It is separate from the product-level cybersecurity requirements under Article 13, which do not apply until December 11, 2027.    

For an overview of the full Cyber Resilience Act, see our EU Cyber Resilience Act blog.

What Triggers a CRA Report 

Two separate categories of events require reporting under Article 14: actively exploited vulnerabilities and severe security incidents. Each has its own trigger and timeline.

Actively Exploited Vulnerabilities

A manufacturer must report to the European Union Agency for Cybersecurity (ENISA) when reliable evidence confirms that a malicious actor has exploited a vulnerability in a product. This does not include authorized activities such as penetration testing and bug bounty programs.  

Confirmed active exploitation triggers the reporting obligation. A published Common Vulnerabilities and Exposures (CVE) entry or the existence of a theoretical risk does not.

Severe Security Incidents

Manufacturers must also report severe incidents that affect product security. This includes incidents that negatively affect or could negatively affect the availability, authenticity, integrity, or confidentiality of data or functions.  

The incident must compromise the security of the product or the processes used to develop, produce, or maintain it. For example, if an attacker breaches the public key infrastructure (PKI) used to authenticate devices during manufacturing, that qualifies as a severe security incident.     

Where to Report: ENISA’s Single Reporting Platform and CSIRT Routing

Manufacturers submit reports through ENISA’s Single Reporting Platform (SRP). The platform routes each notification to the national Computer Security Incident Response Team (CSIRT) in the manufacturer’s Member State of establishment. It will simultaneously make the report accessible to ENISA. Manufacturers notify once; the platform handles distribution.

The SRP is expected to be operational by September 11, 2026, following a pre-launch testing period. ENISA has published an FAQ on the SRP explaining the information manufacturers must provide when submitting a report. Details are listed under the FAQ “What information must be included in the report?”

Application Programming Interfaces (APIs) are not expected to be included in the first SRP release. Automated report submission via API will not be supported.

Manufacturers with an existing incident response plan will almost certainly need to revise it to meet the requirements of Article 14 of the CRA. Particular attention should be given to reporting workflows and timelines, taking into account the obligations under other applicable rules (e.g., EU 2022/2555 NIS2, GDPR) or sector-specific reporting regimes.

As part of the European Commission’s objective to simplify the EU New Legislative Framework through digital tools, the Commission published proposal 2025/0360. The proposal aims to make ENISA’s SRP the common portal for reporting obligations under several EU rules.

Non-EU Manufacturers

For manufacturers based outside the EU, the coordinator CSIRT is determined by the Member State of the entity responsible for placing the product on the EU market. This may be:  

• An EU subsidiary
• An importer
• A distributor
• A voluntarily appointed authorized representative  

Non-EU manufacturers should identify which entity places their product on the EU market and confirm the corresponding Member State CSIRT before September 2026. The receiving CSIRT shares each notification with CSIRTs in all Member States where the product has been made available. Manufacturers can request a delay if premature dissemination could increase exploitation risk, such as while a patch is in development (Commission Delegated Regulation (EU) 2026/881).

Notifying Affected Users

Article 14(8) also requires manufacturers to notify affected users of the vulnerability or incident, and of any corrective measures, without undue delay. The CRA uses the phrase “where appropriate.” Unless a manufacturer can definitively confirm that only a specific subset of users is impacted, notification should extend to all users of the product.

If a manufacturer does not do so in a timely manner, the receiving CSIRT may notify users directly.

CRA Vulnerability Reporting Timeline

Both reporting tracks follow a staged notification process, but the final report deadlines differ.    

Actively Exploited Vulnerabilities Timeline

• Early warning within 24 hours of becoming aware of the exploitation. This is a preliminary alert, not a full analysis. It must identify the affected product and indicate the Member States where the product has been made available.
• Detailed notification within 72 hours. This includes an initial assessment of severity, scope, and any corrective or mitigating measures taken or planned.
• Final report within 14 days of a corrective or mitigating measure becoming available. This must include a description of the vulnerability, its severity and impact, information about the exploiting actor (where available), and details about the security update or corrective measures.

Severe Security Incidents Timeline

• Early warning within 24 hours of becoming aware of the incident. This must indicate whether unlawful or malicious acts are suspected to have caused the incident. It must also identify the Member States in which the product has been made available.
• Detailed notification within 72 hours. The notification must cover the nature of the incident, an initial assessment of its scope, corrective actions taken or planned, and any steps users should take.
• Final report within one month of the 72-hour notification. This must describe the incident and its severity, identify the likely threat type or root cause, and detail both completed and ongoing mitigation efforts.

The 24-hour clock starts when the manufacturer becomes aware of the active exploitation or severe incident, not when the CVE was first published or when the vulnerability was first discovered.

Which Products Are in Scope 

Reporting obligations are not limited to new products. Under Article 69(3), they apply to all products with digital elements on the EU market, regardless of when they were placed on the market. For example, a device sold in 2023 is in scope starting September 2026. 

However, for legacy products, complete software inventories may not exist. Original tooling or build environments may no longer be available. Therefore, other CRA obligations, such as vulnerability handling under Article 13, do not extend to preexisting products.   

Need help assessing your existing product portfolio for CRA scope? Talk to our team.

CRA Reporting and the Supply Chain

The CRA imposes reporting obligations on the manufacturer, defined as the entity placing the product on the EU market. Meeting a CRA 24-hour notification window requires visibility into every software component in the product, including:  

• Third-party libraries
• Open-source code
• Firmware from component suppliers

A complete and current software bill of materials (SBOM) for each product in scope is the operational prerequisite for determining whether a newly disclosed vulnerability affects that product.

While the legal obligation belongs to the manufacturer, the operational requirements extend to the supply chain. Companies that supply components rather than finished products should expect their customers to require transparency into:  

• Software contents of each component
• Known vulnerabilities affecting those components
• Patch and mitigation strategies for critical security updates

Without that information from suppliers, manufacturers cannot assess whether a disclosed vulnerability affects their products. 

How to Prepare for CRA Vulnerability Reporting

The following measures are operationally necessary to meet the September 2026 CRA vulnerability reporting deadline. Some (such as SBOM maintenance and CVD policies) are not legally required until December 2027 under Article 13. 

Map Software Components and Related Cyber Risks

Manufacturers should establish a process to manage SBOMs for all in-scope products in a machine-readable format (e.g., CycloneDX or SPDX). This includes products already on the EU market, not just those in development.

For legacy products where build-time SBOMs do not exist, software composition analysis (SCA) tooling can support this process, scanning current firmware images to generate a baseline.

An SBOM is the starting point. It shows which software components are inside a product. This visibility is essential for understanding potential exposure.  

But an SBOM alone cannot provide insights into potential cyber risk. It does not show whether a vulnerability can be exploited in the final product’s specific configuration or whether the vulnerability matters in practice.  

This is where Vulnerability Exploitability eXchange (VEX) becomes valuable. VEX adds the missing context and answers the real questions: Does this CVE affect my product? Is it irrelevant? Under review? Already fixed?

Together, they turn software transparency into actionable vulnerability triage and clearer risk visibility.

Set Up Vulnerability Monitoring