Vulnerability management has so far relied on a single global mechanism: MITRE's CVE programme, supported by a network of CNAs (CVE Numbering Authorities) mandated internationally. That model remains in place. But since November 2025, a second level of governance has been layered on top for Europe: ENISA has become CVE Root, the apex authority for the CNAs operating within the European scope. Now that the Cyber Resilience Act requires notifications through the ENISA platform from 11 September 2026, this two-tier architecture has direct consequences for your processes.
What is a CVE Root?
The CVE programme is structured in three tiers. At the top, Roots oversee networks of CNAs within a defined scope. The CNAs assign CVE identifiers and publish CVE Records for vulnerabilities within their scope. Below them, Sub-CNAs operate under the direct supervision of a CNA.
MITRE is the historic, global Root and the first point of contact for vulnerabilities without a designated CNA. ENISA is now the European Root, supervising European CNAs: national CSIRTs, Member State cybersecurity agencies and sector-specific authorities. In practice, ENISA recruits, trains and coordinates the CNAs within its sphere of competence. Four organisations have joined the CVE programme under ENISA supervision since November 2025, according to the ENISA announcement of 3 April 2026: Germany's BSI, the Dutch NCSC, Spain's CCN and France's national cybersecurity agency (ANSSI), which was already a CNA and has strengthened its link to the European Root.
The EUVD as a second reference register
ENISA operates the European Vulnerability Database (EUVD), deployed under the mandate of the NIS2 Directive and operational since January 2026. The EUVD aggregates the CVEs from the MITRE register, but adds vulnerabilities reported through national CSIRTs and European CNAs.
The distinction matters. A vulnerability may exist in the EUVD with its own EUVD identifier before it has received a MITRE CVE number, particularly when initial disclosure goes through the European channel. It may also be published in the EUVD with richer metadata than in the US NVD, including cross-border coordination information between Member States.
For your vulnerability management tools (scanners, SIEM, GRC platforms), this implies a dual source. Feeds that consult only the US NVD may miss vulnerabilities first disclosed through the ENISA channel. This is not a theoretical risk: since the EUVD went live, several vulnerabilities affecting European industrial equipment received their EUVD identifier before entering the NVD, with an observed delay of two to five working days.
What the CRA changes from 11 September
The Cyber Resilience Act requires manufacturers of digital products to notify actively exploited vulnerabilities in their products through ENISA's Single Reporting Platform (SRP) within 24 hours of detection. This obligation has been in force since 11 September 2026.
The notification must reference the vulnerability. If a CVE identifier exists, it must be mentioned. If the vulnerability has not yet received a CVE, ENISA coordinates the assignment through its Root role. The process is therefore reversed compared with the usual practice: in the MITRE channel, the vendor's CNA assigns the CVE before public disclosure. In the CRA channel, the notification arrives first, and the identifier follows.
This reversal has a direct operational consequence. The 24-hour window leaves no time to wait for a CVE assignment. Your teams must anticipate the scenario in which a vulnerability exploited in one of your products does not yet have a MITRE identifier. In that case, the SRP notification must describe the vulnerability by its technical characteristics: component, version, nature of the flaw, observed impact, attack vector. The CVE identifier will be assigned afterwards by ENISA.
Three adjustments to your processes
First action: audit your vulnerability monitoring sources. Your intelligence feeds (NVD, CERT-FR feeds, MITRE subscriptions) must be supplemented with the EUVD. The EUVD API is publicly accessible. Some patch management tools have already integrated these feeds natively since early 2026; check whether your asset management platform consults both registers, and not the US NVD alone.
Second action: document your SRP notification process. A tabletop exercise quickly reveals the gaps: what happens if a vulnerability actively exploited in your product is detected at 6 p.m. on a Friday? Who decides to notify? Who completes the SRP form? Who validates the content within 24 hours? These questions require documented answers, not improvisation. The technical description of a vulnerability without a CVE identifier must be drafted by your team in under one hour.
Third action: update your risk registers. If your GRC tool references vulnerabilities by MITRE CVE identifier only, you risk missing native EUVD entries. A reconciliation between the two registers should be built into your monthly review process. For organisations that have structured their software inventory around an SBOM connected to CVE feeds, adding the EUVD follows naturally from that work: the article on SBOM and software inventory under NIS2 and DORA details the mechanics of this inventory and its regulatory requirements.
The particular case of multinationals
For organisations operating outside Europe, dual governance creates a parallel identification regime. A vulnerability in a product distributed in Europe and in the United States may receive a MITRE identifier through the vendor's CNA and an EUVD identifier through the European channel. These two identifiers coexist without any formal hierarchy between them.
A study by the Cloud Security Alliance published in May 2026 notes that multinational organisations must now maintain a correspondence table between the two identification systems to avoid duplicates in their risk registers and inconsistencies in their audit reports. This mapping work is manual in most organisations today. Vulnerability management vendors have announced native integrations, but few are available so far.
What to take away
ENISA's status as CVE Root is not a minor detail of institutional governance. It structures the channel through which vulnerabilities are identified and coordinated in Europe, and through which your CRA notification obligations must now pass. Teams that still treat vulnerability management as a single-source process, MITRE and NVD, will need to adapt their feeds before the first CRA notification forces them to improvise under time pressure.
Dual governance is not added complexity for its own sake. It reflects the European wish no longer to depend on American infrastructure to coordinate responses to critical vulnerabilities affecting its entities. For your teams, the challenge is to turn this institutional reality into an operational process before a real incident raises the question.