Exploitable vulnerability

An exploitable vulnerability is defined in Article 3, point (41) of the Cyber Resilience Act (CRA) as a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions. It sits at the middle of three levels. Below it is the plain vulnerability, above it the actively exploited vulnerability.

Two qualifiers carry the definition, and both are meant literally. The first concerns the actor. Someone has to turn the vulnerability against the product; a malfunction that simply occurs in ordinary use is not enough. The second is the standard of practical operational conditions. The question is not whether exploitation is conceivable but whether it works in the field.

Both language versions of the Regulation are equally binding, and they place the emphasis differently. The English speaks of an adversary; the German of an unbefugter Dritter, an unauthorised third party. For an insider misusing legitimate credentials the two formulations do not necessarily land in the same place. The CRA does not resolve that.

What practical operational conditions mean

The CRA does not elaborate on the phrase. Three questions do follow from the wording, and together they carry a classification:

• Does exploitation work in the configuration the product ships with, or only in a purpose-built lab setup?
• Does an outsider have the access it presupposes, over the network, through an interface, or by physical proximity?
• Does it produce a real effect, or does it stop at a further layer of protection?

If any of those answers comes out negative, the finding remains a vulnerability. Exploitable in the sense of the Regulation it is not. That classification is the manufacturer’s call, and it does not stay informal. Under Article 13(3) the cybersecurity risk assessment has to state whether and how the requirements in Annex I, Part I, point 2 apply to the product.

The single place where the phrase carries legal weight

Outside the definition, the Regulation uses it in a binding provision exactly once. Annex I, Part I, point 2(a) requires products to be made available on the market without known exploitable vulnerabilities. Every other occurrence sits in recitals, which do not bind: 54, 66 and 76 in the English version, and recital 9 as well in the German, which has ausnutzbare Schwachstellen where the English speaks of vulnerability exploits.

Three details hang on that one requirement:

• It covers known vulnerabilities only. An undiscovered flaw does not breach it.
• It bites on the basis of the cybersecurity risk assessment under Article 13(2), and only where it is applicable. Where a manufacturer treats it as inapplicable, Article 13(4) demands a clear justification in the technical documentation.
• It attaches to making available on the market, not to the first placing on the market.

The third point is routinely missed. Making available is the supply of a product for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge. The requirement is therefore not a gate you pass once at launch but a condition that has to hold again at every further delivery.

Nothing to report at this level

Article 14 attaches the vulnerability reporting duty exclusively to the actively exploited vulnerability. An early warning within 24 hours, a vulnerability notification within 72 hours, a final report no later than 14 days after a corrective or mitigating measure is available. The second trigger in the same article is a severe incident. For mere exploitability the Regulation provides none of that, not even where a public proof of concept is circulating.

What does apply is Annex I, Part II. Vulnerabilities and components have to be identified and documented, including through a software bill of materials, and addressed and remediated without delay in relation to the risks posed to the product. That duty covers every vulnerability. Exploitability therefore does not decide whether you act, only how urgently.

The classification still has outward effect, and it travels through the supply chain. As soon as an importer or a distributor learns of a vulnerability in the product, it must inform the manufacturer without delay. Where the product presents a significant cybersecurity risk, the details also go to the market surveillance authorities of the Member States in which the product was made available, under Article 19(5) for importers and Article 20(4) for distributors. The manufacturer owes no notification at this level; its channel partners may well owe one.

Why a CVSS score does not answer the question

A CVSS base score describes a vulnerability in the abstract, detached from the product it sits in. The CRA asks something else, namely how effective it is under your operating conditions. A library carrying a base score of 9.8 may be unreachable in your product, while a medium-scored flaw may be the direct way in.

For the reasoned counter-statement, the “present but not exploitable”, an established format exists: VEX. It records per product and version that a component is affected while the product is not, with the justification attached. The assessment itself belongs in the cybersecurity risk assessment and therefore, under Article 13(4), in the technical documentation.

Where the word known comes from

Known is not limited to whatever happened to catch someone’s eye. Article 13(5) requires due diligence when integrating third-party components. Recital 34 names, among the means of exercising it, checking whether a component is free from vulnerabilities registered in the European vulnerability database or in other publicly accessible vulnerability databases. Annex I, Part II, point 3 adds the duty to apply effective and regular tests and reviews of the security of the product.

Not looking therefore does not breach Annex I, Part I, point 2(a), but it does breach the due diligence duty in Article 13(5). Article 13(7) further requires every vulnerability the manufacturer becomes aware of to be documented systematically.