Sovereign vulnerability management means an organisation controls its own vulnerability intelligence pipeline: where data originates, which authority assigns identifiers, which formats carry advisories, and which jurisdiction governs the entire chain. Until recently, every European organisation depended on a US-controlled stack, namely the MITRE CVE programme for identifiers and the NIST National Vulnerability Database (NVD) for enrichment. The launch of the ENISA European Vulnerability Database (EUVD) in June 2025, combined with ENISA’s recognition as a CVE Program-Root and CVE Numbering Authority (CNA), changes that dependency structure in ways that regulated organisations must now translate into concrete toolchain decisions.
What the EUVD is and how it differs from NIST NVD
The EUVD is the operational implementation of Article 12 of Directive (EU) 2022/2555 (NIS-2), which mandated a European vulnerability registry coordinated by ENISA. It is not a rebrand of NVD. The two databases differ in governance, sourcing and legal grounding.
NVD is a US government product maintained by NIST under a federal programme. It enriches CVE identifiers assigned by MITRE and partner CNAs with CVSS scores, Common Platform Enumeration (CPE) data and weakness classifications. NVD has no legal mandate under EU law; its continuity depends on US federal appropriations. This became visible in practice: NIST acknowledged in 2024 that a large portion of CVEs submitted after February 2024 were left without CVSS enrichment data for months, creating a gap that security teams in Europe had no legal lever to address.
The EUVD aggregates vulnerability records from EU national CSIRTs, ENISA’s own CNA function and partner organisations, publishes them under an EU governance framework and cross-references existing CVE identifiers where they exist. Crucially, ENISA’s CVE Root status means EU CSIRTs can now assign identifiers directly, without routing every disclosure through MITRE. This creates an EU-native identifier path for vulnerabilities discovered or first disclosed within European networks.
The 2025 MITRE funding episode and what it revealed
In April 2025, it became public that the US Department of Homeland Security was not renewing MITRE’s federal contract to administer the CVE programme. A short-term extension was subsequently announced, but the episode exposed a structural fact: the identifier system underpinning global vulnerability management had a single contractual point of failure inside one jurisdiction. For European organisations operating under NIS-2, DORA or the General Data Protection Regulation, relying on that single point is an unacceptable risk concentration, not merely a theoretical one.
The episode directly accelerated ENISA’s timeline for operationalising the EUVD and asserting CVE Root status. It also shifted the conversation among CISOs in regulated sectors from “should we monitor EUVD as a supplement?” to “when do we make EUVD the primary feed and treat NVD as secondary?”
The answer for any organisation whose assets are predominantly European, whose vendors publish CSAF advisories through EU CSIRTs and whose regulators are EU bodies is: the transition should happen now, with NVD retained as a supplementary feed for US-vendor disclosures that have not yet appeared in EUVD.
Configuring a sovereign CSAF-based vulnerability toolchain
CSAF (Common Security Advisory Framework), the OASIS open standard for machine-readable security advisories, is the technical bridge between EUVD and an organisation’s internal vulnerability management platform. ENISA and major EU national CSIRTs, including BSI (Germany) and CERT-FR (France), publish CSAF documents. The framework enables automated matching of an advisory to a specific product in an organisation’s software bill of materials (SBOM), eliminating manual triage steps that introduce latency and error.
A sovereign toolchain for a regulated organisation should be structured as follows. First, the primary ingestion feed points to the EUVD API and to CSAF feeds from the national CSIRT relevant to the organisation’s sector. Second, vendor-specific CSAF documents are ingested directly from vendor portals for major software components not yet covered by EUVD. Third, NVD remains in the pipeline as a fallback for US-vendor products that publish exclusively through NIST channels. The toolchain assigns source priority explicitly: EUVD-sourced records override NVD enrichment for the same CVE identifier where both exist, because EUVD carries the EU-jurisdiction legal provenance required for NIS-2 audit trails.
This configuration is not hypothetical: it is the architecture implied by Article 12(1) of NIS-2, which requires member states to ensure that national competent authorities use the EUVD as a primary coordination point for vulnerability disclosure.
CRA Single Reporting Platform versus EUVD: two different obligations
The Cyber Resilience Act (Regulation (EU) 2024/2847) introduces the Single Reporting Platform (SRP), which becomes mandatory for actively exploited vulnerabilities from September 2026. The SRP and EUVD serve fundamentally different functions and are frequently confused.
| Dimension | EUVD | CRA Single Reporting Platform (SRP) |
|---|---|---|
| Primary purpose | Aggregation and publication of vulnerability intelligence for defenders | Mandatory regulatory notification channel for manufacturers |
| Who uses it | Security teams, CSIRTs, patch managers, auditors | Manufacturers and vendors of products with digital elements |
| Legal basis | NIS-2 Article 12 | Cyber Resilience Act Article 14 |
| Obligation type | No reporting obligation for end-user organisations; voluntary enrichment contributions | Mandatory notification within 24 hours of discovering active exploitation |
| Live from | June 2025 | September 2026 |
Sovereign software vendors, including MSPs that develop or significantly customise software for their clients, must prepare now for SRP notification workflows. A 24-hour notification window for actively exploited vulnerabilities requires pre-built escalation procedures, pre-designated contacts at ENISA, and internal triage processes that can determine active exploitation status within hours, not days.
Patch prioritisation under NIS-2 Article 21 and DORA simultaneously
NIS-2 Article 21 requires organisations to implement risk management measures proportionate to the risk, including patch management as a named component. DORA Article 13 requires financial entities to maintain an ICT vulnerability management procedure as part of the ICT risk management framework. The two obligations overlap substantially but are not identical: DORA applies only to financial entities and is more prescriptive about documentation standards, while NIS-2 applies across all critical sectors and focuses on the risk-management outcome.
A patch-prioritisation workflow that satisfies both must do three things. It must tie priority directly to asset criticality, meaning the same CVE receives a different remediation deadline depending on whether the affected system is in the production payment rail or in a development sandbox. It must produce a machine-readable record of each decision, showing which EUVD or CSAF record triggered the action, what CVSS or EPSS score was applied, what deadline was set and when the patch was deployed. And it must be auditable on demand by the competent authority: for NIS-2 this is the national supervisory authority, for DORA it is the financial supervisor.
Using EUVD as the evidentiary source for this workflow matters legally. An audit trail that references an ENISA-published advisory carries EU-jurisdiction provenance. An audit trail that references only a US NVD record creates a dependency on a foreign government database for compliance evidence, which is precisely the kind of jurisdictional exposure that NIS-2 was designed to reduce.
MSP and MSSP obligations under Implementing Regulation 2024/2690
Commission Implementing Regulation (EU) 2024/2690 specifies the technical and methodological requirements for NIS-2 Article 21 security measures. For managed service providers and MSSPs that manage infrastructure on behalf of regulated clients, the regulation creates contractual obligations that many existing service agreements do not yet reflect.
Specifically, the regulation requires that vulnerability disclosure timelines and patching SLAs be documented in contracts with essential and important entities. A sovereign MSP managing a healthcare network or a financial institution’s on-premises infrastructure must specify: the maximum time from EUVD or CSAF advisory publication to client notification; the maximum time from notification to patch deployment for critical, high and medium severity vulnerabilities; and the escalation procedure when a patch cannot be deployed within the agreed window due to system availability constraints.
Failure to meet these contractual SLAs for a critical patch can constitute a reportable incident under NIS-2 Article 23 if it creates a significant risk of service disruption. MSPs that have not yet updated their standard service terms to reflect 2024/2690 requirements are operating under contracts that will not survive regulatory scrutiny after an incident.
Statistics that contextualise the risk
The IBM Cost of a Data Breach Report 2024 recorded the average cost of a data breach at USD 4.88 million globally, the highest figure in the report’s history. Breaches that involve unpatched vulnerabilities consistently exceed the average because the exploitation window is longer and the attacker dwell time is greater. For regulated European organisations, the financial cost is compounded by NIS-2 administrative fines of up to EUR 10 million or 2% of global annual turnover, whichever is higher.
NIST’s NVD processing backlog in 2024, where thousands of CVEs lacked CVSS enrichment for months after February 2024, demonstrated that NVD is not a guaranteed service. Organisations whose patch-prioritisation workflows depended on NVD CVSS scores were effectively flying blind during that period.
ENISA’s EUVD launched in June 2025 as the operational instrument of NIS-2 Article 12, providing a legally grounded, EU-hosted alternative with initial aggregation from EU CSIRTs and ENISA’s own CNA function.
FAQ
Is the ENISA EUVD a replacement for NIST NVD, or do organisations need to use both?
EUVD is not a full replacement for NVD. EUVD has stronger coverage of vulnerabilities disclosed through EU channels; NVD remains relevant for US-vendor advisories. A mature sovereign toolchain treats EUVD as authoritative for EU-sourced records and uses NVD as a supplementary feed, not the primary source of truth.
What is the practical difference between the EUVD and the CRA Single Reporting Platform?
EUVD is a public vulnerability intelligence database for defenders. The CRA Single Reporting Platform (mandatory from September 2026) is a regulatory notification channel: manufacturers must actively report actively exploited vulnerabilities to ENISA through the SRP within 24 hours. The SRP is a legal obligation for vendors; the EUVD is a resource for everyone.
How does NIS-2 Implementing Regulation 2024/2690 affect MSP vulnerability disclosure obligations?
The regulation requires MSPs to document patching SLAs and vulnerability notification timelines in contracts with regulated clients. Failing to meet agreed critical-patch windows can constitute a reportable incident under NIS-2 Article 23. MSPs that have not updated their service terms to reflect these requirements are exposed.
What happened to the MITRE CVE programme in 2025, and why does it matter for EU organisations?
In April 2025, the US government signalled it would not renew MITRE’s contract to run the CVE programme. A short extension followed, but the episode confirmed that global vulnerability identifiers depended on a single US federal contract. This directly accelerated ENISA’s CVE Root status and the EUVD launch, and it strengthened the case for European organisations to diversify their vulnerability intelligence sourcing away from US-controlled infrastructure.
How do CSAF advisories support NIS-2 and DORA audit trails?
CSAF documents are machine-readable, carry structured product references and can be linked directly to patch tickets. By tagging every remediation action with the CSAF document URL or EUVD identifier at creation, organisations produce NIS-2 and DORA-ready audit evidence automatically, without retrospective documentation effort. ENISA and EU national CSIRTs including BSI and CERT-FR publish CSAF feeds that can be ingested by most vulnerability management platforms.