The EU Vulnerability Database and NIS2 Disclosure: An MSP Guide

In May 2025, ENISA quietly switched on the European Vulnerability Database. By September 2026, feeding it stops being optional for a large group of vendors. If your clients build, resell, or integrate ICT products, that deadline is now on your roadmap — whether they know it or not.

Most NIS2 conversations still revolve around risk registers and incident reporting. The coordinated vulnerability disclosure machinery sitting underneath Article 12 gets ignored. That's a mistake. It's the part of NIS2 that quietly reshapes how your clients find out about flaws in the products they run, and how their own products get reported when something breaks.

This is a practical walkthrough for consultants, MSPs, and vCISOs: what the EUVD is, what the September 2026 reporting obligation actually requires, and how to operationalise coordinated vulnerability disclosure for clients who have never thought about it.

The EUVD is the EU's answer to a single point of failure

For two decades, the world's vulnerability tracking ran through one US-funded program: the CVE system. In early 2025, that funding wobbled. The CVE program came within days of a lapse before a last-minute extension. Europe noticed.

ENISA's European Vulnerability Database — the EUVD — is the structural response. It launched in May 2025 as a mandate of NIS2 Article 12. It is not a replacement for CVE; it ingests CVE records, vendor advisories, and CISA's Known Exploited Vulnerabilities catalogue, then layers EU-specific context on top.

The practical output is three dashboard views your clients can use today, for free:

• Critical vulnerabilities — flaws with severe impact.
• Exploited vulnerabilities — what's being actively used in attacks right now.
• EU coordinated vulnerabilities — flaws being handled through European CSIRTs.

The "exploited" view matters most operationally. It tells a client which of the thousands of monthly CVEs are actually being weaponised — which is the difference between a patch backlog and a fire drill.

Article 12 creates a disclosure pipeline, not just a database

The database is the visible part. The mechanism underneath is coordinated vulnerability disclosure, and it changes who your clients talk to when they find a flaw.

Every member state has designated one of its CSIRTs as the national CVD coordinator. That coordinator does specific work: it identifies and contacts the entities affected by a reported vulnerability, supports the researcher who reported it, negotiates a disclosure timeline, and handles flaws that hit multiple organisations at once. ENISA sits above this as the secretariat of the EU CSIRTs Network, coordinating across borders when a single flaw threatens entities in several countries.

For a consultant, the takeaway is concrete. When a client's security researcher — or a customer, or a bug bounty participant — reports a flaw in the client's product, there is now a defined channel and a defined counterparty. "We'll figure out who to tell" is no longer an acceptable answer.

NIS2 Incident Reporting Timeline
24h
⚡
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
Step 1
72h
📋
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
Step 2
1mo
📊
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.
Step 3
24h
⚡
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
72h
📋
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
1mo
📊
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.

September 2026: reporting actively exploited vulnerabilities becomes mandatory

Here is the date to put in front of clients. From September 2026, notifying actively exploited vulnerabilities becomes mandatory for manufacturers of ICT products.

This obligation does not land on every NIS2 entity equally. It targets the vendors — the organisations that build and ship software and connected hardware. But the reach is wider than most clients assume, because it travels through the supply chain. An MSP that develops a custom integration, a SaaS vendor in scope as an important entity, a manufacturer embedding firmware in a device — all of them can carry a reporting duty.

The requirement is narrow but sharp. It is not "report every CVE." It is: when you know a vulnerability in your product is being actively exploited, you notify. That distinction — actively exploited, not merely discovered — is what makes the EUVD's exploited-vulnerabilities feed the operational backbone of the obligation.

For clients who ship products, three questions need answers before September 2026:

1. Who inside the organisation is responsible for deciding a vulnerability is "actively exploited"?
2. What is the notification path to the relevant CSIRT, and is it tested?
3. How fast can the organisation move from internal knowledge to formal notification?

If a client can't answer all three today, that's the gap to close.

How the disclosure obligation cascades down the supply chain

NIS2 was deliberately built so that obligations don't stop at the entity in scope. Article 21's supply chain requirements push security expectations onto suppliers, and coordinated vulnerability disclosure rides along with them.

A practical example: an essential entity in the energy sector runs a SCADA component from a mid-size vendor. That vendor may not be a NIS2 entity in its own right. But the energy operator's Article 21 obligations mean the operator must manage supply-chain risk — which increasingly means demanding that the vendor have a working CVD process and report exploited flaws. The obligation cascades by contract even where it doesn't apply by statute.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

This is where consultants earn their fee. The work isn't reading the directive to clients. It's mapping which of a client's suppliers carry vulnerability-disclosure expectations, getting those expectations into contracts, and giving the client a way to verify they're met.

What "operationalising CVD" actually means for an MSP

For MSPs running infrastructure on behalf of clients, the EUVD changes the daily vulnerability-management workflow. Three concrete shifts:

Monitoring. Add the EUVD exploited-vulnerabilities feed to the sources you already watch. It carries EU-specific advisories and exploitation markings that a US-centric feed may surface later or not at all. For European clients, this is closer to the regulators' own view of risk.

Intake. Every client who ships a product needs a published way to receive vulnerability reports — a security.txt file, a disclosure email, a defined contact. This is the single cheapest, highest-value control you can implement, and most SMB clients don't have it.

Triage and notification. Define, in writing, the threshold and the path. When a reported flaw is confirmed as actively exploited, who decides, who notifies the CSIRT, and within what window. Document it before you need it.

None of this is exotic. It's the same discipline as incident response, applied to vulnerabilities instead of breaches. The clients who'll struggle in 2026 are the ones treating disclosure as an afterthought.

Where this fits in a readiness assessment

Coordinated vulnerability disclosure is not a standalone project. It's one measurable slice of a client's overall NIS2 compliance posture, sitting alongside incident reporting, supply-chain controls, and the Article 21 measures.

If you're running a gap analysis for a client this year, three CVD-specific checks belong on the list: do they monitor the EUVD or an equivalent EU-aware feed, do they have a working intake channel for inbound reports, and — for product vendors — do they have a tested path to notify exploited vulnerabilities before September 2026.

You can map these gaps fast. Our NIS2 quick scan flags exactly where a client's vulnerability-handling and supply-chain posture falls short, so you can move straight to remediation instead of starting from a blank page.

The deadline is real and the database already exists

The EUVD isn't a proposal. It's live, it's free, and your clients can use it tomorrow. The September 2026 manufacturer reporting obligation isn't a consultation either — it's a date.

The consultants who get ahead of this will spend 2026 helping clients build working disclosure processes. The ones who don't will spend it explaining to clients why nobody warned them. The work is straightforward. The window is not unlimited.

For the broader picture of how these obligations connect, see our guides on NIS2 supply chain security and the Article 21 ten measures.