On 11 September 2026, the reporting obligations of the Cyber Resilience Act enter into force for manufacturers of products with digital elements. Most security teams have prepared for this deadline. Fewer have integrated into their processes the European vulnerability database, the EUVD, which ENISA has operated since May 2025. The two schemes coexist, serve different purposes and together create a blind spot in patch management processes that have not been updated.
The EUVD is not a European NVD
The European Union Vulnerability Database was launched in April 2025 and has been operational since May 2025. It is mandated by Article 12 of the NIS2 Directive, which tasks ENISA with building a centralised database, fed by national CSIRTs that are members, vendors and partner databases. It publishes its own identifiers (EUVD-AAAA-XXXXX) in addition to CVEs, and has a publicly documented API.
The comparison with the US NVD ends there. The EUVD does not replace the CVE programme run by MITRE: it is a downstream reference. ENISA became a CVE Program Root in 2026, which allows it to assign CVE IDs directly for vulnerabilities reported by member CSIRTs. But the EUVD also publishes its own exploitation metadata specific to the European scope. In practical terms, a vulnerability actively exploited in Germany by an APT group targeting the energy sector may receive an active threat indicator in the EUVD several hours before the NVD updates its entry.
Two distinct tools, a frequent confusion
The Cyber Resilience Act provides for a single reporting platform, the Single Reporting Platform (SRP), operated by ENISA. It is through the SRP that manufacturers notify an actively exploited vulnerability within 24 hours of discovering it. The SRP is the regulatory notification tool. The EUVD is the tool for consulting and referencing known vulnerabilities.
These two tools coexist without replacing each other. Consulting the SRP does not replace querying the EUVD. Notifying via the SRP does not guarantee that your patch management process is aligned with EUVD data. In practice, many teams still operate with an NVD feed as their main source for vulnerability monitoring, possibly supplemented by the MITRE CVE feed, and have not configured any query of the EUVD API in their SIEM or asset management tools. The article on the Cyber Resilience Act notification obligations details the mechanics of the SRP and the applicable deadlines.
What the EUVD offers that the NVD does not
Three operational differences deserve attention.
First, local exploitation data. The EUVD aggregates reports from the CSIRTs of the 27 Member States and produces an exploitation status indicator (not exploited, known exploitation, active exploitation) that reflects the reality on the European ground. For a vendor whose customers are mostly European, this granularity changes patch priorities.
Second, EUVD identifiers. Some vulnerabilities receive an EUVD identifier before the corresponding CVE is published or finalised, particularly for flaws reported by member CSIRTs in software poorly covered by US CNAs. Ignoring this feed means relying on incomplete coverage for software products used mainly in Europe.
Third, alignment with NIS2. Article 12 of NIS2 requires essential and important entities to report vulnerabilities affecting their systems through the competent CSIRTs. The EUVD is the reference that these CSIRTs feed and consult. Not being operationally connected to it means handling incidents outside the reference that your supervisory authority will use during an audit.
A concrete example: the signal gap
In July 2026, a flaw in a session management component of an open source library widely used in web applications was reported by CERT-FR to France's national cybersecurity agency (ANSSI), then passed to the EUVD with an "active exploitation" indicator. The vulnerability had received its CVE identifier two days earlier, but the NVD had not yet incorporated the full attack vector. Teams that consulted only the NVD prioritised other fixes for 48 hours, during which part of their production customers remained exposed.
This gap is not exceptional. It illustrates a structural principle: the EUVD is fed by a network of CSIRTs that observe attacks in real time across European territory. The NVD is fed by vendors and researchers, through a validation process that mechanically introduces a delay.
Three adjustments to make now
Set up an automatic query of the EUVD API. The EUVD offers a documented REST API at euvd.enisa.europa.eu. It can be queried on the basis of a list of components (CPE, PURL, CVE) and returns the exploitation status along with the associated metadata. If your patch management tool or SIEM supports custom feeds, the integration generally requires no more than one day of development.
Differentiate the feeds in your prioritisation policy. Your prioritisation rules probably distinguish critical CVSS scores from the rest. Add a criterion, "active exploitation reported in the EUVD", as an escalation factor, independently of the CVSS score. According to a 2025 ENISA study, 34% of vulnerabilities actively exploited within the European scope have a CVSS score below 7.0: the score alone is not enough to trigger maximum priority.
Document EUVD coverage in your NIS2 compliance register. During a NIS2 audit, the question of vulnerability management will cover your monitoring sources and your ability to demonstrate a response proportionate to the actual exploitation status. A dashboard that cross-references EUVD data with your SBOM inventory is a solid answer to this requirement.
A window of seventeen days
On 11 September 2026, the CRA notification obligations enter into force. Manufacturers that have not yet completed their reporting process via the SRP have seventeen days to do so. Those that do not yet consult the EUVD in their monitoring feed have the same window to set up the integration. These two projects are distinct but complementary: the first meets a reporting obligation, the second a monitoring and responsiveness obligation.
ENISA has reported, in its statistics for the first half of 2026, more than 14,000 vulnerability records in the EUVD since its launch. The pace is accelerating. Waiting for the NVD to systematically relay this data with the same level of detail amounts to accepting a structural latency in your risk management, precisely at the moment when supervisory authorities have a reference that does not suffer from this delay.
