NIS2 deals with vulnerabilities at two levels. Article 12 requires each Member State to designate one CSIRT as coordinator for coordinated vulnerability disclosure, and has ENISA run a European vulnerability database, live since May 2025. Article 21(2)(e) requires essential and important entities to include vulnerability handling and disclosure in their security measures.
This guide covers what Article 12 sets up, the European vulnerability database, what your company must do, the stricter rules for digital providers and manufacturers, national additions, a policy template, what the law leaves open, and a checklist.
| Provision | Who it binds | What it requires | Status, September 2026 |
|---|---|---|---|
| NIS2 Art. 7(2)(c) | Member States | National policy on managing vulnerabilities and promoting coordinated disclosure | Part of each national strategy |
| NIS2 Art. 12(1) | Member States and their CSIRTs | A coordinator CSIRT that takes reports, anonymously if asked | Due from 18 October 2024 |
| NIS2 Art. 12(2) | ENISA | A European vulnerability database | EUVD launched 13 May 2025 |
| NIS2 Art. 21(2)(e) | Essential and important entities | Vulnerability handling and disclosure as part of the security measures | Through national law, due from 18 October 2024 |
| Implementing Regulation 2024/2690, Annex 6.10 | Cloud, data centre, MSP, MSSP and other listed digital providers | Monitor, scan, fix critical vulnerabilities, disclosure procedure | In force since 7 November 2024 |
| CRA Art. 14 | Manufacturers of products with digital elements | Report actively exploited vulnerabilities, first within 24 hours | Applies since 11 September 2026 |
| CRA Annex I, Part II | Manufacturers | Disclosure policy, contact address, software bill of materials | From 11 December 2027 |
What is coordinated vulnerability disclosure under NIS2?
Recital 58 describes coordinated vulnerability disclosure (CVD) as a structured process: a vulnerability is reported to the manufacturer or provider so it can diagnose and fix it “before detailed vulnerability information is disclosed to third parties or to the public”. The recital points to ISO/IEC 29147 (disclosure) and ISO/IEC 30111 (handling) for guidance. NIS2 makes neither mandatory.
What does NIS2 Article 12 require?
Article 12 is addressed to Member States and ENISA, not to companies.
A CSIRT as coordinator
Each Member State must designate one of its CSIRTs as coordinator. Where necessary, it acts as “a trusted intermediary” between the person reporting a vulnerability and the manufacturer or provider concerned. Its tasks are:
- identifying and contacting the entities concerned;
- assisting the people reporting a vulnerability;
- negotiating disclosure timelines and managing vulnerabilities that affect multiple entities.
Anyone must be able to report to the coordinator, anonymously if they ask, and the coordinator must ensure diligent follow-up. Where a vulnerability could have a significant impact in more than one Member State, the coordinators cooperate within the CSIRTs network “where appropriate”. How the coordinator fits among the national bodies is in the NIS2 institutional architecture. Article 7(2)(c) adds that each national strategy must include a policy on managing vulnerabilities, promoting and facilitating coordinated disclosure.
What Article 12 does not do
It sets no disclosure deadline; timelines are negotiated. It creates no duty for your company to report vulnerabilities: mandatory reporting under Article 23 concerns significant incidents. It gives researchers no legal immunity either. Recital 60 only encourages Member States to adopt guidelines on non-prosecution of security researchers and exemption from civil liability. National law decides.
What is the European vulnerability database (EUVD)?
Article 12(2) requires ENISA to develop and maintain a European vulnerability database. Entities, “regardless of whether they fall within the scope” of NIS2, and their suppliers can register publicly known vulnerabilities there on a voluntary basis, and all stakeholders get access. Entries describe the vulnerability, the affected products or services and severity, and available patches or, failing those, mitigation guidance from authorities or CSIRTs.
ENISA launched it as the EUVD on 13 May 2025. It aggregates CVE records, vendor advisories, CISA’s Known Exploited Vulnerabilities catalogue and national CSIRT information, with dashboards for critical, exploited and EU-coordinated vulnerabilities. Recital 63 asks ENISA to explore close cooperation with the CVE system rather than duplicate it. For most companies it is a feed to watch, not a register to file in.
What must your company do about vulnerabilities under NIS2?
Article 21(2)(e) lists among the minimum measures “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. It applies to essential and important entities alike, in proportion to their risk, and gives no further detail. Recital 58 explains the intent: entities that develop or administer systems “should” have procedures to handle vulnerabilities, and manufacturers and providers “should” be able to receive vulnerability information from third parties. So the measure has two halves.
Handling: finding and fixing your own vulnerabilities
A sensible approach, and one auditors recognise from ISO 27001 control A.8.8, is:
- keep an inventory of systems and software, including everything internet-facing;
- scan at planned intervals and follow vendor, CSIRT and EUVD advisories;
- rate each finding on severity and exposure, including whether it is being exploited;
- set patch timelines per rating, for example days for exploited critical flaws and weeks for the rest;
- track every exception with an owner, a reason and an end date.
Those timelines are practice. NIS2 sets no patch deadline.
Disclosure: letting others tell you
Researchers, customers and CSIRTs will find vulnerabilities in your systems. In practice, letting them reach you means:
- a short published disclosure policy;
- a security.txt file at /.well-known/security.txt (RFC 9116), whose only required fields are Contact and Expires;
- a monitored inbox with a named owner and a deputy;
- triage within an agreed time, and a record of each report;
- if you make software, advisories when you ship a fix.
What are the stricter rules for digital providers?
For DNS, TLD, cloud, data centre, CDN, managed and managed security service providers, online marketplaces, search engines, social networks and trust service providers, Implementing Regulation (EU) 2024/2690 spells it out. Section 6.10 of its Annex requires them to:
- monitor vulnerability information, for example CSIRT and authority announcements and supplier information;
- where appropriate, scan at planned intervals and keep evidence of the results;
- address vulnerabilities critical to their operations “without undue delay”;
- align vulnerability handling with change, patch, risk and incident management;
- “lay down a procedure for disclosing vulnerabilities in accordance with the applicable national coordinated vulnerability disclosure policy”.
Where impact justifies it, they plan and implement mitigation; otherwise they document why no remediation is needed. Section 6.6 adds that patches are applied “within a reasonable time”, tested and taken from trusted sources, and a decision not to patch is justified in writing. Other entities are not bound by it, but it is a concrete official reading of Article 21(2)(e), as set out in the ten Article 21 measures.
What does the Cyber Resilience Act add for manufacturers?
If you place products with digital elements (hardware or software) on the EU market, the Cyber Resilience Act (Regulation (EU) 2024/2847) applies, subject to some sector exclusions, whether or not you are in NIS2 scope.
- Since 11 September 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities in their products: early warning within 24 hours, notification within 72 hours, final report within 14 days of a fix or mitigation being available. Reports go through ENISA’s single reporting platform to the CSIRT designated as coordinator under NIS2 Article 12, and to ENISA. See CRA reporting obligations.
- From 11 December 2027, Article 13(8) requires effective vulnerability handling for the support period, in line with Annex I, Part II: a software bill of materials, a coordinated vulnerability disclosure policy, a contact address for reports, and public disclosure of fixed vulnerabilities.
Your NIS2 customers will ask. Article 21(3) requires them to consider their direct suppliers’ product quality and secure development, as covered in NIS2 supply chain security.
Do national laws go further?
Some do. According to the Centre for Cybersecurity Belgium (CCB), Belgium’s NIS2 law lists a coordinated vulnerability disclosure policy as an eleventh measure for essential and important entities, next to the directive’s ten. The details are in the Belgian NIS2 law. Check your own national law, and read your national coordinated vulnerability disclosure policy: Implementing Regulation 2024/2690 points to it directly.
Vulnerability disclosure policy template
A policy does not need to be long. This minimal version covers what researchers look for. The response times are examples, not legal requirements; check the legal wording with counsel.
VULNERABILITY DISCLOSURE POLICY [Company] v1.0, [date]
Scope
In scope: [domains, applications, products and versions]
Out of scope: third-party services, denial of service,
social engineering, physical testing
How to report
Email: security@[domain] (encryption key: [URL])
security.txt: https://[domain]/.well-known/security.txt
Include: affected asset, steps to reproduce, impact
Anonymous reports are accepted.
What we commit to
Acknowledge your report within [3] working days
Give an initial assessment within [10] working days
Keep you informed until the issue is fixed
Agree a disclosure date with you, normally within [90] days
Credit you, if you wish, once the fix is released
What we ask of you
Test only what is needed to show the vulnerability
Do not access, change or keep more data than necessary
Do not disrupt services or harm users
Do not disclose publicly before the agreed date
Coordination
If we do not respond, or several vendors are affected, you
may contact the national CSIRT designated as coordinator:
[name, URL]
Legal
We will not take legal action over good-faith research that
follows this policy. [Check against national law.]What does the law leave open?
The legal text stops at “handling and disclosure”. It does not say how fast, how thorough, or how you prove it. Three gaps come up in practice.
The inbox. A published policy is worthless if security@ lands in a shared mailbox nobody reads. Someone has to own intake and know when a report is really an incident.
The inventory. You cannot tell anyone whether a new CVE affects you without knowing which systems and versions you run. Asset lists tend to cover servers and miss appliances, SaaS integrations and old subdomains.
The evidence. An authority asking about Article 21(2)(e) wants scan results, patch times against your own targets, and the exceptions you accepted and why. Collected by hand once a year, that record is stale on arrival. Pulled continuously from scanners, endpoint tools and ticketing, with a person reviewing the exceptions, it shows the measure operating. That is how the CloudSoul platform works: automated evidence collection with human-in-the-loop expertise. A security audit shows where your vulnerability process stands today, and the wider programme is on the NIS2 compliance page.
NIS2 vulnerability disclosure checklist
- Publish a disclosure policy and a security.txt file with a current Expires date.
- Name an owner and a deputy for the security inbox, and set a response time.
- Keep an inventory of systems and software, including internet-facing assets.
- Follow advisories from your vendors, your national CSIRT and the EUVD.
- Scan at planned intervals and keep the results.
- Set patch timelines by severity and record every exception with a reason.
- Identify your national coordinator CSIRT and read the national CVD policy.
- If you make products, meet CRA reporting now and plan for the CRA disclosure rules from December 2027.
Sources
- Directive (EU) 2022/2555 (NIS2), Articles 7, 12, 21 and 23 and recitals 58 to 63, EUR-Lex; article text also at nis-2-directive.com.
- Commission Implementing Regulation (EU) 2024/2690, Annex sections 6.6 and 6.10, EUR-Lex.
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14 and 71 and Annex I, Part II, EUR-Lex.
- ENISA, Consult the European Vulnerability Database to enhance your digital security, 13 May 2025, and the EUVD.
- Centre for Cybersecurity Belgium, NIS2 obligations.
- IETF, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, April 2022.
- ISO, ISO/IEC 29147:2018 Vulnerability disclosure and ISO/IEC 30111:2019 Vulnerability handling processes.
Frequently asked questions
What does NIS2 Article 12 require?
Each Member State must designate one of its CSIRTs as coordinator for coordinated vulnerability disclosure, acting as a trusted intermediary between people who report vulnerabilities and the manufacturers or providers concerned. Article 12(2) requires ENISA to maintain a European vulnerability database, launched as the EUVD on 13 May 2025.
Is a vulnerability disclosure policy mandatory under NIS2?
Article 21(2)(e) requires essential and important entities to include vulnerability handling and disclosure in their security measures, without prescribing a document. Digital providers covered by Implementing Regulation (EU) 2024/2690 must lay down a disclosure procedure, and some national laws, such as Belgium's, list a coordinated vulnerability disclosure policy as a measure of its own.
Do companies have to report vulnerabilities to the CSIRT under NIS2?
No. NIS2 Article 23 requires reporting of significant incidents, not vulnerabilities. Manufacturers of products with digital elements must, however, report actively exploited vulnerabilities under Article 14 of the Cyber Resilience Act, which has applied since 11 September 2026.
Does NIS2 protect ethical hackers from prosecution?
Not directly. Recital 60 encourages Member States to adopt guidelines on the non-prosecution of security researchers and an exemption from civil liability. Whether a researcher is protected depends on national law.
What is the EUVD?
The European Vulnerability Database that ENISA runs under NIS2 Article 12(2). It launched on 13 May 2025, aggregates sources such as CVE records, vendor advisories and national CSIRTs, and registration by entities is voluntary.
