Europe takes more control of the vulnerability register, and NATO IT agency joins

ENISA announced on 6 August 2026 that the NATO Communications and Information Agency, NCIA, and the company AISLE have become CVE Numbering Authorities under the ENISA Root. Such an authority holds the right to assign CVE identifiers for vulnerabilities within its own defined scope. ENISA itself became a Root in the CVE Program in November 2025, and is thereby the point of contact within the programme for EU member states, for EU bodies and for the members of the CSIRTs Network. According to ENISA there are now twenty numbering authorities under the ENISA Root, eight of which were transferred from the MITRE Root. Hans de Vries, ENISA Chief Cybersecurity and Operations Officer, states that recent developments have underscored the need to build strong vulnerability management infrastructure.

What happens technically

The CVE Program is the naming system for vulnerabilities. When a weakness becomes known it receives a CVE identifier, and that identifier is the shared key everything else hangs on. Scanners, vendor advisories, national databases and risk tooling all refer to the same number. Without such a shared name the same vulnerability would carry a different label in every tool, and it would be impossible to tell whether two advisories concerned the same issue. The programme is built in layers. A CVE Numbering Authority issues identifiers within a defined scope, typically its own products. A Root recruits, trains and oversees such authorities, and ensures that programme rules are followed. This is the role ENISA now fills for Europe.

Alongside this, ENISA operates the European Vulnerability Database, EUVD, which opened on 13 May 2025. The database aggregates information from CSIRTs, vendors and existing databases, and presents it in three views: critical vulnerabilities, exploited vulnerabilities, and vulnerabilities coordinated by European CSIRTs. EUVD carries its own identifiers, but they are mapped to the CVE identifiers issued under MITRE. That is a deliberate choice, and coverage of the launch describes the point as interoperability rather than competition. The legal basis is NIS2, which requires ENISA to maintain a European registry of vulnerabilities. According to Industrial Cyber the basis is article 12 of the directive.

The reason this became urgent lies in April 2025. MITRE then publicly warned that its contract to operate the CVE Program was about to lapse. The programme came close to stopping on 16 April, and the American agency CISA extended the funding at the last moment. The episode lasted less than two days, but it revealed something that did not pass with it. The naming system on which the whole world's vulnerability management rests depended on a single contract in a single country. ENISA brought forward the launch of EUVD afterwards, and the database went live sooner than originally planned.

That NCIA now becomes a numbering authority under the ENISA Root is therefore more than an administrative detail. The NATO communications agency delivers and operates systems for the alliance. When such an environment assigns CVE identifiers through the European Root, disclosure of its own vulnerabilities runs through European infrastructure. The other authority, AISLE, is described by ENISA as a company working in artificial intelligence and cybersecurity. The figures ENISA gives tell the direction more clearly than the individual names do. Eight of the twenty authorities under the European Root moved there from the MITRE Root. This is therefore not only the building of something new alongside what exists, it is also the relocation of responsibility that was already held.

What this means for you if you track vulnerabilities professionally

This is a question of digital sovereignty, and it is worth saying what that word means for you. It does not mean that Europe should build its own alternative to everything. It means that critical shared functions must not be able to stop because a decision is taken somewhere else. The vulnerability reporting you build your work on is such a function. It is cheap to run and priceless on the day it is missing. Vulnerability data is also intelligence, in the sense that it says where something is weak, and who learns it first. A union that cannot itself assign names to weaknesses in its own systems depends on someone else doing so in time. The episode in April 2025 showed that the distance between a working system and a stopped one was a single contract renewal. Europe did not answer by leaving the arrangement, but by building a parallel route that points at the same identifiers.

The trade-off is real, and it runs in both directions. One shared naming system is a strength, because everyone then speaks about precisely the same vulnerability. Two registries can become a weakness, if they begin to diverge in content, timing or assessment. As long as EUVD maps to the CVE identifiers, this is redundancy of the useful kind. Should that mapping weaken, it becomes fragmentation, and you on the defending side pay the bill in duplicated work. That the NATO communications agency chooses the European Root suggests the infrastructure is meant to be real rather than symbolic. At the same time ENISA states that it retains competence under the MITRE Root, so this is not a break with the American-run programme but a distribution of risk within it. For you in Norway the practical consequence is less dramatic than the headlines suggest. The CVE identifier is still the key, and your tools work as before. What changes is where the information comes from, and how early European coordinated cases become visible to you. Berigo's assessment is that you should read both sources and use the CVE identifier as the shared key between them.

Berigo recommends

• Follow both the American and the European vulnerability database, and use the CVE identifier as the shared key between them.
• Verify that your tooling draws on more than one source, so that a single outage does not leave you blind.
• Note which of your vendors are numbering authorities themselves, since the advisory then comes from the source and often earlier.
• Include the dependency on external vulnerability registries in your contingency plan, as a supply you do not control.
• Watch whether the two registries begin to diverge in content or timing, because that is where any fragmentation will show first.