When is a vulnerability known and exploitable under the CRA?

Article 3 defines three nested categories, and each one triggers a different obligation.^[1]

The categories narrow from left to right in the table. Every actively exploited vulnerability is exploitable. Most vulnerabilities in a component inventory are neither. The dates come from Article 71(2), which moves Article 14 forward to 11 September 2026 and leaves Annex I on 11 December 2027.^[4]

A vulnerability is exploitable when an adversary could use it under the conditions the product actually operates in.^[1] Commission guidance excludes vulnerabilities that can only be exploited in theoretical conditions, such as a lab or a simulation, or in conditions that would not occur in the product's operational environment.^[6]

The Commission services FAQ names three factors for the case-by-case judgement.^[7] The first is the extent to which the vulnerable code is invoked or loaded when the product is in use. The second is the level and type of access the exploit requires. The third is whether compensating controls already mitigate exploitation.

The FAQ gives a worked example. A smartphone flaw that bypasses a password check, but needs physical access and a laser to induce a glitch, may be judged not exploitable in practical operational conditions.^[7] A second example covers a Wi-Fi router with a buffer overflow in a library whose functions the firmware never calls. The risk assessment shows the vulnerability cannot be exploited, so the manufacturer may document it, skip a dedicated update, and remove the unused library in the next regular release.^[7]

The router example is the legal basis for reachability analysis in a software composition tool. A finding in code that is never called is a documented, non-exploitable vulnerability, provided the analysis is recorded in the risk assessment.

The Regulation does not say when an exploitable vulnerability becomes known. Commission guidance fills the gap in points 232 to 235.^[6]

A vulnerability is known when it is listed in a relevant publicly accessible vulnerability database. The guidance names the European vulnerability database established under Article 12(2) of Directive (EU) 2022/2555, and other prominent databases.^[6] Recital 66 gives the same database the job of helping manufacturers detect known exploitable vulnerabilities in their products.^[5]

A vulnerability can also be known through non-public information. The guidance lists coordinated disclosure by a security researcher, and the manufacturer's own internal testing and analysis, including AI-powered services. Public and prominent reporting in reliable media, including specialised cybersecurity publications, also makes a vulnerability known.^[6]

A report is the start of the analysis. Point 235 says a reported or found vulnerability is not, by that fact alone, exploitable or applicable to the product. The manufacturer investigates, confirms veracity and applicability, and a limited period between first report and confirmation is acceptable. The guidance puts the emphasis on prompt action.^[6]

Point (2)(a) of Part I requires products to be made available on the market without known exploitable vulnerabilities. The requirement applies on the basis of the cybersecurity risk assessment in Article 13(2) and where applicable.^[2]

Article 13(3) requires the risk assessment to state whether and how each Part I point (2) requirement applies to the product.^[3] The position on known exploitable vulnerabilities therefore belongs in the technical documentation, with the evidence behind it.

The requirement is tested at the moment of placing on the market, per Article 13(1) and guidance point 236.^[6] After that moment, the vulnerability handling requirements in Annex I Part II take over for the rest of the support period.^[2] The Commission services FAQ covers the gap between the two. A vulnerability found while a laptop sits on a shop shelf does not have to be fixed before sale. The manufacturer handles it under Part II, for example with an update when the laptop is first put into operation.^[7]

The manufacturer decides, on the basis of the risk assessment, whether the product can still be placed on the market securely or whether the fix comes first.^[6] Point 237 of the guidance lists the inputs. They are the severity, exploitability and potential impact of the vulnerability, and the risk to the product once in use.

The guidance also allows the risk of delay to count. A release that fixes other exploitable vulnerabilities, or that critical systems need to keep operating, can justify shipping before the new fix is ready.^[6] The decision is the manufacturer's, so it needs a record. A dated note that names the vulnerability, the exploitability assessment, the factors weighed and the remediation plan is the evidence a market surveillance authority would ask for.

The rule covers the whole product, components included. Article 13(5) requires due diligence when integrating third-party components, open source included, so that the components do not compromise the product's cybersecurity.^[3] Recital 77 calls it of particular importance that products do not contain vulnerable components developed by third parties.^[5]

Annex I Part II point (1) requires an SBOM covering at least the top-level dependencies, in a commonly used, machine-readable format.^[2] The SBOM is the inventory that a database match runs against, so a component missing from the SBOM is a component whose known vulnerabilities go unseen.

Article 13(6) adds an upstream duty. A manufacturer that identifies a vulnerability in an integrated component reports it to the person or entity maintaining the component. A manufacturer that develops a fix shares the code or documentation with that maintainer, where appropriate in machine-readable form.^[3]

Four records carry the position. The first is an SBOM for the released version, generated from the build. The second is a match of that SBOM against public vulnerability databases on the release date. The third is an exploitability verdict for each match, with the reason, such as code not reachable, access not available in the operational environment, or a compensating control. The fourth is a release decision for every confirmed exploitable vulnerability that ships.

A VEX document is the machine-readable form of the third record. It states per vulnerability whether the product is affected, and the justification when it is not. The CSAF justification vulnerable_code_not_in_execute_path is the router example from the Commission services FAQ in machine-readable form. CVD Portal keeps a per-product findings ledger from each SBOM scan. A user records the VEX status and justification on each finding, and the ledger exports as CSAF. The SBOM checker runs the database match for free.