Does ENISA EUVD live up to all the hype?

Last week’s announcement from ENISA resulted in a lot of hype around the launch of its European Vulnerability Database (EUVD), which officially went live on May 13, 2025.

Given the criticality of the challenges the market is responding to over the issues at MITRE, NIST and CISA relative to the overall CVE program, I decided to take a closer look and evaluate the new service.

At VulnCheck, evaluating new and existing sources of vulnerability and exploit intelligence is a routine part of my work. So, this is nothing new. Today, we collect hundreds of millions of records from over 500+ sources, and our amazing engineering team manages the collection and curation of this data to help organizations counter emerging threats.

What many readers may not realize, however, is that government-funded vulnerability advisory services and databases are not new. In addition to ENISA’s EUVD, VulnCheck has had long-standing initiatives to include Russia’s BDU, China’s CNVD & CNNVD, Japan’s JVN (including JVN iPedia), the NIST NVD in the U.S., and various national CERTs, most of which have been providing vulnerability data for years.

Why I Decided to Publish This Research So Soon

Following the funding crisis at CVE.org in April and the ongoing resource constraints at NIST's National Vulnerability Database (NVD), many organizations are actively exploring alternative sources for vulnerability information.

We’ve been fielding a lot of inquiries about this topic. With the recent launch of ENISA’s vulnerability database, a common question has emerged: Is ENISA a viable alternative to CVE.org and the NIST NVD?

This research aims to share experiences and observations to help others better understand how ENISA compares and whether it can serve as a reliable alternative for these established services. This feedback and insight is incredibly important for ENISA’s consideration, which could help them improve their service to make it a more viable alternative data source to CVE.org and NIST NVD.With the coming regulatory requirements of CRA, this database becomes a critical source for organizations doing business in the EU.

Key Findings

• EUVD is a strategically important resource aligned with the upcoming Cyber Resilience Act (CRA), making it increasingly relevant for organizations operating in the EU.
• EUVD API and website limitations present fewer vulnerabilities than CVE.org/NIST NVD, with over 50,000+ CVEs not surfaced via its main vulnerabilities API endpoint, though many are present on the website and most appear to be available through direct search/query.
• The exploited vulnerabilities listed in EUVD mirrors CISA KEV but omit some entries on their website, offering narrower visibility than sources like VulnCheck.
• The current EUVD API presents performance constraints and limited support for high-volume or automated use, which may impact operational workflows.
• Important metadata, such as CWE, CPE, and CVSS Source, is not yet available, reducing EUVD’s utility for in-depth risk analysis.
• The implementation of EPSS includes scoring modifications that introduces the possibility of misleading downstream consumers.
• Though launched as “operational,” the database is still labeled “beta,” signaling that it is an evolving platform and doesn't appear to be ready for production-level dependency.

Vulnerability Count Confusion

When analyzing a new source of vulnerability and exploitation intelligence, my first instinct is to look at raw counts. This provides a foundational comparison point with existing sources. This led to some rather confusing findings in the case of ENISA's EUVD.

Initial Observation

Two specific counts stood out to me:

• The total number of vulnerabilities.
• The total number of exploited vulnerabilities. I used two approaches to gather these numbers:
• Reviewing the raw counts on the EUVD website.
• Querying the EUVD vulnerabilities API and comparing results with CVE.org and the NIST NVD.

When querying the EUVD vulnerabilities API endpoint, I received the following response:

"total": 243,969

This immediately raised a red flag: why are over 50,000 CVEs not included in the ENISA vulnerabilities API endpoint?

Verifying Vulnerability Counts via the Website

To investigate further, I checked the EUVD website directly. Navigating to the "Full Vulnerability List" and accessing the last page (page 26,492), I found that each page displays 10 records. This gives us: 26,492 pages × 10 records = 264,920 vulnerabilities.

Still, this number is well below the total CVE count published to date.

Vulnerability Count Comparison (as of May 17)

To put things in perspective, here’s a side-by-side comparison of vulnerability counts across ENISA EUVD’s website, EUVD’s vulnerability API, NIST NVD total count, and NIST NVD total count w/o rejected :

Vulnerability Count as of May 17th

Finding the Missing Vulnerabilities

As a researcher, I naturally wanted to understand which 50,000+ CVEs were not returned from the ENISA EUVD vulnerabilities API.

To dig deeper, I compared the full set of NIST NVD’s 294,484 with the CVEs presented in the vulnerabilities API endpoint. From this comparison, I compiled a list of CVEs that were not returned from the endpoint.

While analyzing this dataset, I noticed vulnerabilities with an EPSS score greater than .1 are missing from the vulnerabilities API endpoint, which account for 20,559 of the missing vulnerabilities. For those not familiar with EPSS, higher scores have a higher likelihood that a software vulnerability will be exploited in the wild.

After a quick spot check using the ENISA EUVD website’s search interface, I confirmed that many of these CVEs were, in fact, available through the website's search function and available for direct query using the direct query vulnerability API endpoint. So the data exists, it’s just not presented in the vulnerabilities API or the website in many cases and requires you to have a complete list of CVE IDs or ENISA IDs to pull the data.

Further Exploring Exploited Vulnerability Counts

Exploring exploited vulnerabilities and discovering new data sources is one of my favorite areas of research. So, when a new resource from a reputable organization like ENISA comes online, I’m always eager to dig in and see what it adds to the ecosystem.

Unfortunately, I was disappointed to find that the ENISA EUVD Exploited Vulnerabilities list is merely a subset of CISA’s Known Exploited Vulnerabilities (KEV). That immediately raised a question: why are some CISA KEV entries not listed on EUVD’s all exploited vulnerabilities dashboard?

To investigate, I used the same methodology as with total vulnerability counts comparing raw numbers across sources.

Exploited Vulnerabilities As of May 17

I manually validated that every exploited vulnerability listed by ENISA is also present in the CISA KEV list, confirming it's a strict subset. However, this leaves 75 CISA KEV vulnerabilities unaccounted for in ENISA’s dashboard that includes “all exploited vulnerabilities”.

When I used the search functionality for these individual CVEs using the EUVD website’s search function, the results were returned, aligning with the same experience I had with vulnerability counts.

Technical Limitations of the EUVD API

Slow API Access

Downloading the currently available records from the EUVD vulnerabilities API endpoint proved time-consuming. Others I've spoken with who are also exploring the EUVD dataset have reported similar experiences, with download times exceeding multiple hours in most cases. These limitations make it challenging to automate or scale interactions with the EUVD API, given its current limitations.

To be fair, performance bottlenecks like this are not unique to vulnerability databases as anyone that’s used NIST NVD can attest to this. At VulnCheck, we experienced similar constraints before migrating to a more modern, scalable architecture as our customer base has grown. I discussed that transition and some of the architectural decisions behind it in this video.

Modified EPSS Scores in APIs

ENISA appears to have made a mistake in its implementation of EPSS scores, a common issue among projects integrating EPSS. Misunderstandings around how EPSS works often lead to inadvertent misuse or misrepresentation of the scores.

In this case, ENISA has enriched their API data with EPSS values but removed the fifth decimal place and converted the original decimal scores into percentages by multiplying them by 100, resulting in an EPSS score range between 0 and 100. It's common to present a probability as a percentage in a UI, however this conversion in the API unfortunately doesn't reflect that the score was modified. This results in a misrepresentation of the actual EPSS score itself and introduces the possibility of misleading downstream consumers.

Here are a few examples of the scoring differences:

Enrichment Data Available in Other Sources

There are a handful of important vulnerability enrichments available through NIST NVD / CVE.org that are not available in ENISA EUVD. A few of the fields I would expect to see in a vulnerability database that are not present in EUVD include:

• CWE
• CPE
• Reference Tags
• Metadata for source (CVSS Scores, Identifiers)
• Support for multiple CVSS versions on a single record.

There are also vulnerabilities without CVSS scores that are available in NIST NVD. Here is an example: https://euvd.enisa.europa.eu/vulnerability/CVE-2020-2106. Leveraging NIST NVD as a source, could help fill some of ENISA's gaps in historical data.

Several of these are current limitations of CVE.org as well.

Observations of Identifiers / Aliases

CVEs with Duplicate EUVD Identifiers

A handful of CVEs in the database contain multiple EUVD identifiers, which poses a host of challenges for consumers as it can’t be assumed that there will always be a 1-for-1 match. An Example of this is CVE-2025-25286 which has two EUVD IDs which include EUVD-2025-0100, EUVD-2025-4100. I’m curious how ENISA plans to address duplicate identifiers moving forward.

Multiple Aliases/IDs Stored into a Single String

There are several instances where EUVD stores multiple records into a single string. This makes it challenging for consumers of the API, requiring them to parse through and identify unique identifiers and the source they came from. There could also be potential collisions between sources in the future as the amount of vulnerability sources grows.

Here is an example for EUVD-2022-0047:

"aliases": "CVE-2024-13484\nGHSA-58fx-7v9q-3g56\n"

An alternative structure could include the source of the identifier:

"aliases": [
  {
    "id": "CVE-2024-13484",
    "source": "CVE"
  },
  {
    "id": "GHSA-58fx-7v9q-3g56",
    "source": "GitHub"
  }
]

Additional Questions About Data Quality / Enrichment

While conducting this research, I wanted to further evaluate the data quality. However, due to time constraints (and more critically) the challenges involved in obtaining complete and accurate data, a deeper analysis will take more time. There are many observations I made during my research that I just didn't have time to chase down and validate and would encourage others to share their own experiences.

That said, my general impression is that the EUVD currently offers less complete data, with a delivery model that makes it difficult for consumers to access and consume effectively. I’m looking forward to seeing how they improve on this in the future.

Lack of Feedback Loop for Those That Want to Help

ENISA EUVD FAQ currently states, “We do not send individual follow-ups.” This policy is disappointing, as it sends a message to consumers and researchers who want to help improve data quality with a one-way communication model with no feedback loop, which is incredibly valuable when building a new service. A more collaborative approach with the security community would significantly benefit the EUVD project and likely improve its quality and reliability.

While some may view NIST NVD and CVE.org as less than fully receptive to community input, my experience has been that they are generally responsive to researchers and users, even if there’s still plenty of room for improvement. This kind of open dialogue and engagement is important if ENISA EUVD hopes to be seen as a viable and trusted alternative.

Does ENISA Intended For People To Rely On EUVD, or Is It In Beta?

While ENISA issued a press release announcing the EUVD as “operational”, the website itself states:

This sends mixed messages to users, particularly those evaluating EUVD as a potential alternative to CVE.org or the NIST NVD. The contradiction between an “operational” status and a “beta” disclaimer creates uncertainty around the platform’s maturity and reliability.

Does ENISA EUVD Live Up To The Hype?

In its current form, the EUVD lacks the completeness, accessibility, and enrichment required by enterprise consumers and national CERTs alike. With foundational work still needed on API design, data quality, and community collaboration, ENISA faces a steep climb if it hopes to become an alternative source to more mature sources like CVE.org or NIST NVD. That said, its strategic importance for organizations doing business in the European Union is key for the success of this new tool mandated by the Cyber Resilience Act (CRA).

Special Thanks

Thanks to Josh Bressers for validating some of my experiences and findings related to ENISA EUVD.

About Vulncheck

VulnCheck is helping organizations not just to solve the vulnerability prioritization challenge - we’re working to help equip any product manager, security team and threat hunting team to get faster and more accurate intelligence with infinite efficiency using VulnCheck solutions. We knew that defenders needed better data, faster across the board, in our industry. So that’s what we deliver to the market. We deliver key insights on vulnerability management, exploitation and major trends we can extrapolate from our dataset to continuously support practitioners.

Join the VulnCheck Community today and get access to our VulnCheck NVD++ and the VulnCheck KEV in 30 seconds or less.