In brief · As of: September 2026
Annex I Part I(2)(a) of the Cyber Resilience Act requires that products "be made available on the market without known exploitable vulnerabilities". When a vulnerability is known, the regulation does not say. The Commission guidelines under Art. 26 (C(2026) 5252, para. 233) fill the gap: known is what is listed in a publicly accessible database such as the EUVD or another prominent database. On our reading, that includes the public advisories and CSAF feeds of controller manufacturers. For plant builders this means: a published CVE for the installed controller counts as known even if no e-mail about it arrived, and it counts at the moment of placing on the market, not at the software freeze.
The regulation requires "without known exploitable vulnerabilities" but does not define "known"
The requirement sits in Annex I Part I(2)(a): on the basis of the risk assessment under Art. 13(2), products with digital elements shall, where applicable, "be made available on the market without known exploitable vulnerabilities". Two of the three terms are defined. A "vulnerability" under Art. 3(40) is a weakness, susceptibility or flaw that can be exploited by a cyber threat. An "exploitable vulnerability" under Art. 3(41) is one "that has the potential to be effectively used by an adversary under practical operational conditions".
There is no definition of "known". The Commission says so itself in its guidelines (para. 232): the regulation requires procedures for handling reported vulnerabilities but does not explicitly specify when an exploitable vulnerability should be considered known by the manufacturer, thereby triggering the obligation at the moment of placing on the market. Whether a plant builder breached Annex I when placing a system on the market depends on this question.
The Commission ties "known" to public databases
Para. 233 of the guidelines answers the question: a vulnerability should be regarded as known when it is listed in relevant publicly accessible vulnerability databases, namely the European Vulnerability Database established under Art. 12(2) of the NIS 2 Directive or other prominent databases. Para. 234 adds three further routes: non-public information such as coordinated disclosure by a security researcher; the manufacturer's own testing and analysis; and prominent reports in reliable media outlets including specialised cybersecurity publications.
The guidelines are issued under Art. 26 CRA and are not legally binding; only the Court of Justice can interpret the regulation authoritatively. They are, however, the Commission's official reading, and a market surveillance authority will rely on them. A manufacturer that did not check the EUVD before delivery will therefore find it hard to plead ignorance to the authority.
The "other databases" include the manufacturers' public feeds
Para. 233 names the EUVD as an example ("such as") and places "other prominent vulnerability databases" beside it. Recital 34 phrases the same as "other publicly accessible vulnerability databases". In both cases the criterion is public accessibility, not the operator. Which sources fall under it, neither the regulation nor the guidelines say conclusively.
On our reading, the public security advisories of component manufacturers are among them, for three reasons. Annex I Part II(4) requires every CRA manufacturer to publicly disclose information about fixed vulnerabilities; the advisory pages and CSAF feeds of controller manufacturers fulfil exactly that obligation and are thus public, structured registers of vulnerabilities. The guidelines themselves treat manufacturer advisories as an equivalent source of knowledge: para. 223 recommends checking "publicly accessible vulnerability databases, project-specific security advisories, or established issue trackers" before reporting upstream. And recital 34 lists, next to the database check, "checking its security updates history" as a due diligence action for a component; that history exists nowhere but in the manufacturer's advisory record.
In addition, the major controller manufacturers assign CVE numbers to their vulnerabilities themselves. What is published there reaches the EUVD through the CVE programme anyway, usually with a delay. Anyone who checks only the EUVD checks the same information later. The controller manufacturer's public feed is therefore not merely a channel through which an advisory will hopefully arrive, but a source whose content counts as known once it is published there.
A database entry makes the vulnerability known, but not yet exploitable
The guidelines narrow the database rule in para. 235: the mere fact that a vulnerability is reported or listed does not, in itself, mean that it is exploitable in practice or applicable to the specific product. The manufacturer has to investigate the entry and establish whether it applies to its own product. A limited period may therefore elapse between listing and confirmation; what is required is a prompt investigation.
What "exploitable under practical operational conditions" means is spelled out in the Commission FAQ (v1.4, no. 4.2.2): relevant factors include whether the vulnerable code is invoked or loaded at all when the product is in use, the level of access required for the exploit and whether compensating controls are already in place. The FAQ's example is a smartphone whose password check can only be bypassed with physical access and a laser glitch; the manufacturer may classify that as not exploitable, with reasons. For a plant system the corresponding argument is, for instance, that the vulnerable service is disabled or that the controller sits in a network zone without remote access. The classification is a decision under para. 237, weighing severity, exploitability and impact, and it belongs in the technical documentation together with its reasoning.
A published CVE for the installed controller counts as known, even without an e-mail from the supplier
The layered model of the CRA allows plant builders to rely on the advisories and updates of component manufacturers when handling vulnerabilities. For the question whether a vulnerability was known at the moment of placing on the market, that division of labour does not help under para. 233. A CVE for the installed controller that is listed in the EUVD, in another prominent database or in the controller manufacturer's public advisory is known to the plant builder, even if no e-mail about it arrived or it sits in a service technician's inbox. Recital 34 of the regulation points the same way for due diligence under Art. 13(5). It names as a possible action "verifying that a component is free from vulnerabilities registered in the European vulnerability database [...] or other publicly accessible vulnerability databases".
The check presupposes that the component inventory per system is available: manufacturer, type and firmware version of the installed devices. Without it, no database can be queried. It also needs an identifier through which a database entry can be matched to the component. Why that step in particular is the bottleneck for industrial components is covered in the article on suppliers without CSAF.
The relevant moment is placing on the market, not the software freeze
Under Art. 13(1), the obligation in Annex I Part I applies at the moment of placing on the market. In para. 236 the guidelines also address the case where a vulnerability becomes known only during the final stages of development or shortly before the product enters the distribution chain: it counts too. In plant engineering the governing software version is often settled around twelve months before delivery. Everything that enters the EUVD for the installed firmware during those twelve months is known on the cut-off date. The requirement itself applies, under Art. 71(2), to systems placed on the market from 11 December 2027; for systems delivered earlier it applies only after a substantial modification (Art. 69(2)). Anyone quoting a system today with delivery in 2028 is therefore already inside the window.
The guidelines do not demand a shipping halt for that. Under para. 237 the requirement is risk-based: the manufacturer decides, on the basis of the risk assessment, whether the product can be securely placed on the market despite the new vulnerability or whether it has to be fixed first. The risks of postponing the release may also enter the assessment, for instance where the system has to keep critical processes running. The guidelines require a reasoned decision, not a particular outcome.
After placing on the market, a different yardstick applies. According to the Commission FAQ (no. 4.2.3), a vulnerability that becomes known between placing on the market and handover to the user does not constitute a breach of Annex I Part I. It has to be addressed without delay under Annex I Part II(2), where necessary with a security update at commissioning. For plant systems, months often pass between delivery and commissioning. Which vulnerabilities fall into that period and which do not can only be shown with a documented date of placing on the market.
The regulation uses three different thresholds for vulnerabilities
The three thresholds are frequently confused in practice, above all the first with the second:
| Term | Provision | Threshold | Consequence |
|---|
| known exploitable vulnerability | Annex I Part I(2)(a); guidelines para. 233 | listed in the EUVD or another prominent database, or known by other means, and exploitable under operational conditions | must not be placed on the market as is, unless the risk assessment supports the decision |
| actively exploited vulnerability | Art. 3(42); Art. 14(1) | reliable evidence that a malicious actor has exploited it in a system | early warning to ENISA within 24 hours of becoming aware |
| vulnerability during the support period | Annex I Part II(2); Art. 13(8) | any vulnerability of the product including its components | to be addressed and remediated without delay |
A CVE without evidence of exploitation does not trigger a report under Art. 14. For a system not yet placed on the market, however, the same CVE decides whether shipping it in that state is permissible.
Three things have to be documented before delivery
- Document the check before placing on the market. Compare the system's component inventory against the EUVD and the component manufacturers' public advisories, with a date. That is the due diligence action recital 34 describes.
- Record the decision under para. 237. For every known vulnerability in the installed components: not applicable, not exploitable with reasons, fixed, or shipped with a documented residual risk. This list is what stands behind the signature on the declaration of conformity.
- Record the date of placing on the market per system. It decides which vulnerabilities fall under Part I and which belong to handling under Part II.
See the database check for one system in the demo →
Werkspilot continuously compares the component inventory of delivered systems against the EUVD, further databases and supplier notices and documents the assessment in an auditable way. This article reflects the state of the regulation at the time of publication and is not legal advice. The regulation text prevails; the Commission guidelines (as of 27 July 2026) and the FAQ (v1.4, 4 September 2026) are not legally binding.
