ENISA's European Vulnerability Database (EUVD), and what NIS2 Article 12 requires

The EUVD isn't a voluntary ENISA initiative — it implements a specific obligation. A Cloud Security Alliance research note on the launch states the database fulfils "a specific obligation imposed by NIS2 Article 12, paragraph 2," which directs ENISA to develop and maintain a European vulnerability database. Our broader NIS2 Directive guide independently notes, citing ENISA's own NIS2 policy page, that the directive assigns ENISA the task of "developing and maintaining a European vulnerability registry" among several other roles (secretariat for CyCLONe, an annual EU cybersecurity state report, peer-review support, and a cross-border service-provider registry) — the EUVD is that registry obligation put into production.

Per ENISA's own vulnerability-disclosure topic page, the EUVD "aggregates, stores, enriches, and publishes known vulnerabilities for public use," drawing on: advisories from EU CSIRTs and ICT vendors; an EU-maintained Known Exploited Vulnerabilities (KEV) Catalogue synchronised into the EUVD; CISA's own KEV Catalog; and unspecified "additional threat data providers." Independent reporting describes the public interface as organized around three categories — critical vulnerabilities, EU-CSIRT-coordinated vulnerabilities, and exploited vulnerabilities — spanning IT, OT and IoT products, which maps onto the device, firmware and industrial-component scope this site already tracks through the US-centric KEV/EPSS prioritization lens.

A detail easy to miss: ENISA doesn't just mirror the CVE Program's output into the EUVD — per the same SecurityWeek reporting, ENISA has itself been a CVE Numbering Authority (CNA) since 2024, meaning it can assign CVE IDs directly to vulnerabilities reported to or discovered by European CSIRTs, within whatever Scope Definition it operates under. See our CVE Numbering Authority (CNA) rules guide for how the CNA Operational Rules govern that role generally; ENISA's position doesn't replace MITRE's or any other CNA's assignments, it adds another assigner into the same shared CVE ID space.

NIS2 Article 12 does more than require a database — per the Cloud Security Alliance's research note, it also requires each member state to designate a national CSIRT as the coordinated vulnerability disclosure (CVD) coordinator, responsible for identifying and contacting affected entities, acting as an intermediary between a reporter and a vendor, negotiating disclosure timelines, and managing cases involving multiple parties. Where a reported vulnerability could affect entities across more than one member state, the note states the relevant national coordinators "are required to cooperate within the European CSIRTs Network," with ENISA itself stepping in as a coordination point for cases beyond a single state's capacity. This is a process obligation on member states, running in parallel with — not instead of — a manufacturer's own disclosure program built on ISO/IEC 29147/30111 and a published vulnerability disclosure policy.

A device maker selling into the EU already has to track the Cyber Resilience Act's own 24-hour/72-hour vulnerability reporting obligations to ENISA and national CSIRTs for actively exploited vulnerabilities and severe incidents. The EUVD and the NIS2 Article 12 CSIRT-coordinator role are a related but distinct mechanism: CRA reporting is a manufacturer's direct notification duty for its own products, while the EUVD is ENISA's public aggregation layer and the Article 12 coordinator role is about handling third-party vulnerability reports that reach a national CSIRT rather than the vendor first. Machine-readable vulnerability status published in CSAF/VEX format is one practical way a manufacturer's own advisories can feed cleanly into aggregators like the EUVD rather than requiring manual re-entry by an EU CSIRT.