CVE

CVE stands for “Common Vulnerabilities and Exposures”. A CVE identifier is nothing more than a unique number for a publicly known vulnerability, in the format CVE-year-number, for example CVE-2021-44228 for the vulnerability that became known as Log4Shell.

Its value lies precisely in that uniqueness. Without a shared identifier, every database, tool and advisory would have to identify the same vulnerability by description. That cannot be automated.

Why CVE identifiers matter

The Cyber Resilience Act (CRA) never mentions CVE. It does require you to identify and document vulnerabilities in your products, and the identifier is the practical link that makes that work:

• The Software Bill of Materials (SBOM) lists components with versions and unique identifiers.
• Vulnerability databases map CVEs to the affected version ranges.
• Matching the two automatically produces the list of possible hits.

Without CVEs, all that would be left of this process is reading advisories by hand.

How an identifier comes about

The path from discovery to a published CVE follows fixed steps:

1. Security researchers, a customer or an internal team report a vulnerability.
2. A responsible numbering authority reserves an identifier. From that moment the number exists, but no public description does.
3. Manufacturer and reporter coordinate the fix. The identifier stays reserved so that everyone involved can already refer to the same number.
4. On publication the record is filled in with affected versions, description and references.

This is why you occasionally meet a CVE number with no content: it is reserved but not yet published. Records can also be marked as rejected or disputed. Disputed applies when manufacturer and reporter disagree on the assessment.

For you as a manufacturer this means reserving an identifier early is not an admission but good practice. It creates a shared name before the fix is finished.

Where the data lives and what Europe adds

The CVE list itself only carries the basics. Practical work relies on enriched sources that additionally hold scores, affected version ranges and links to advisories.

One source is particularly relevant for European manufacturers: the EU Agency for Cybersecurity, ENISA, has operated the European Vulnerability Database (EUVD) since April 2025. It stems from Article 12 of the NIS2 Directive, is freely accessible, and carries information on mitigations and current exploitation status alongside the vulnerability data.

That last point matters directly under the CRA: whether a vulnerability is already being exploited decides whether you are facing an Actively exploited vulnerability, and therefore whether the 24-hour clock is running.

What a CVE is not

Not a rating. The identifier says nothing about severity or exploitability. That is what CVSS is for. It is a separate system, usually supplied alongside but frequently confused with the identifier itself.

Not proof that you are affected. A component being in your product and having a CVE does not mean your product is vulnerable. The vulnerable function may sit in a version you do not use, or in a code path your product never reaches.

Not complete coverage. Far from every vulnerability receives a CVE. Defects found internally and fixed quietly never appear there. Basing vulnerability management on CVE matching alone means seeing only the publicly documented part.

How this plays out in practice

Matching your bill of materials against a database first produces a list of possible hits. Only assessing each hit turns that into a defensible statement: is the affected version really in use, is the vulnerable code path reachable, are there mitigating factors in the configuration?

That assessment is where the actual effort sits. It is also the reason a raw scanner report is not yet a vulnerability analysis.