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

A continuous process should match disclosed vulnerabilities against SBOM component inventories. Manufacturers could monitor:

• Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog
• Vulnerability databases such as ENISA’s European Vulnerability Database (EUVD) and the NIST National Vulnerability Database (NVD)  
• Vendor and supplier security advisories
• Threat intelligence feeds relevant to the product category

Security automation processes support a risk-based vulnerability management approach. They help teams correlate vulnerability sources with product data, assess potential product impact, and retain evidence of triage decisions.

This approach improves collaboration between security and engineering teams. It supports company readiness for CRA vulnerability handling and reporting obligations. 

Establish the Reporting Workflow

ENISA’s SRP will be operational by September 2026. Before that date, manufacturers should define internal policies and procedures, as well as a responsibility matrix for escalation paths.

This process is usually cross-functional. The exact teams involved will depend on the company’s size, product complexity, and internal structure. Groups that may participate include:   

• PSIRT  
• Engineering  
• Product management  
• Legal and compliance  
• Customer support  
• Supply chain  
• Communications
• Executive stakeholders  

Aligning all relevant internal stakeholders ensures that technical analysis, regulatory assessment, customer impact, and internal approval receive proper coverage when reporting timelines are tight.

Each reporting stage needs a short runbook in checklist format that should specify:  

• Who is responsible
• What information is required  
• Who approves before submission  

These should be concise, actionable documents rather than high-level policy statements.

Before September 2026, manufacturers should run at least one tabletop exercise simulating the full reporting chain:  

• Detection of an exploited vulnerability  
• Triage  
• Reportability decision
• Early warning drafting
• SRP submission

Publish a Coordinated Vulnerability Disclosure (CVD) Policy

The CRA requires a published CVD policy by December 2027 (Article 13). Establishing one ahead of the reporting deadline provides the intake channel needed to receive external reports of exploitation.

A practical CVD process should describe how external vulnerability reports are:  

• Received  
• Acknowledged  
• Triaged  
• Validated  
• Remediated  
• Coordinated for disclosure  

Companies do not need to design their vulnerability intake and handling process from scratch. Standards and guidance offering useful starting points include:  

• ISO/IEC 29147  
• ISO/IEC 30111  
• RFC 9116 security.txt  
• The emerging prEN 40000-1-3 work on vulnerability handling  

The intake process should connect to the internal triage workflow so that a report of active exploitation immediately starts the 24-hour reporting clock. 

Engage the Supply Chain

For products that include third-party components, meeting the 24-hour reporting window depends in part on supplier responsiveness. Manufacturers should confirm that each supplier can provide:

• Component-level SBOMs in machine-readable format
• Timely notification of known exploited vulnerabilities in their components (with “timely” defined contractually)
• Patch availability commitments for critical security updates

Where these commitments do not exist, manufacturers should negotiate them into supplier agreements.  

Register for SRP Access

ENISA’s FAQ confirms that manufacturers must register before submitting reports through the SRP.  

Manufacturers should monitor ENISA’s SRP page for registration announcements and prepare the following registration data in advance:  

• Legal entity information  
• In-scope product list  
• Designated reporting contact
• The Member State of the main EU establishment   

Manufacturers should register as soon as the platform opens.

Establish a User Notification Channel

Article 14(8) requires manufacturers to inform affected users of vulnerabilities and incidents without undue delay. For IoT devices, this may mean:

• A published security advisories page
• An email notification list
• Device-level push notifications

Manufacturers should identify which channel reaches the installed base and confirm it is operational before September 2026. For products without a direct communication channel to end users, the notification path may run through distributors, resellers, or a public advisory page. 

Penalties for CRA Non-Compliance

Non-compliance with CRA reporting obligations can result in fines of up to €15 million or 2.5% of the manufacturer’s global annual turnover, whichever is higher. When setting fine amounts, authorities must account for enterprise size, including microenterprises, SMEs, and startups. Smaller companies are not exempt from reporting. 

What Comes After September 2026

The reporting infrastructure manufacturers build for September 2026 feeds directly into the broader CRA requirements that take effect on December 11, 2027. Those requirements extend beyond reporting to cover the full product security lifecycle, including vulnerability handling and end-of-support obligations. The operational groundwork for September 2026 serves as the foundation for long-term CRA compliance.

CRA vulnerability reporting obligations take effect in September 2026. Telit Cinterion can help manufacturers assess readiness and build reporting infrastructure.