EUVD vs NVD vs CVE: What EU Manufacturers Need to Know

If you build, import, or distribute connected products for the EU market, the question EUVD vs NVD vs CVE is not academic — it shapes how you catalogue, track, and report vulnerabilities under the Cyber Resilience Act. From 11 September 2026, Regulation (EU) 2024/2847 requires manufacturers to report actively exploited vulnerabilities to ENISA, and the identifiers you cite matter for clarity, traceability, and coordinated disclosure. This guide untangles the three databases, explains how they connect to CRA reporting, and tells you which references to use when.

The three databases, defined

• CVE — Common Vulnerabilities and Exposures. Maintained by MITRE, CVE is the global identifier scheme. A CVE record gives a vulnerability a stable, unique ID (for example, CVE-2026-12345) and a short description. CVE is the common currency of vulnerability tracking — it is an identifier registry, not a scoring system.
• NVD — the U.S. National Vulnerability Database. Operated by NIST, NVD enriches CVE records with metadata, most notably CVSS severity scores, affected-product mappings, and references. NVD is the de facto enrichment layer for the CVE ecosystem, but it is a U.S.-governed resource.
• EUVD — the EU vulnerability database / catalogue. Maintained under ENISA, the EUVD is the regionally governed counterpart: a vulnerability catalogue increasingly relevant to EU manufacturers’ CRA reporting context. It is designed to give EU stakeholders a vulnerability reference aligned with the EU regulatory and linguistic landscape.

The short version: CVE names it, NVD scores it, EUVD localises it for the EU.

Why the distinction matters under the CRA

Article 14 reporting does not force you to choose one database, but it does reward precision. When you notify ENISA of an actively exploited vulnerability within 24 hours, citing the right identifiers helps authorities correlate your report with what other manufacturers, CSIRTs, and researchers already know. A practical submission references:

• The CVE ID for global cross-referencing.
• The NVD CVSS score where available, to communicate severity consistently.
• The EUVD entry where one exists, to anchor the report in the EU ecosystem.

Where no identifier exists yet — common for a freshly discovered, actively exploited flaw — you describe the vulnerability, its impact, and mitigations, and add identifiers as they are issued.

How the databases connect to your reporting process

The databases are inputs to a reporting workflow, not the workflow itself. A mature manufacturer process:

1. Ingests CVE, NVD enrichment, and EUVD entries into a single vulnerability view.
2. Correlates each identifier against its own products and software bill of materials (SBOM).
3. Triages actively exploited items for the 24-hour ENISA notification trigger.
4. Cites the relevant identifiers in the Article 14 submission.

This is where many teams stumble: the databases disagree on timing, enrichment, and affected-product granularity, so a human decision still determines what counts as “actively exploited” and reportable.

What to put in place now

Preparation is straightforward but easily deferred:

• Subscribe to all three feeds. CVE, NVD, and EUVD updates should land in the same triage queue.
• Map identifiers to your SBOM. Without an SBOM, you cannot tell whether a new CVE affects your products — and you cannot report accurately.
• Define the “actively exploited” signal. Decide in advance what evidence flips a vulnerability from monitored to reportable.
• Pre-draft the ENISA submission. Leave an identifier field that accepts CVE, NVD, and EUVD references.

The penalty for getting this wrong is steep: non-compliance can reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher.

Link vulnerability intelligence to product risk

Identifiers are only useful if you can act on them. A maintained risk register lets you tie each CVE, NVD, and EUVD entry to the specific products, suppliers, and assets it affects — the linkage that makes a 24-hour report accurate rather than guesswork. Reviewing the pricing for the tooling that sustains that register keeps the capability funded as a standing function, not an incident-time scramble.

The bottom line

EUVD vs NVD vs CVE is best understood as a layered system: CVE provides the global identifier, NVD adds scoring and enrichment, and EUVD gives EU manufacturers a regionally governed reference aligned with the CRA. Cite all three where they exist, wire them into a single triage and SBOM-driven process, and your Article 14 reporting becomes precise and defensible before the 11 September 2026 deadline.

For the reporting framework these identifiers feed into, read our guide to CRA Article 14 reporting requirements.