Sovereign Vulnerability Management with EUVD: A NIS-2 Guide

Sovereign vulnerability management is the practice of identifying, prioritising and remediating security flaws in an organisation’s technology stack using intelligence sources, tooling and update channels that remain under the legal control of the organisation and its jurisdiction, rather than those of a foreign government or corporation. For European public sector bodies and regulated entities, this discipline has moved from best practice to legal obligation, driven by three converging instruments: the NIS-2 Directive, the Cyber Resilience Act (CRA) and the operational maturity expected by DORA. At the centre of this shift sits a new European institution: the ENISA European Vulnerability Database (EUVD).

What the EUVD Is and How It Differs from MITRE CVE

The ENISA European Vulnerability Database, launched in January 2024, is the EU’s authoritative vulnerability intelligence repository, mandated under the NIS-2 Directive and operated by the European Union Agency for Cybersecurity. It is not simply a mirror of MITRE’s CVE programme.

The MITRE CVE programme, funded by the US Department of Homeland Security through CISA, assigns identifiers to publicly known vulnerabilities and relies on a global network of CVE Numbering Authorities (CNAs). It is the de facto global standard, but it operates under US law and US federal contract. Any organisation whose vulnerability management process depends exclusively on CVE data is, by extension, dependent on a US-government-funded system that could in principle be restructured, delayed or restricted by US policy decisions.

The EUVD differs in three material ways. First, it aggregates not only CVE-sourced data but also bulletins from EU national CSIRTs, CERT-EU advisories and vendor disclosures submitted through European channels, producing a richer contextual picture for European infrastructure. Second, it carries explicit legal standing: NIS-2 Article 21 and the implementing guidelines reference ENISA’s role in coordinating vulnerability information, and the EUVD is the operational vehicle for that role. Third, it is jurisdictionally clean: it operates under EU institutional law, meaning access to and management of the data does not create the foreign-jurisdiction exposure that arises when a European organisation’s entire security posture runs through MITRE or NIST NVD.

CRA Article 14 and the September 2026 Reporting Deadline

The Cyber Resilience Act, published as Regulation (EU) 2024/2847, introduces the most operationally demanding vulnerability reporting obligation European organisations have faced. Article 14 requires that manufacturers of products with digital elements report an actively exploited vulnerability to the CRA Single Reporting Platform (SRP) within 24 hours of becoming aware of it.

This deadline applies from September 2026, giving organisations approximately two years from the CRA’s publication to build compliant processes. The SRP, operated under ENISA’s coordination, feeds directly into the EUVD, creating a closed European loop: a vulnerability discovered in sovereign software must be disclosed through the SRP, which then enriches the EUVD, which national CSIRTs and other covered entities consume to update their own remediation priorities.

For sovereign software vendors, this means several concrete process changes are required before September 2026. Vendors must maintain a software bill of materials (SBOM) accurate enough to identify which of their products are affected by a newly discovered flaw. They must have an internal triage process capable of making an “actively exploited” determination within hours, not days. And they must have a registered relationship with the SRP so that submission is not the first contact they have with the system during an incident.

For sovereign infrastructure deployers, the CRA obligation is indirect but consequential. When a software component in a sovereign stack is reported via the SRP, the EUVD entry will typically carry a flag indicating active exploitation. Organisations consuming EUVD feeds will see that flag and must respond under their NIS-2 Article 21 remediation timelines, not at their convenience.

“NIS-2 is not a checkbox exercise. Article 21 requires entities to demonstrate continuous, evidence-based risk management, and vulnerability handling is explicitly part of that obligation.” (ENISA, NIS-2 implementation guidance)

Designing a Sovereign Patch Pipeline Without US Update Channels

The dependency on US-controlled update infrastructure is an underappreciated jurisdictional access vector. Microsoft Windows Update, AWS Systems Manager Patch Manager and Google Cloud’s OS Config service all route update metadata and telemetry through infrastructure subject to the US CLOUD Act and FISA Section 702. Even if the payload (the patch itself) is cryptographically verified, the update management plane, which determines what gets patched, when and with what priority, operates under US legal authority.

This matters because a compelled disclosure or a covert legal process served on the vendor could, in principle, manipulate update scheduling, suppress a patch or expose patch-status telemetry about a target organisation’s infrastructure. For a defence ministry, a national health authority or a systemically important financial institution, this is not a theoretical risk.

A fully sovereign patch pipeline has four components that must each be sourced appropriately:

The ENISA Coordinated Vulnerability Disclosure (CVD) policy provides the governance framework for how organisations receive and act on externally reported flaws. Adopting a published CVD policy is explicitly referenced in the NIS-2 implementing guidelines and signals to both regulators and researchers that the organisation has a structured, predictable response process.

NIS-2 Article 21 and DORA ICT Risk Obligations: What Must Be Provable

NIS-2 Article 21 requires covered entities to implement technical and organisational measures covering, among other areas, vulnerability handling and disclosure. The ENISA technical guidelines (reference 2024/2690) translate this into operational expectations: continuous vulnerability scanning of exposed assets, defined remediation timelines based on severity (critical vulnerabilities within 72 hours for actively exploited flaws is the benchmark referenced in guidance), and documented evidence that patches were applied.

DORA, applicable to financial entities from January 2025, adds a parallel ICT risk management framework requiring institutions to maintain an asset register, test their systems against known vulnerability signatures, and demonstrate to competent authorities that ICT risks are identified and addressed in a documented, repeatable way.

The Verizon 2024 Data Breach Investigations Report found that exploitation of vulnerabilities as an initial access vector grew 180% year-on-year, accounting for 14% of all breaches analysed (Verizon DBIR 2024). Separately, Mandiant’s M-Trends 2024 Report documented that the median time between public vulnerability disclosure and active exploitation in the wild fell to five days in 2023, down from 32 days in 2021 (Mandiant 2024).

These figures are not decorative. They define the operational tempo that NIS-2 and DORA remediation timelines must match. A 30-day patch cycle, common in many organisations, is now empirically inadequate for critical-severity flaws with public proof-of-concept code.

Audit Artefacts a CISO Must Present to Regulators

ENISA’s technical guideline 2024/2690 implicitly defines what “evidence” means in the context of vulnerability management. A CISO presenting to a national supervisory authority or a DORA competent authority should prepare the following artefacts:

Asset and SBOM inventory: A current, machine-readable software bill of materials for all production systems, demonstrating that the organisation knows what software it is running and can query it against EUVD entries programmatically.

Scan cadence logs: Timestamped output from an authenticated vulnerability scanner (such as Greenbone Vulnerability Manager or OpenSCAP) showing that scanning occurs at defined intervals and that newly discovered EUVD entries trigger out-of-cycle scans for affected assets.

Remediation tickets with closure timestamps: A traceable record linking each EUVD identifier (or CVE where applicable) to a change management ticket, showing the date the vulnerability was identified, the severity assigned, the target remediation date, and the actual patch date. Gaps between target and actual date must be explainable with a documented risk acceptance or compensating control.

CSIRT notification records: Where the organisation operates critical infrastructure, evidence that relevant national CSIRT advisories were received, reviewed and acted upon, demonstrating the sovereign intelligence pipeline was active rather than passive.

CVD policy publication and intake log: A published CVD policy accessible to external researchers, with a log of any reports received, their triage outcomes and resolution timelines. This satisfies both the NIS-2 implementing guidelines and the pre-conditions for CRA Article 14 readiness.

“The European Vulnerability Database is a cornerstone of a more autonomous European cybersecurity ecosystem, reducing dependency on non-EU vulnerability intelligence sources.” (Juhan Lepassaar, Executive Director, ENISA)

Together, these artefacts shift vulnerability management from a process claim to a verifiable operational record. Regulators conducting NIS-2 or DORA inspections are increasingly asking not whether an organisation has a vulnerability management policy, but whether it can demonstrate, with timestamped evidence, that the policy was executed for every material flaw in the preceding audit period.

Frequently Asked Questions

Is the EUVD a replacement for the MITRE CVE programme?

No. The EUVD aggregates CVE data alongside other sources such as CSIRT advisories and vendor bulletins, but it is an independent European layer rather than a direct replacement. Its legal significance is that it is operated under EU jurisdiction and carries explicit obligations under NIS-2 and the CRA, whereas MITRE operates under US federal contract.

When does the CRA Article 14 active-exploit reporting deadline take effect?

The Cyber Resilience Act was published in October 2024. The Article 14 obligations, requiring manufacturers to report actively exploited vulnerabilities to the CRA Single Reporting Platform within 24 hours of discovery, apply from September 2026, giving organisations roughly two years to build compliant processes.

Does using open-source software such as Nextcloud exempt an organisation from vulnerability management obligations?

No. NIS-2 Article 21 applies to the entity operating the service, regardless of the underlying software licence. Open-source components must be tracked, scanned and patched with the same rigour as proprietary software. The EUVD indexes vulnerabilities in open-source packages alongside commercial products.

What is the difference between a CVD policy and a bug bounty programme?

A coordinated vulnerability disclosure policy, as defined by ENISA’s CVD guidance, is a structured process for receiving, validating and remediating reports from external researchers, with agreed timelines and communication norms. A bug bounty adds financial incentives. NIS-2 and the CRA reference CVD policies specifically; a bug bounty alone does not satisfy that obligation.

How does Swiss hosting reduce jurisdictional exposure in the update supply chain?

Swiss hosting under the revised Federal Act on Data Protection removes data from the reach of the US CLOUD Act and FISA 702 because Swiss law does not permit unilateral foreign government access without Swiss legal process. However, if the underlying software update mechanism routes through US-controlled infrastructure, the update traffic itself may carry jurisdictional risk regardless of where the data is hosted. Both the data layer and the update management layer must be addressed.