Vulnerability programmes that rely on a single upstream database inherit its delays and its gaps, and the EU now runs its own public source that European organisations are expected to know. The EU Vulnerability Database (EUVD), operated by ENISA under the NIS2 Directive and live since 13 May 2025, aggregates CVE records, vendor advisories, national CSIRT alerts and exploitation status into one service with its own identifiers, dashboards and a public API. This guide explains what the EUVD contains, how EUVD identifiers relate to CVE IDs, how to read its exploited and critical views, how to pull it into a vulnerability pipeline, and how it connects to NIS2 and Cyber Resilience Act (CRA) obligations. It is for vulnerability management teams, product security (PSIRT) teams and compliance leads in EU-regulated organisations. The CVE and NVD side of the story is covered in the CVE Programme and NVD Backlog Guide.
Key takeaways
- The EUVD is an aggregator with a legal basis. ENISA built it as provided for by the NIS2 Directive (Article 12(2), as the CRA's recitals cite it), and it pulls in CVE data, vendor advisories, CSIRT alerts and CISA's exploitation catalogue.
- EUVD IDs sit beside CVE IDs, not instead of them. Each record has an EUVD-year-number identifier and lists its CVE and other aliases, so you can join it to existing CVE-keyed data.
- Three views matter operationally. The critical, exploited and EU coordinated dashboards give a fast triage list, with the exploited view carrying an exploitedSince date.
- The API is open and simple. Public JSON endpoints return records with CVSS score, version and vector, EPSS, aliases, vendor and references, which suits automated enrichment.
- CRA makes it more relevant over time. The CRA's recitals expect ENISA to publish fixed vulnerabilities reported under the regulation in the EUVD, and suggest manufacturers check components against it.
What it is and who it applies to
ENISA describes the EUVD as providing aggregated, actionable information on vulnerabilities affecting ICT products and services, such as mitigation measures and exploitation status. It is a public service, free to read, and nothing obliges a private organisation to consult it. Its importance comes from three directions.
| Audience | Why the EUVD matters | Practical link |
|---|---|---|
| NIS2 essential and important entities | NIS2 asks entities to handle vulnerabilities and disclosure as part of their risk management measures; the EUVD is the EU's own reference source | Add it to your vulnerability intelligence sources and record that you monitor it. See the NIS2 Directive Guide. |
| Manufacturers under the CRA | CRA recital 34 lists checking that third-party components are free from vulnerabilities registered in the EUVD as one due diligence option; recital 66 expects ENISA to publish fixed, reported vulnerabilities there with the manufacturer's agreement | Wire EUVD lookups into component (SBOM) checks and PSIRT triage. See the EU Cyber Resilience Act Vulnerability and Incident Reporting Guide. |
| CSIRTs and suppliers | NIS2 recital 62 allows any entity, in or out of NIS2 scope, plus suppliers, competent authorities and CSIRTs, to register publicly known vulnerabilities voluntarily | Coordinated disclosure through national CSIRTs can surface first in the EU coordinated view |
| Everyone else running a vulnerability programme | A second, independent aggregation reduces dependence on one upstream database | Use it as an enrichment and cross-check source |
Two related roles explain where EUVD data comes from. Since January 2024 ENISA has been a CVE Numbering Authority (CNA) for vulnerabilities found by, or reported to, EU CSIRTs where no other CNA has scope. Since November 2025 it has also been a CVE Program Root for European entities: by ENISA's 6 August 2026 announcement, 20 CNAs sat under the ENISA Root, 12 onboarded directly and 8 transferred from the MITRE Root. More European CNAs means more CVE records whose assigner is European, and those flow into the EUVD alongside everything else.
Structure and key requirements
Data sources
ENISA lists the inputs as open-source vulnerability databases interconnected through the open-source Vulnerability-Lookup software, advisories and alerts from national CSIRTs, vendor mitigation and patching guidance, CVE data and vendor advisories, and CISA's Known Exploited Vulnerabilities catalogue, which is transferred automatically. In practice the EUVD is an aggregation and normalisation layer: it rarely holds a fact that exists nowhere else, but it gathers facts that otherwise sit in many places and adds EU CSIRT coordination status.
Identifiers
Every record carries an identifier in the form EUVD-<year>-<number> (for example, records from 2026 begin EUVD-2026-) and an ENISA UUID. The aliases field lists other identifiers for the same issue, typically the CVE ID and, for open-source packages, a GitHub Security Advisory (GHSA) ID. Keep CVE as your primary join key where one exists and store the EUVD ID as an additional alias; use the EUVD ID as the key only where no CVE has been assigned.
Record fields
| Field (API name) | What it holds | How to use it |
|---|---|---|
id, enisaUuid | EUVD identifier and ENISA UUID | Store as aliases on your finding record |
aliases | CVE, GHSA and other IDs, newline-separated | Split and join to scanner and SBOM data |
baseScore, baseScoreVersion, baseScoreVector | CVSS base score, version (for example 3.1 or 4.0) and vector string | Always store the version with the score; do not compare v3.1 and v4.0 scores directly. See the CVSS v4 Guide. |
epss | Exploit Prediction Scoring System value | Use as a likelihood signal alongside exploitation status. See the EPSS Guide. |
exploitedSince | When exploitation was observed (exploited records) | Drive SLA clocks for exploited issues |
assigner | Organisation that assigned the CVE | Spot European CNA records and vendor self-assignments |
enisaIdVendor | Vendor objects linked to the record (may be empty) | Match to your supplier inventory; fall back to aliases when empty |
references, datePublished, dateUpdated | Source URLs and timestamps | Follow the vendor advisory for the fix; re-pull on update |
Dashboards and API
The web interface at euvd.enisa.europa.eu presents three dashboards: critical vulnerabilities, exploited vulnerabilities, and EU coordinated vulnerabilities (those coordinated by European CSIRTs, including members of the EU CSIRTs network). The same data is available as JSON from euvdservices.enisa.europa.eu without registration. Endpoints observed in November 2026 include /api/exploitedvulnerabilities and /api/criticalvulnerabilities (short lists of recent records) and /api/search, which accepts filters such as score range and page size and returns an items array with a total count. ENISA has not published a formal service level for the API, so treat field names and limits as subject to change and validate responses in code.
Choosing how deeply to integrate
Small organisations: a weekly review of the exploited and EU coordinated dashboards against your software list is a reasonable start and needs no engineering. Mid-sized teams with a vulnerability platform: a daily API pull joined on CVE alias gives most of the value. Large estates and manufacturers: full enrichment, SBOM matching and source comparison justify the build, because the EUVD then feeds release decisions and regulatory evidence. Whichever level you pick, keep at least one other exploitation source so a gap in one service does not leave you blind.
Identity and NHI requirements
The EUVD sets no identity requirements of its own: reading it needs no account. Identity enters in three places.
- Vulnerabilities in identity infrastructure: identity providers, PAM vaults, secrets managers, directory services and federation gateways are high-value products. Build a saved EUVD search, or an API filter on vendor and alias, for every identity product in your estate, and give those findings the shortest SLA. See the Privileged Access Management Guide.
- The automation that pulls the feed: the job that queries the EUVD and writes into your vulnerability platform or ticketing system is a non-human identity. Give it its own service account, store its downstream credentials (ticketing and platform API keys) in a secrets manager, and log its writes. See the Service Account Security Guide.
- Feed integrity: fetch only over HTTPS from the official hosts, pin the hostnames in egress rules, and reject records that fail schema validation, so a spoofed or malformed feed cannot open or close tickets at scale.
Implementation steps
- Decide the role of the EUVD. For most organisations it is an enrichment and cross-check source beside CVE, the NVD, vendor advisories and the CISA catalogue. For EU product manufacturers it is also an input to CRA component due diligence. Write this down in your vulnerability management standard.
- Map identifiers. Add an alias table to your vulnerability data model so a finding can hold CVE, EUVD and GHSA IDs together. Backfill EUVD IDs for open findings by querying on CVE alias.
- Pull the exploited view first. Schedule a daily job against the exploited endpoint, join on CVE alias to your scanner findings, and raise priority where an asset you own is affected. Compare against your existing exploitation sources and record which source flagged each issue first.
- Add search-based enrichment. For each new finding, query the EUVD for EPSS, CVSS version and vector, vendor and references. Store the source of each field so analysts can see where a score came from.
- Track EU coordinated issues. Review the EU coordinated dashboard weekly for products you use; these often relate to European suppliers where CSIRT coordination is under way.
- Connect to PSIRT and SBOM (manufacturers). Check component lists against EUVD records during release gates and periodically for shipped products, and route matches into the same triage that handles CRA reportable vulnerabilities.
- Test and roll back. Run the enrichment in shadow mode for two weeks, compare priorities with and without EUVD data, then switch it on. If the API changes or fails, the pipeline should fall back to your other sources without blocking ticket creation.
Evidence and assessment
No auditor certifies EUVD use, but NIS2 supervisors, CRA market surveillance authorities and customers will ask how you learn about vulnerabilities. Keep evidence that shows the EUVD is part of a working process.
| Evidence | What it shows | Metric to report |
|---|---|---|
| Vulnerability management standard naming the EUVD as a source | Intent and scope | Date last reviewed |
| Job logs for the EUVD pull | The feed runs and is monitored | Successful daily pulls in the last 30 days |
| Findings carrying EUVD aliases | Data is joined, not just downloaded | Share of open findings with an EUVD ID |
| Tickets prioritised from the exploited view | The feed changes decisions | Median time from exploitedSince to remediation on owned assets |
| Release gate records (manufacturers) | CRA component due diligence | Releases checked against the EUVD before shipping |
| Source comparison log | Value of multiple sources | Issues first flagged by the EUVD versus other sources |
Mapping to other frameworks
| Framework | Where EUVD use fits |
|---|---|
| NIS2 Directive (EU) 2022/2555 | Article 12(2) is the basis for the database; vulnerability handling and disclosure sit within the Article 21 risk management measures |
| Cyber Resilience Act (EU) 2024/2847 | Recitals 34, 66 and 73 tie component due diligence, publication of fixed vulnerabilities and the single reporting platform to the EUVD |
| NIST CSF 2.0 | ID.RA-02 (cyber threat intelligence is received from information sharing forums and sources) and ID.RA-01 (vulnerabilities identified, validated and recorded) |
| NIST SP 800-53 Rev 5 | RA-5 Vulnerability Monitoring and Scanning; SI-5 Security Alerts, Advisories, and Directives |
| ISO/IEC 27001:2022 Annex A | A.8.8 Management of technical vulnerabilities; A.5.7 Threat intelligence |
| CIS Controls v8.1 | Control 7 Continuous Vulnerability Management. See the CIS Control 7 Continuous Vulnerability Management Guide. |
Common pitfalls
- Treating the EUVD as a replacement for CVE: it aggregates CVE and other data and uses CVE as an alias. Keep CVE as the primary key and the EUVD as an additional source.
- Mixing CVSS versions: records may carry CVSS 3.1 or 4.0 scores. Store the version and vector; do not sort a mixed list by base score alone.
- Double-counting exploitation: the EUVD already imports CISA's exploitation catalogue, so an issue flagged by both is one signal, not two independent ones.
- Relying on the vendor field:
enisaIdVendorcan be empty. Match on CVE alias and product data from your scanner or SBOM as well. - Hard-coding the API: field formats (for example newline-separated aliases and text timestamps) are not under a published contract. Parse defensively and alert on schema changes.
- Assuming CRA reporting goes through the EUVD: CRA notifications go to the single reporting platform; the EUVD is where fixed vulnerabilities may later be published. Keep the two processes distinct.
Practitioner checklist
- Name the EUVD in your vulnerability management standard as an enrichment and exploitation source.
- Add EUVD and GHSA aliases to your vulnerability data model, keyed to CVE where one exists.
- Schedule a daily pull of the exploited endpoint and join it to scanner findings on owned assets.
- Store CVSS version and vector with every score taken from the EUVD.
- Create saved searches or API filters for every identity, PAM and secrets product you run.
- Run the feed job under a dedicated service account with vaulted downstream credentials and schema validation.
- Manufacturers: check component lists against the EUVD at release gates and route matches to PSIRT triage.
- Report monthly on feed health, alias coverage and time to remediate exploited issues.
Standards and references
- ENISA: EU Vulnerability Database (EUVD)
- ENISA: Consult the European Vulnerability Database to enhance your digital security
- ENISA: ENISA scales up its role in the CVE Program
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- ENISA: EUVD API, exploited vulnerabilities endpoint
Related NHI Mgmt Group resources: CVE Programme and NVD Backlog Guide · EU Cyber Resilience Act Vulnerability and Incident Reporting Guide · Risk-Based Vulnerability Management Guide · NIS2 Directive Guide. This guide summarises the EU Vulnerability Database and related EU law and is not legal advice.