Cyber Resilience Act
Vulnerability
Legal definition Art. 3(40) CRA
“a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat”
The Cyber Resilience Act (CRA) uses a deliberately broad notion of a vulnerability. It names three forms (weakness, susceptibility, flaw) and ties them to a single condition: each must be exploitable by a cyber threat.
A vulnerability is therefore more than a coding error. An insecure default configuration, an over-generous permission model, or a dependency that has long had a patched version all meet the definition.
Three levels that must be kept apart
The CRA defines not only the vulnerability but two escalations of it. Very different obligations hang on the three levels:
- A vulnerability can in principle be exploited.
- An exploitable vulnerability has the potential to be effectively used by an adversary under practical operational conditions.
- With an actively exploited vulnerability, there is reliable evidence that a malicious actor has actually exploited it in a system without permission of the system owner.
Only the third level triggers the reporting obligations. Confusing them means either reporting far too much or missing the 24-hour deadline in the one case that counts.
What the CRA requires for all vulnerabilities
Even without a reporting duty, vulnerabilities are not a purely internal matter. Annex I, Part II requires manufacturers to identify and document vulnerabilities in their products and to address them without delay, including through security updates. For that documentation, the Software Bill of Materials (SBOM) is explicitly envisaged.
That duty runs across the whole Support period. It does not end at shipping; it accompanies the product for years.
How vulnerabilities become known
In practice manufacturers learn about vulnerabilities three ways: from their own testing and code analysis, from public databases covering the components they use, and from outside reports. Those reports come from security researchers, customers and authorities.
The third route is routinely underestimated. The CRA requires manufacturers to provide a contact address for such reports and to put in place and enforce a policy on coordinated vulnerability disclosure. Without a named channel, reports end up in general support. Or they reach no one.
Vulnerability, exploit, attack
Three terms are frequently blurred. The vulnerability is a property of the product. The exploit is the technique that takes advantage of it. The attack is that technique actually applied to a specific system.
For the CRA the distinction is not academic: it decides whether you simply fix, or whether a clock is running.
Practical questions
-
No. What matters is the qualifier “that can be exploited by a cyber threat”. A rendering glitch or a wrongly rounded figure is a bug, not a vulnerability. The reverse holds as well: not every vulnerability is a coding error. An insecure default, an over-broad permission model or an outdated library all qualify.
-
No. The reporting duty does not attach to vulnerabilities as such but to the Actively exploited vulnerability. All other vulnerabilities must be identified, documented and fixed, but not reported to authorities. This distinction is the single most common misunderstanding when starting with the CRA.
-
Yes. You answer for the security of your product regardless of who wrote the affected component. The CRA goes a step further: where you have developed a fix for a component, you must share the relevant code or documentation with the person or entity manufacturing or maintaining it.
This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.