What a CVE Numbering Authority actually is
A CVE Numbering Authority (CNA) is an organization the CVE Program authorizes to assign CVE identifiers and publish CVE records for vulnerabilities within a defined scope — most often its own products, an open-source ecosystem it stewards, or vulnerabilities reported through its research or bug bounty programs. Instead of MITRE assigning every identifier by hand, each CNA receives blocks of CVE IDs and issues them directly, which is what lets the program keep pace with tens of thousands of new vulnerabilities a year. As of 2024–2025 there are more than 400 CNAs operating across roughly 40 countries, arranged in a federated hierarchy under two Top-Level Roots: MITRE and CISA.
That is the summary an AI Overview will give you. Here is what it can't show you: the shape of the hierarchy that decides who is allowed to number what, the routing logic you actually follow to get a CVE assigned to something you found, and the speed and conflict-of-interest tradeoffs each route carries. The diagrams, decision table, and live CVE lookup below turn "CNAs assign CVEs" into something you can act on.
The federated CNA hierarchy at a glance
The CVE Program is not flat. Two Top-Level Roots govern the whole structure, Roots recruit and manage authorities beneath them, and the CNAs at the bottom do the day-to-day assignment. A CNA of Last Resort catches everything no other CNA covers.
The program began in 1999 with MITRE assigning every CVE alone. As disclosure volume exploded, that centralized queue became a bottleneck — vulnerabilities waited weeks or months for an identifier. The federated CNA model exists to remove that queue by pushing assignment authority out to the organizations closest to each vulnerability, while keeping MITRE and CISA as the governing Top-Level Roots that resolve conflicts and hold the authoritative record.
Which CNA assigns your vulnerability?
The single most useful thing to know is which CNA covers a given finding, because that determines who you report to, how fast a CVE lands, and how trustworthy the initial data will be. This table maps the common CNA types to the scope they cover and when each is the right target.
| CNA type | Examples | Scope it covers | Typical speed | When it's your target |
|---|---|---|---|---|
| Software vendor | Microsoft, Apple, Cisco, Oracle | Vulnerabilities in that vendor's own products | Same-day possible | The affected product is theirs and they are a CNA |
| Open-source ecosystem | GitHub, Apache Software Foundation, Python | Projects hosted in / stewarded by that ecosystem | Days to weeks | Flaw is in an open-source project the vendor doesn't self-cover |
| Security research firm | Tenable, Qualys, Trend Micro ZDI | Vulnerabilities their researchers find or receive | Often same-day | You disclosed to them, or the vendor isn't a CNA |
| Bug bounty platform | HackerOne, Bugcrowd | Findings submitted through their programs | Coordinated with client | You found it via a bounty program |
| Government / ICS | CISA (incl. ICS-CERT) | US gov, critical infrastructure, control systems, medical devices | Urgent for active threats | Industrial/embedded systems, or a national-interest flaw |
| National CERT | JPCERT/CC, CERT-In | Vulnerabilities within that country's remit | Varies | Regional software or vendor coordination |
| CNA of Last Resort (MITRE) | MITRE | Anything no other CNA's scope covers | Slower (manual queue) | Small vendor not a CNA and no ecosystem fits |
Which should you use? Report to the vendor's own CNA if one exists — that path is fastest and produces the most accurate affected-versions data. If the vendor is not a CNA, fall to an ecosystem CNA (GitHub covers a large share of open-source), then a research-firm CNA, and only reach for MITRE as the CNA of Last Resort when nothing else applies.
Look up any CVE and see which CNA assigned it
Every published CVE record names its assigning CNA in the metadata. Use the lookup below to pull a live record — check the "Assigner" field to see exactly which authority numbered it, then compare its description against the NVD enrichment.
The five real-world assignment routes
Vulnerabilities reach a CVE identifier along a handful of well-worn paths. The route determines the timeline — from same-day for a vendor patching its own bug to an accelerated few days for something already being exploited.
Route 1 — Direct vendor assignment. The vendor discovers a flaw in its own software, assigns a CVE internally as a CNA, and publishes the CVE alongside the patch. This is the fastest path and enables same-day disclosure.
Route 2 — Researcher to vendor. A researcher privately discloses to the affected vendor, which (as a CNA) confirms the flaw, assigns the CVE, and releases a patch. Typical timeline: 30–90 days.
Route 3 — Researcher to a CNA (vendor is not a CNA). The researcher discloses to a research CNA (Tenable, Qualys) or ecosystem CNA (GitHub). That CNA contacts the vendor, assigns the CVE, and coordinates disclosure. Typical timeline: 30–90 days.
Route 4 — Discovered in the wild. A vulnerability under active exploitation is reported to a CNA or vendor, which assigns a CVE urgently — often within days — while patch development is accelerated.
Route 5 — Public disclosure and aggregators. When a flaw surfaces in a public GitHub issue, mailing list, or advisory, an aggregator-type CNA numbers it once the disclosure is already public.
The CNA of Last Resort — the safety net most people miss
Not every vulnerability falls inside a CNA's scope. A small vendor may not be a CNA; academic or limited-use software may match no ecosystem; some hardware and international software has no dedicated authority. For exactly these gaps, the program designates a CNA of Last Resort (CNA-LR). MITRE is the primary CNA-LR and will assign a CVE for anything outside every other CNA's scope. CISA's ICS team serves as the CNA-LR for industrial control systems and medical devices. If you have a legitimate finding and cannot identify any CNA that covers it, the CNA-LR is your guaranteed path to an identifier — you are never actually stuck.
The CNA designation process
Becoming a CNA requires meeting the program's criteria:
Technical expertise — a demonstrated understanding of vulnerability disclosure, CVE record requirements, and vulnerability assessment.
Infrastructure and processes — systems for receiving disclosures, validating that a flaw meets CVE requirements, assigning identifiers, maintaining metadata, and coordinating with other CNAs.
Trusted reputation — a track record of responsible disclosure and demonstrated commitment to security.
Scope definition — a clearly stated scope (which products, projects, or sectors the CNA will number). Organizations apply through a Root or Top-Level Root, which evaluates them; active CNAs must maintain their processes or risk losing status.
CNA responsibilities and requirements
CNAs operate under the CVE Program's published rules:
Vulnerability assessment — verify a flaw meets CVE requirements (it exists in publicly available software or hardware, represents a real security weakness, and is in scope) before assigning.
Timely assignment and record population — assign and publish records promptly after confirming eligibility so downstream databases can react.
Accurate metadata — provide a description, affected products and versions, impact context, references to advisories and patches, and, where available, an initial CVSS score.
Coordinate with other CNAs — when a flaw spans multiple vendors, coordinate to avoid duplicate identifiers and conflicting descriptions.
Maintain data quality — the assigning CNA is responsible for initial accuracy, even though NVD and MITRE can enrich or correct records later.
Follow responsible disclosure — avoid publishing before vendors have had reasonable time to patch, typically negotiated within a 0–90 day window.
Coordination between hundreds of CNAs
With 400+ CNAs operating globally, coordination prevents duplicate identifiers, conflicting descriptions, and confusion over which CVE means which flaw. The mechanisms:
- CVE working groups align CNAs on assignment standards and policy.
- CNA communication channels let authorities flag pending assignments and coordinate on cross-vendor flaws before publication.
- MITRE as arbiter resolves disputes when multiple CNAs claim the same vulnerability and maintains the authoritative record.
- Scope rules determine which CNA owns a given assignment based on the affected products.
Where the model shows strain
The federated design is fast, but it has real tradeoffs worth naming:
Vendor bias. A vendor that is its own CNA controls the initial description and severity of flaws in its own products, which can lead to downplayed severity or delayed assignment. NVD enrichment and third-party disputes are the counterweight.
Variable standards. Different CNAs apply assignment criteria unevenly, creating inconsistency across the CVE corpus.
Speed over review. Rapid assignment sometimes ships CVEs with thin vetting, producing questionable or later-rejected entries.
Why this matters for your vulnerability management
Understanding the CNA landscape has concrete payoffs. Vendors that are CNAs can assign CVEs immediately, so their advisories tend to appear faster and with better affected-versions data — while flaws in non-CNA software may lag until another authority picks them up. Knowing which CNA owns a product helps you predict when a fix will land and route your own disclosures correctly. And when you read a CVE, checking the assigning CNA in the record tells you how much to trust the initial severity before NVD finishes its analysis.
Conclusion
CVE Numbering Authorities decentralize vulnerability identification so the CVE Program can keep pace with a flood of disclosures without a single bottleneck. A federated hierarchy — Top-Level Roots (MITRE and CISA), Roots, 400+ CNAs, and MITRE as the CNA of Last Resort — decides who numbers what, while MITRE holds the authoritative record. For defenders, the practical skill is reading that structure: knowing which CNA covers a product tells you how fast a CVE will appear, how reliable its first description is, and where to send a vulnerability you discover yourself.