Modules

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

By Enrico Milanese

Federico Della Valle

July 21, 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.

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

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.

Awareness of active exploitation may come through multiple channels:

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.

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.

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:

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).

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.

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

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.

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.

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:

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:

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

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.

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.

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

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.

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:

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:

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

Prepare for CRA Vulnerability Reporting

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

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:

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

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

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:

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

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