ENISA's CVE Root Just Hit 20 CNAs — Here's What That Does (and Doesn't) Do for Your CRA Article 14 Deadline

On August 6, 2026, ENISA announced that NATO's Communications and Information Agency (NCIA) and the AI-security firm AISLE had joined the CVE Program as CVE Numbering Authorities (CNAs) under ENISA Root — bringing the total to 20 CNAs operating under ENISA's oversight, up from 11 in May. If you've read any of our own CRA Article 14 guides from earlier this year, you've seen a version of the line "you need CVE assignment capability — either become a CNA yourself or work with an existing one, typically via MITRE." That line is now out of date. MITRE is still very much part of the CVE Program, but it is no longer the only — or, for an EU manufacturer, necessarily the most relevant — path to CVE-issuing capability.

This post has two jobs: explain what actually changed with ENISA's CVE Root expansion, and correct a conflation we've seen repeatedly (including in our own coverage) — that getting a CVE ID assigned has anything to do with satisfying your CRA Article 14 reporting obligation. It doesn't. They are two unrelated processes that happen to both involve the word "vulnerability" and both involve ENISA.

What actually happened, in order

"Root" in CVE Program terminology is a coordination layer, not a database — a Root trains and supports the CNAs under its scope and makes sure they follow CVE Program rules when they assign identifiers. Before November 2025, any EU organization that wanted to become a CNA did so under MITRE's oversight (MITRE remains the CVE Program's original Top-Level Root and still runs cve.org). Now an EU entity — a vendor, a national CSIRT, a research group — can become a CNA under an EU-governed Root instead, without leaving the CVE Program or losing interoperability with the global CVE database. ENISA describes its role as identifying, onboarding, and supporting the CNAs in its scope and ensuring they follow the CVE Program's rules — training and coordination, not a parallel numbering system.

How you'd actually become a CNA — under either Root

The requirements are set by the CVE Program itself, not by whichever Root you land under: a public vulnerability disclosure policy, a public source where you publish new vulnerability disclosures, and agreement to the CVE Terms of Use. There's no fee and no contract — CNAs volunteer their own capacity because it's in their interest to control their own numbering and disclosure timing. In practice this means contacting the relevant CNA coordination team, filling out a registration form, attending an onboarding session, and demonstrating you can create correctly formatted CVE record entries from sample data before you're granted scope.

For most small and mid-sized SaaS teams, this is the part worth being honest about: becoming your own CNA only makes sense if you're regularly assigning CVEs across a product line and want control over disclosure timing. If you ship one product and expect to report a handful of vulnerabilities a year, working with an existing CNA — including GitHub's, if your code lives there, or a vendor umbrella CNA — is simpler than running your own onboarding. The ENISA Root expansion doesn't change that calculus; it just means that if you do decide to apply, an EU-governed Root is now a real option alongside MITRE's.

The part that actually matters: a CVE ID is not a CRA Article 14 report

Here's the conflation. CRA Article 14 requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT through the Single Reporting Platform (SRP), established under Article 16 — an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a corrective measure becoming available (or within one month of the incident notification for severe incidents). That obligation becomes legally enforceable on September 11, 2026 — not June 11, as one of our own earlier posts in this series states; that was a mix-up with the separate June 11, 2026 application date for Chapter IV's conformity-assessment-body notification rules (Articles 35–51), a different part of the CRA entirely. We can't edit that older post directly under our current publishing setup, but treat the "June 11, 2026" date in it as wrong — every other Article 14 post in our series, and every primary source we checked for this one, confirms September 11, 2026.

Getting a CVE ID assigned — whether via MITRE, via GitHub, or via a CNA under ENISA Root — establishes an identifier for a vulnerability. It does not submit anything to ENISA's Single Reporting Platform, does not start or stop your 24-hour clock, and does not satisfy any part of Article 14. A vulnerability can have a CVE ID and never trigger an Article 14 report (most CVEs are not actively exploited). Conversely, you can owe ENISA a 24-hour early warning for an actively exploited vulnerability before a CVE ID has been assigned at all — the report doesn't wait on the identifier. If your incident-response runbook treats "we filed for a CVE" as a checkbox that satisfies your CRA reporting duty, it's wrong, and worth fixing before September.

For the actual reporting mechanics — what the 24h/72h/14-day submissions must contain, who your national CSIRT contact is, and how this differs from NIS2's incident-reporting track — see our dedicated posts linked below rather than this one; we're not duplicating that content here.

The Single Reporting Platform's own readiness is a separate open question

ENISA's own SRP page confirms the platform is scheduled to go live on September 11, 2026, coinciding with the Article 14 application date, with a testing period beforehand. As of the most recent independent tracking we found, the platform was not yet operational and functional/security testing was still underway, with no published fallback procedure if the launch slips past the deadline. That's ENISA's execution risk, not yours — but the guidance from CRA compliance trackers is consistent: the 24-hour clock starts when you become aware of an actively exploited vulnerability, regardless of whether the platform is live that day. Don't build a compliance plan that assumes the SRP will be ready and reachable on day one. Identify your national CSIRT contact now, build the internal detection and escalation process independent of the platform, and treat SRP registration as something to complete the moment ENISA opens it — not something to wait on.

Does the "EU Root vs. MITRE Root" distinction matter beyond optics?

Honestly, only partly. The CVE Program is still one global database with one numbering scheme; a CVE-2026-XXXXX ID assigned under ENISA Root is fully interoperable with one assigned under MITRE Root, and MITRE remains a peer Root in the same Council of Roots governance structure ENISA just joined — this isn't a fork or a competing registry. What changes is who trains and coordinates your CNA if you become one: an EU body you can reach through EU institutional channels, rather than a US-government-funded nonprofit operating under a US federal contract. For a manufacturer already building a CLOUD Act risk assessment for other parts of their stack, that's a genuine, if modest, reduction in the number of US-anchored dependencies in your compliance chain — not a reason to rearchitect anything, but a reasonable tie-breaker if you were already planning to apply for CNA status and the choice of Root was otherwise arbitrary.

Same-week checklist

• If any of your incident-response documentation says "CVE assignment satisfies our vulnerability reporting obligation," fix that sentence — CVE IDs and CRA Article 14 reports are unrelated processes.
• Confirm you know your national CSIRT contact for Article 14 reporting — don't wait for the SRP to identify it.
• If you're already a CNA under MITRE Root, no action is required — your CVEs remain valid; ENISA Root is a new option, not a replacement requirement.
• If you're considering applying to become a CNA for the first time, and you're an EU-established manufacturer, ask about ENISA Root during the application — it's now a real alternative, not just MITRE by default.
• Build your 24-hour actively-exploited-vulnerability detection and escalation path assuming the SRP might not be live on September 11 — the clock doesn't wait for the tooling.

See also

For the full Article 14 reporting mechanics — the 24h/72h/14-day timeline, what each submission must contain, and a compliance checklist — see CRA Article 14: The 24-Hour ENISA Serious-Incident Alert and CRA Article 14 Compliance Finale: The September 2026 Vulnerability Reporting Checklist. For the upstream vulnerability-handling process obligations under Article 13, see CRA Article 7: Vulnerability Handling Requirements. For our earlier overview of the reporting regime — note the entry-into-force date in that post is incorrect and should be treated as superseded by the September 11, 2026 date confirmed here — see EU CRA Vulnerability Disclosure: SaaS Developer Guide.

Primary sources: ENISA — Stepping up our role in Vulnerability Management: ENISA Becomes CVE Root (Nov 20, 2025) · ENISA — New CVE Numbering Authorities Under ENISA Root (May 6, 2026 cohort) · ENISA — ENISA scales up its role in the CVE Program (Aug 6, 2026 cohort, NCIA/AISLE, 20 CNAs) · ENISA — Single Reporting Platform (SRP) · European Commission — Cyber Resilience Act: Reporting obligations · cyberresilienceact.eu — With Reporting Due September 11, 2026, ENISA's Single Reporting Platform Is Still Not Live · Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 14, 16, and 71.