Vulnerability handling

ENISA Now Governs 20 CNAs as a CVE Root: What It Means for CRA-Scope Manufacturers

Last updated · August 21, 2026

TL;DR: On 6 August 2026, ENISA announced that two new organisations - NATO's technology agency and an AI security firm - joined the global vulnerability-numbering system under ENISA's authority. ENISA now governs 20 CVE Numbering Authorities as a CVE Root. This is about where CVE IDs get assigned for European-discovered vulnerabilities. It does not change your Article 14 reporting duty. You do not need to become a CNA to comply with the CRA. Read on for what this actually means in practice.

What just happened

On 6 August 2026, ENISA announced that the NATO Communications and Information Agency (NCIA) and AI cybersecurity firm AISLE had joined the CVE Program as CVE Numbering Authorities (CNAs) under the ENISA Root. That brings ENISA's total to 20 CNAs under its Root, including 8 transferred from the MITRE Root.

Hans de Vries, ENISA's Chief Cybersecurity and Operations Officer, described it as "a major milestone for European cybersecurity" that "improves the reliability, timeliness, and coordination of vulnerability handling across the EU."

If those terms - CVE Root, CNA, MITRE Root - are unfamiliar, that's fine. Most product and compliance teams don't need to live inside vulnerability-management infrastructure. This post explains what each term means, why the change matters, and what (if anything) you need to do.

Plain-English glossary: CVE, CNA, Root

CVE stands for Common Vulnerabilities and Exposures. Founded in 1999, the CVE Program is a global system for identifying and cataloguing publicly disclosed cybersecurity vulnerabilities. Every vulnerability gets a unique ID - CVE-2024-XXXXX - so that developers, vendors, security teams, and governments worldwide can be sure they're talking about the same flaw.

CNA stands for CVE Numbering Authority. CNAs are organisations authorised by the CVE Program to assign CVE IDs to vulnerabilities and to create and publish the accompanying CVE Records. Think of them as the entities that stamp a unique serial number onto a newly discovered flaw and write the official description. Large software vendors, national CSIRTs, research organisations, and some hardware manufacturers are CNAs. Participation is voluntary.

Root is a tier above a CNA. A Root recruits, trains, and governs CNAs within a defined scope. Until recently, MITRE - a US non-profit - operated the dominant Root for most of the world. CISA runs a separate Root for industrial control systems. ENISA is now a Root for European entities and vulnerabilities discovered by or reported to EU CSIRTs.

The hierarchy in one sentence: MITRE/CISA/ENISA are Roots → they oversee CNAs → CNAs assign CVE IDs → CVE IDs appear in vulnerability databases worldwide. Manufacturers who aren't CNAs sit outside this hierarchy entirely — they receive CVE IDs assigned by others, and separately file Article 14 reports to ENISA's SRP.

ENISA's path to Root: a quick timeline

ENISA has been assigning CVE IDs and publishing CVE Records since January 2024, when it became a CNA for vulnerabilities discovered by or reported to EU CSIRTs. Becoming a Root formalises and expands that authority: ENISA can now recruit and govern other CNAs within its scope, not just assign IDs itself.

The practical effect is that EU CSIRTs and the CNAs under the ENISA Root can now assign CVE IDs without routing through the US-based MITRE Root. That should mean faster CVE assignment for EU-relevant vulnerabilities and more consistent handling of cross-border disclosures within Europe.

There are currently over 90 CNAs in Europe that can transfer voluntarily under the ENISA Root, out of a total of 510 CNAs from 42 countries actively participating in the CVE Program. ENISA has said more organisations have already requested onboarding in the coming weeks.

ENISA is also working closely with CISA and MITRE throughout this transition - the intent is to reinforce the shared global CVE backbone, not fragment it.

What this means for your products

Here is the practical read for a manufacturer of connected products.

CVE IDs on your products are assigned by others. When a researcher or CSIRT discovers a vulnerability in your product and it doesn't fall within your own CNA scope, they request a CVE ID from the relevant CNA - which may now be one under the ENISA Root. You receive the ID; you don't issue it. The change in who governs that CNA doesn't alter your responsibilities.

Faster EU-side CVE assignment may help your coordinated disclosure process. If a vulnerability in your product is reported to an EU CSIRT, that CSIRT (or a CNA under the ENISA Root) can now assign the CVE ID without going through MITRE. In practice, this could shorten the time between a researcher reporting a flaw and a CVE ID appearing publicly - which matters when you're coordinating a patch release timeline.

This is separate from your Article 14 reporting duty. The CVE Root structure governs who assigns CVE IDs. Article 14 of the CRA governs what manufacturers must report to ENISA's Single Reporting Platform (SRP) and when. These are parallel systems. A vulnerability getting a CVE ID does not automatically trigger an Article 14 report; active exploitation or a severe incident does. Conversely, filing an Article 14 report does not assign a CVE ID.

The Article 14 clock is still ticking. Mandatory reporting via the SRP starts 11 September 2026 — 24h early warning, 72h notification, 14-day final report for actively exploited vulnerabilities. The CVE Root news does not move or modify those deadlines. If you haven't confirmed your SRP readiness, that's the more urgent task right now.

Should your organisation become a CNA?

Probably not - unless you're a large manufacturer, an open-source project with a significant user base, or a security research organisation. Here's the honest breakdown.

For context: CNA participation is voluntary, and the core requirements are a public vulnerability disclosure policy, a public source for new vulnerability disclosures, and agreement to follow CVE Program rules. There is no contract to sign and no fee. The commitment is operational - you must assign IDs consistently and respond to researchers within defined timelines.

For most CRA-scope manufacturers, the more pressing question is not "should we become a CNA?" but "are we ready to file an Article 14 report on 11 September?"

The SRP: still the thing to watch

ENISA's CVE Root role and its SRP role are both part of the same broader vulnerability-management picture, but they're operationally distinct. The CVE Root governs ID assignment. The SRP governs mandatory incident and vulnerability reporting by manufacturers.

On the SRP: ENISA published step-by-step instructions for the Single Reporting Platform on 31 July 2026. As of early August, the platform itself was not yet live - the SRP's public access URL had not been published, and ENISA had scheduled the platform to be operational by 11 September 2026, the date mandatory reporting begins. Short instructional videos and a pre-launch webinar were still to come.

The guidance published so far is marked as subject to change. That's a nuance worth holding: the instructions exist, the platform does not yet. Watch ENISA's SRP page for the go-live URL and any guidance updates before 11 September.

Three things you can do now that don't depend on the platform being live:

Create EU Login accounts for the people who will file reports. Do it before an incident forces you to do it under pressure.
Map your products to scope. The 72-hour notification stage asks for product type and Annex III/IV category. Know the answer in advance.
Build your internal 24-hour early warning process. A short internal form, two named people who can complete it out of hours, and a clear escalation path from your CVD intake.

How the two systems connect

It's worth seeing the full picture in one place.

How a vulnerability flows from discovery to CRA report

The key point: CVE assignment and Article 14 reporting are parallel tracks. A vulnerability can get a CVE ID without ever triggering a mandatory report. And a severe incident may need to be reported before a CVE ID has even been assigned.

The bottom line

ENISA's growing CVE Root authority is a structural improvement to how European vulnerabilities are identified and tracked. For most manufacturers, it means CVE IDs for EU-discovered flaws may arrive faster and with better coordination. It does not create new compliance obligations.

What does create obligations - starting 11 September 2026 - is Article 14. That clock is not affected by this announcement. If your SRP readiness is solid, this news is background context. If it isn't, that's where to focus.

We'll update this post if ENISA publishes material changes to CNA onboarding guidance or the SRP go-live date shifts.

CRA Facts is an independent plain-English guide to Regulation (EU) 2024/2847, operated by Nukipa Labs GmbH. It is not affiliated with the EU, the European Commission, or ENISA. Nothing here is legal advice.