Who should read this: Security Researchers, Vulnerability Disclosure Coordinators, Product Security Teams, Cybersecurity Policy Makers.
For security researchers, the emergence of the NIS2 Directive presents both opportunity and obligation. The Directive explicitly establishes a framework for coordinated vulnerability disclosure (CVD) in Article 12, creating institutional structures and processes through which researchers can report vulnerabilities responsibly. This is significant: the Directive recognises that responsible disclosure requires coordination, that researchers play a critical role in improving security, and that trustworthy processes are necessary for disclosure to function effectively. If you are a researcher, a vulnerability coordinator, or work in product security, understanding Article 12 and the European vulnerability disclosure ecosystem it creates is essential.
Coordinated vulnerability disclosure is not new; security researchers have been disclosing vulnerabilities responsibly for decades. What is new is the creation of a formal, EU-wide framework with dedicated institutional support. The Directive establishes CSIRTs designated as coordinators in each Member State, creates a European vulnerability database, and sets out procedures for managing vulnerabilities that cross borders or affect multiple vendors. This infrastructure creates a trusted path for responsible disclosure and protects researchers from legal liability when they disclose vulnerabilities in good faith.
The CSIRT Coordinator Role
Under Article 12(1), each Member State must designate one of its computer security incident response teams (CSIRTs) as a coordinator for vulnerability disclosure. This coordinator CSIRT has several specific functions that are foundational to the NIS2 vulnerability ecosystem.
First, the coordinator CSIRT acts as a trusted intermediary. If you discover a vulnerability and wish to disclose it responsibly, you can report it to your Member State’s coordinator CSIRT. The CSIRT then identifies the affected vendor or manufacturer and facilitates communication between you and them. This intermediary role is important because it protects your anonymity if you request it, and it creates a neutral third party that can help manage the inevitable friction that sometimes occurs between researchers and vendors during disclosure.
Second, the coordinator CSIRT assists you as a researcher. If you need guidance on how to structure your disclosure, how to test your findings without causing harm, or how to manage communication with a vendor that is being difficult, the CSIRT coordinator can help. This is not merely a nice-to-have; it is a formal service available to all researchers reporting vulnerabilities within Europe.
Third, the coordinator CSIRT negotiates disclosure timelines and manages vulnerabilities affecting multiple entities. If your vulnerability affects three different vendors’ products, the coordinator CSIRT will work to synchronise disclosure across those vendors, ensuring that patches are coordinated and disclosure happens at approximately the same time. This prevents the situation where an early discloser is disadvantaged because they patch before others have fixed the same vulnerability.
Article 12(1) explicitly permits researchers to report vulnerabilities to the coordinator CSIRT anonymously if they wish. The CSIRT must ensure diligent follow-up on your report and must maintain your anonymity throughout the process if you request it. This is a significant protection, particularly for researchers in smaller Member States or less developed cybersecurity ecosystems where researcher anonymity might otherwise be difficult to guarantee.
Where a vulnerability could have significant impact on entities across multiple Member States, the coordinator CSIRTs of each Member State concerned must cooperate. If you discover a vulnerability in a DNS root nameserver or a major cloud provider’s infrastructure, the scale of potential impact could easily cross borders. The CSIRTs network will coordinate the disclosure process to ensure coherent response across Europe.
The European Vulnerability Database
Article 12(2) requires ENISA (the European Union Agency for Cybersecurity) to develop and maintain a European vulnerability database. This database is distinct from existing vulnerability repositories like the National Vulnerability Database (NVD) or Mitre’s CVE system. It is Europe-specific and serves a particular role within the NIS2 framework.
The European vulnerability database contains information about publicly disclosed vulnerabilities in ICT products and ICT services. Notably, it is voluntary; vendors and researchers can choose to register vulnerabilities, and participation is not mandated. However, the database is designed to serve as a central point of reference for vulnerability information that is particularly relevant to European entities and regulators.
The database includes four key categories of information. First, it contains descriptions of the vulnerability itself: what it is, what systems it affects, and under what conditions it can be exploited. Second, it specifies affected ICT products and services and the severity of the vulnerability. Third, it provides information about patches: whether patches are available, when they were released, and where they can be obtained. Fourth, if patches are not available, the database provides guidance from competent authorities or CSIRTs on how users can mitigate the vulnerability.
For researchers, this database provides several benefits. Publishing your vulnerability information in the European vulnerability database gives it official recognition within the EU’s cybersecurity governance framework. Affected organisations across the EU can discover the vulnerability, access technical details, and find patch information from a trusted, official source. This reduces the likelihood that vulnerability information will be fragmented across different platforms or lost in translation between different national regulatory systems.
The database also supports what the Directive calls “all stakeholders.” This means vendors and manufacturers (who can monitor the database for vulnerabilities affecting their products), enterprise security teams (who can use the database to track vulnerabilities affecting their infrastructure), and policy makers (who can use the database to understand emerging vulnerability trends and allocate resources accordingly).
Vulnerability Disclosure Governance
The framework Article 12 establishes reflects several important principles that govern vulnerability disclosure under NIS2.
First is the principle of legitimate protection. Researchers who disclose vulnerabilities in good faith, following the Article 12 framework, have legal protection. This is critical. Without legal protection, researchers would be reluctant to disclose responsibly, and vulnerabilities would instead be sold on dark markets or used for criminal purposes. The Directive makes clear that coordinated vulnerability disclosure is a public good and that researchers participating in it have the Directive’s backing.
Second is the principle of reasonable timelines. The Directive does not mandate a specific disclosure window (for example, “vendors must patch within 30 days”) because such windows are not universally appropriate. Some vulnerabilities are trivial to patch; others require substantial development effort. Some vendors have rapid release cycles; others release patches quarterly. The framework requires that timelines be “negotiated,” which means coordinators should facilitate discussion between researchers and vendors to agree on a reasonable timeline that accounts for the specific vulnerability’s complexity and the vendor’s development cycle.
Third is the principle of graduated response. If a vendor is unresponsive or fails to patch despite agreement on a timeline, the process should escalate. A researcher can escalate to the coordinator CSIRT, which can attempt to locate an alternative contact within the vendor organisation or escalate to the vendor’s national competent authority. This graduated approach provides leverage for researchers whilst maintaining an orderly process.
Fourth is the principle of affected entities’ right to know. Article 12(1) requires that coordinators ensure diligent follow-up, which includes making sure vendors know about vulnerabilities affecting their products. If a vendor fails to acknowledge a vulnerability report, the CSIRT coordinator should pursue the issue until the vendor responds or it becomes clear that the vendor is not responsive.
Researchers’ Responsibilities and Best Practices
Article 12 creates opportunities for researchers, but it also implies responsibilities. Coordinated vulnerability disclosure under the framework comes with expectations about how you conduct your research and how you communicate your findings.
When you discover a potential vulnerability, you should have reasonable confidence that it is real before disclosing it. This means conducting sufficient testing to confirm that the vulnerability exists and understanding the conditions under which it can be exploited. Responsible disclosure does not mean disclosing every theoretical possibility; it means disclosing vulnerabilities that you have validated.
You should disclose to the appropriate entity. For vendors and manufacturers operating in Europe, your first contact should be the vendor’s security team (if you can identify them) or your national CSIRT coordinator. Including the vendor directly in your disclosure, even before involving the CSIRT, is often the most efficient path, provided you have a working vendor security contact. The CSIRT coordinator is available if direct vendor contact fails or if you are uncomfortable contacting the vendor directly.
You should provide sufficient technical detail for the vendor to understand and fix the vulnerability. This does not mean publishing exploit code immediately, but it does mean explaining the vulnerability clearly enough that a competent developer can reproduce it and identify the root cause.
You should be patient. Vendors, even responsible ones, need time to develop, test, and release patches. If you have negotiated a timeline with the vendor (perhaps through the CSIRT coordinator), allow that timeline to expire before escalating further.
You should respect embargoes and pre-disclosure confidentiality. If you have agreed with a vendor that you will not disclose a vulnerability publicly until a specific date, honouring that agreement is both ethical and essential to maintaining trust in the disclosure process.
The Broader Ecosystem
Article 12 coordinates researchers, vendors, and CSIRTs, but it exists within a broader ecosystem of standards and practices. ISO 30111 provides guidance on vulnerability handling; ISO 29147 provides guidelines for vulnerability disclosure. These standards are relevant to how the Article 12 framework operates, even though NIS2 does not mandate them by name.
Similarly, organisations are increasingly adopting responsible disclosure policies and operating bug bounty programmes. The Article 12 framework complements these private-sector initiatives. A researcher who discovers a vulnerability can either report it through a vendor’s bug bounty programme (if one exists) or through the NIS2 framework. Over time, these pathways should converge toward a more seamless European vulnerability disclosure ecosystem.
Key Takeaways
-
Article 12 establishes a formal coordinated vulnerability disclosure framework with each Member State designating a CSIRT coordinator to facilitate responsible disclosure and protect researcher anonymity.
-
Your national CSIRT coordinator can assist with vulnerability disclosure, negotiate timelines with affected vendors, and coordinate disclosure across multiple Member States if a vulnerability affects entities in more than one country.
-
The European vulnerability database, maintained by ENISA, serves as a central repository for publicly disclosed vulnerabilities relevant to European entities. Publishing your findings there integrates them into the official EU cybersecurity framework.
-
Researchers disclosing vulnerabilities under Article 12 have legal protection. Good-faith coordination with vendors through the CSIRT coordinator framework is the process through which this protection is secured.
-
Timeline negotiation is core to the framework. Disclosure timelines should be reasonable, should account for the vulnerability’s complexity and the vendor’s development cycle, and should be documented.
