The EU Cyber Resilience Act (CRA) introduces a structured, legally binding framework for how manufacturers of products with digital elements must manage vulnerabilities. While much attention has focused on conformity assessment requirements, the vulnerability handling and reporting obligations carry their own distinct deadlines - and the first of those is already approaching.
Manufacturers must comply with the CRA's incident reporting obligations by September 2026, well ahead of the full product compliance deadline. Critically, this obligation applies to products already on the market, not only to new releases.
Where Vulnerabilities Come From: Three Input Streams
Effective CRA compliance begins with recognising that vulnerabilities reach manufacturers through multiple channels, each carrying its own operational implications.
Field reports arrive when vulnerabilities are detected in products already deployed. Receiving these reliably requires a documented Vulnerability Disclosure Policy (VDP) - a mechanism for external researchers, customers, and security professionals to report findings to the manufacturer in a structured way. Under CRA Article 13, this is a legal requirement, not a best practice.
Supplier notifications reflect the composite nature of most products. Few manufacturers build every component themselves. When a component supplier identifies a vulnerability in something they ship to you, they are obligated to inform downstream users. Those notifications feed directly into the manufacturer's own vulnerability management process.
Proactive discovery is the third stream - and the one manufacturers cannot substitute with reactive processes alone. Periodic penetration testing and internal security reviews are recognised approaches for maintaining an active awareness of a product's vulnerability landscape before others discover it first.
A Three-Tier Obligation Framework
The CRA does not impose a single undifferentiated duty. It establishes three distinct tiers of obligation, each triggering different requirements.
Tier 1 - Assess all vulnerabilities. Manufacturers must actively manage any vulnerability that could be relevant to their product and assess its risk. There is no threshold below which a vulnerability may be ignored at the outset. The obligation is to look and to assess.
Tier 2 - Track known, exploitable vulnerabilities to closure before market release. Once a vulnerability is identified as exploitable in the context of the specific product, the manufacturer must address it before placing the product on the market. The CRA's standard is deliberate: products must be free of known exploitable vulnerabilities, not free of all vulnerabilities. Where a vulnerability exists but is demonstrably not exploitable in the product's deployment context - with documented justification - it may remain. Zero vulnerabilities is not a realistic or required standard; zero unjustified exploitable vulnerabilities is.
Tier 3 - Report actively exploited vulnerabilities without delay. When a manufacturer becomes aware that a vulnerability in their product is being actively exploited in the field, this constitutes a severe incident under the CRA. It triggers mandatory reporting obligations to ENISA at EU level and to the relevant national CSIRT (in Germany, BSI; requirements vary by Member State). These obligations apply regardless of how old the affected product is.
The EUVD: The Authoritative Reference for “Known” Vulnerabilities
A practical question arising from Tier 2 is: how does a manufacturer establish whether a vulnerability is “known”? The answer is the EU Vulnerability Database (EUVD), which functions as the authoritative European reference for this purpose.
The EUVD mirrors the content of the CVE and NVD databases maintained in the US by MITRE, meaning all CVEs are represented. Crucially for compliance purposes, the EUVD also includes an exploitability rating for each entry. Once a vulnerability appears in the EUVD, it is difficult to sustain a claim that it was unknown to the manufacturer. The exploitability classification provides a defensible threshold for prioritising vulnerability management efforts.
Manufacturers should integrate EUVD monitoring into their vulnerability management workflows, with automation where possible, to ensure they are not operating on stale intelligence.
Reporting Timelines: Precision Matters
When a vulnerability is actively exploited - triggering the Tier 3 obligation - the CRA imposes strict reporting timelines that leave no room for delay:
- Within 24 hours of becoming aware: submit an early warning to the CRA Single Reporting Platform.
- Within 72 hours: submit a detailed report covering technical scope and known indicators of compromise.
- Within 14 days (for vulnerabilities) or 30 days (for significant incidents): submit a final report including root cause, timeline, fix, and disclosure strategy.
These reports flow through the EU Single Reporting Platform, currently in pilot testing under ENISA coordination, from which they are distributed to ENISA centrally and to the relevant national CSIRTs. Authorities receiving the reports are not passive recipients - they have disclosure obligations of their own. Manufacturers are required to include a disclosure strategy within their submissions. Responsible disclosure, calibrated to avoid assisting threat actors while enabling legitimate situational awareness, is part of the compliance requirement, not an afterthought.
Exploitable vs. Exploited: The Legal Distinction
These two terms appear similar in ordinary language. In the CRA framework, they carry materially different legal consequences.
An exploitable vulnerability is one that could theoretically be used by an attacker - but has not yet been actively weaponised. Exploitable vulnerabilities are the subject of the Tier 2 obligation: they must be addressed before a product reaches the market, or justified as acceptable risk in the specific deployment context.
An actively exploited vulnerability is one where an attacker has successfully leveraged the flaw against a real product in the field. This is the Tier 3 trigger: the 24-hour reporting obligation.
One unresolved question that has been raised to the European Commission concerns proof-of-concept (PoC) exploit code. A published PoC demonstrates that exploitation is technically feasible, but does not establish that an active, sustained attack campaign is underway. The Commission has not yet issued guidance with legal certainty on this distinction. Until it does, manufacturers should err towards treating published PoC as escalatory and monitoring closely for indicators of active exploitation.
What This Means in Practice
The September 2026 deadline is not the end of the compliance journey - it is the start of the most operationally demanding part of it. Manufacturers who have not yet established a Vulnerability Disclosure Policy, mapped their component supplier notification chains, or built EUVD monitoring into their workflows should treat this deadline as a forcing function.
The CRA's vulnerability handling framework rewards manufacturers who treat security as a continuous operational discipline rather than a pre-release checklist. The regulatory exposure for those who do not is now both concrete and time-bound.