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 reporting obligations from 11 September 2026, more than a year ahead of 11 December 2027, when the rest of the Regulation applies. Critically, these obligations reach products already on the market. Article 69(2) generally exempts products placed on the market before 11 December 2027 unless they undergo a substantial modification, and Article 69(3) then derogates from that specifically for Article 14. Reporting therefore applies to every in-scope product placed on the market before that date, which is the opposite of the usual assumption about legacy portfolios.
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 coordinated vulnerability disclosure policy - a mechanism for external researchers, customers, and security professionals to report findings to the manufacturer in a structured way. Annex I Part II point (5) makes putting one in place and enforcing it a legal requirement, and Annex II point 2 requires the single point of contact for reports, and where the policy can be found, to be supplied with the product.
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, Article 14(1) requires notification. This is a distinct trigger from a severe incident, which Article 14(3) handles on its own track with its own final-report deadline, and conflating the two is how filings end up on the wrong clock. Notification goes simultaneously to the CSIRT designated as coordinator and to ENISA, in one submission through the single reporting platform. Article 14(7) picks that CSIRT by the manufacturer’s main establishment in the Union, meaning where decisions about the cybersecurity of its products are predominantly taken, so it does not automatically follow the registered office. These obligations apply regardless of how old the affected product is.
The EUVD: A Useful Reference, Not a Sufficient One
A practical question arising from Tier 2 is: how does a manufacturer establish whether a vulnerability is “known”? The EU Vulnerability Database (EUVD) is the obvious starting point, and it is worth being precise about what it is and what it is not.
The EUVD is operated by ENISA under Article 12(2) of the NIS2 Directive rather than under the CRA, and the CRA does not designate it as the authoritative register of known exploitable vulnerabilities. Its records carry a technical description, affected products and versions, severity, exploitation characteristics and mitigation guidance, and it maintains a view of vulnerabilities known to be exploited.
Two limits matter for compliance planning. The EUVD does not reproduce every CVE, and independent analysis has found tens of thousands of CVEs that its principal API does not surface, so treating it as a complete picture would leave real gaps. Its exploited-vulnerability listing also draws heavily on CISA KEV and omits some entries.
The practical consequence is that appearing in the EUVD makes an unaware defence hard to sustain, while absence from it establishes nothing. Manufacturers should monitor the EUVD with automation where possible, and alongside CVE and NVD, vendor and upstream advisories, and their own component feeds derived from the SBOM. Monitoring the EUVD alone is thinner coverage than the Tier 1 duty to look and assess actually requires.
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: an early warning, indicating where applicable the Member States where the product has been made available.
- Within 72 hours: a vulnerability notification giving general information about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken, and measures users can take. This is also where you indicate how sensitive you consider the information to be.
- No later than 14 days after a corrective or mitigating measure is available: a final report describing the vulnerability including its severity and impact, information on any malicious actor exploiting it where available, and details of the security update or other corrective measures.
The severe incident track under Article 14(4) runs 24 hours, then 72 hours, then a final report within one month after the 72-hour notification, covering a detailed description, the likely root cause, and applied and ongoing mitigation measures.
That difference is the one to get right. The vulnerability final report is anchored to a fix being available, so it cannot be diarised when you file at 72 hours. The incident final report is anchored to the earlier filing, so it can. Note also that “severe” is the CRA’s term. “Significant incident” belongs to NIS2 Article 23, which is a separate obligation on a separate subject.
These reports flow through the EU single reporting platform established under Article 16, which ENISA has scheduled to be operational by 11 September 2026, with a testing period before then. One submission at the coordinating CSIRT’s end-point is simultaneously accessible to ENISA, and that CSIRT then disseminates to the CSIRTs of the Member States where you indicated the product was made available. Responsible disclosure, calibrated to avoid assisting threat actors while enabling legitimate situational awareness, remains the right operating posture, though it is worth being clear that Article 14 does not itself require a “disclosure strategy” as a named element of any of the three filings.
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 11 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 coordinated vulnerability disclosure policy, mapped their component supplier notification chains, determined their coordinating CSIRT under Article 14(7), or built vulnerability 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.