CVE Numbering Authority (CNA) Explained: Scope, Lifecycle, IDs

What a CNA Actually Is

A CVE Numbering Authority is an organisation authorised by the CVE Program to assign CVE identifiers to vulnerabilities in a defined scope and to publish the corresponding CVE records. The CVE Program is sponsored by the Cybersecurity and Infrastructure Security Agency (CISA) and operated by MITRE under that sponsorship. Several hundred CNAs participate in the programme as of the time of writing, ranging from major operating system vendors and cloud providers to open-source maintainers, bug bounty platforms, sector-specific coordinators, and national CSIRT teams.

The point of the programme is decentralisation. A single central authority cannot keep up with the volume of vulnerabilities discovered each year across every product on the internet, and the bottleneck creates exactly the kind of disclosure backpressure that helps attackers and hurts defenders. By federating the authority to issue identifiers across hundreds of organisations who each cover a defined slice of the ecosystem, the CVE Program scales the issuance step without losing the global identifier namespace CVE-YYYY-NNNN that every downstream system depends on.

Each CNA operates inside a published scope statement. The scope names which products, projects, or sectors the CNA is authorised to assign IDs for, and the rules that govern the no-go cases (out-of-scope products, duplicate assignments, disputed records). When a CNA assigns an ID to a vulnerability inside its scope, the ID becomes the canonical reference everywhere downstream: NVD, scanner content feeds, SIEM correlation rules, VM platform inventories, advisory mailing lists, and the regulatory disclosures that increasingly cite CVE IDs by reference.

CNA vs MITRE vs NVD vs CISA

The CVE ecosystem has four roles that get conflated constantly. They are different organisations doing different jobs at different stages of the same lifecycle. Untangling them is the first step to operating against the system rather than past it.

Read together: the CVE Program defines the namespace and partner rules, CNAs assign and publish the individual records, NVD enriches the records for severity and CPE downstream, and CISA sponsors the programme and runs the exploited-in-the-wild flag on top. A vulnerability that is missing a CVE ID is invisible to all of the downstream layers, which is why the CNA assignment step matters enough to be worth understanding rather than ignoring.

The CNA Hierarchy: Top-Level Roots, Roots, CNAs, CNA-LRs

The CNA partner programme is structured as a hierarchy rather than a flat list. Understanding the layers tells a programme who to file a CVE request through, and which CNA to escalate to when an assignment is stuck or disputed.

The CVE ID Lifecycle: RESERVED, PUBLIC, REJECTED, DISPUTED

A CVE ID is not a single state; it has a small lifecycle of its own. Reading the state correctly is the difference between a vulnerability management decision that is defensible and one that gets re-litigated during audit. The four states below are the ones an operator sees in practice, plus the auxiliary states the CVE record format supports.

The CVE record format also supports auxiliary fields that capture more granular state: CONFIRMED (the CNA has corroborated the report), VERIFIED (an independent party has reproduced it), UNVERIFIED (the evidence has not yet been corroborated). Those annotations are useful in advisory ecosystems but the four-state model above is what most VM programmes need to operate cleanly.

The CVE Record Format and CVE Services API

The CVE Program publishes a versioned JSON schema for the CVE record format and runs the CVE Services API for CNA-side automation. CNA Services 5 is the current major version of the schema at the time of writing, with a richer affected-products model, structured references, and an improved description container compared to the legacy 4.x format. Any CNA producing records at scale interacts with the schema rather than with web forms.

The record format is structured around a small set of containers. The CNA container holds the CNA-published description, affected-products list, references, and metric data. The ADP container (more on this below) holds annotations from authorised data publishers other than the originating CNA. Affected-products entries describe the vendor, product, default-status (affected, unaffected, unknown), and version ranges using semantic identifiers. References include URLs to advisories, patches, third-party analysis, and the original report. Metric data carries CVSS Base scores from the CNA, with NVD providing its own enrichment downstream.

For an internal product security team that becomes a CNA, the CVE Services API is the integration surface. Issuing an ID, publishing a record, updating affected-products, and rejecting an ID all happen via the API. Most CNAs run a thin internal service that listens to the disclosure pipeline and emits CVE Services calls when an advisory reaches the publish state. Open-source clients exist for the API and for the schema validation step. The schema itself is canonical: any CVE record that does not validate against the published schema cannot be published, which is the load-bearing reason the format survived the move from 4.x to 5.x without breaking the global namespace.

ADP: Authorized Data Publishers

The Authorized Data Publisher (ADP) role is a newer addition to the CVE programme. An ADP is an organisation authorised to add structured annotations to existing CVE records without being the originating CNA. ADP additions live in their own container on the record so the CNA-published content and the ADP-published content stay distinguishable.

CISA was the first ADP, with authority to add KEV-related annotations and structured advisory metadata to CVE records on top of the originating CNA content. The ADP role exists because the CNA programme recognised that downstream parties (governments, sector regulators, patch coordinators, EPSS publishers) often have legitimate, authoritative content to add to a CVE that the originating CNA cannot or should not be the one to publish.

For consumers of CVE data, the ADP container is something a modern VM tool reads alongside the CNA container. A CVE record can carry both the CNA-published description and the ADP-published exploitation note from CISA. Reading both is the difference between a CVE-centric posture (only the CNA view) and a multi-source posture (CNA plus authorised governmental annotations) that catches signals like KEV additions earlier in the lifecycle.

When to Become a CNA

Most enterprises do not need to become a CNA. Most should file the rare external-facing vulnerability they discover through CNA-LR (MITRE) or through the bug bounty platform CNA they already use. The decision to apply to the partner programme is structural: it makes sense when the organisation produces software that other parties consume, when the volume of disclosures is more than a handful per year, and when the disclosure timeline coordination is already part of the product security operating model.

The clear case for becoming a CNA is a vendor product organisation. If your product is consumed by external customers and security researchers report vulnerabilities directly to your security team, being a CNA gives you scope authority over your own products: you assign the CVE, you control the description, you publish the affected-products list, and the disclosure timeline is yours to coordinate rather than yours to chase upstream. The cost is the operational obligation to publish defensibly, handle disputes, and maintain the embargo discipline the programme expects.

The unclear case is an internal-only enterprise where the security team finds vulnerabilities in third-party software during pentests and authenticated scans. The right path here is almost always to file with the affected vendor (if they are a CNA), with the relevant Root CNA, or with CNA-LR if no other path exists. Becoming a CNA to assign IDs to vulnerabilities you found in someone else's product is not how the scope model works; the scope statement would not authorise it.

For open-source maintainers, the path varies by ecosystem. Several Root CNAs exist specifically for ecosystem-wide assignment (covering broad swaths of npm, PyPI, Maven, Go, Rust, and others). Joining the relevant Root CNA is usually a faster path than applying as an independent CNA, because the Root absorbs the partner-programme administration and lets the maintainer focus on disclosure handling.

The CNA Application Process at a Glance

The CNA partner programme has a published application path. The path varies slightly by Root CNA but the structural steps below cover what an applicant should expect.

CNA Operating Discipline: Embargo, Coordination, Publication

A CNA that publishes records badly does more harm than one that does not exist. The operating discipline of a working CNA has three pillars: embargo, coordination, and publication. Each one fails in distinctive ways when the discipline slips.

Embargo is the discipline of not leaking the existence of a vulnerability before the publication date agreed with the affected parties. A CNA that reserves an ID and discusses it publicly before the embargo expires hands attackers a window. The defence is operational: ID reservations are private until the publish event, draft records sit on the CNA-side pipeline rather than in shared chat, and the coordinated-disclosure timeline is the document the CNA enforces, not the one the CNA negotiates each time.

Coordination is the discipline of working with the affected vendor (if the CNA is a third party), with the reporter, with downstream consumers, and with adjacent CNAs whose scope might overlap. Coordination is where most CNA disputes happen, and where the Root CNA escalation path matters: if a subordinate CNA is unresponsive or refuses to assign, the reporter has a documented path to escalate to the Root rather than going directly public.

Publication is the discipline of producing a record that downstream systems can consume cleanly: a description that names the weakness without leaking exploitation details, an affected-products list with structured version ranges, references to the patch and to any third-party analysis, a CVSS Base score from the CNA (with the ADP layer adding KEV or other annotations as warranted), and a CWE mapping at the class level. A clean record passes through NVD enrichment without rework. A messy record produces NVD disputes downstream, which the CNA then has to respond to in public.

CNAs in Vulnerability Management Operations

For the vulnerability management function, the CNA layer is mostly invisible most of the time. The queue runs on CVE IDs the way drivers run on traffic signals: as long as the system works, you do not think about the wiring. The wiring becomes visible exactly when something goes wrong: a missing ID for a real-world vulnerability your scanner is not picking up, a REJECTED CVE that is still firing in your feed, a DISPUTED record that needs adjudication before triage, an NVD enrichment lag that leaves a PUBLIC CVE without a CVSS score for weeks, or a CNA scope ambiguity where two vendors disagree on which of them owns the disclosure.

The operating record matters. Every finding in a programme that traces to a public CVE should carry the CVE ID as a structured field, plus the originating CNA reference, plus the CNA record state (PUBLIC, REJECTED, DISPUTED). Without those three on the record, a triage analyst cannot tell the difference between a real CVE-backed finding, a stale REJECTED reference firing through a scanner feed, and a DISPUTED record that needs human adjudication. With the three on the record, the triage decision tree collapses. Pair the discipline with the scanner result triage workflow and the vulnerability prioritisation workflow so the CNA-record state feeds the triage call rather than sitting in a different system.

Internal product security teams interact with CNAs differently. The discipline is bidirectional: any finding the team produces during product testing that is going to be disclosed externally needs a CNA decision on whether the team itself files (because it is a CNA), files through CNA-LR (because it is not), or coordinates with an upstream CNA (because the affected component is not the team's product). Recording the CNA decision on the engagement record at the point of disclosure (rather than recreating it during a regulator request) is the small recordkeeping discipline that makes the audit conversation easy.

Where CNA Output Maps to Compliance Frameworks

None of the major frameworks make the CNA process itself a control. Several of them either expect CVE references in evidence or require a working vulnerability disclosure programme, both of which sit adjacent to the CNA process. Mapping the relationship explicitly in the policy keeps the CNA layer in the audit pack rather than adjacent to it.

Common CNA-Adjacent Failure Modes

Most CNA-adjacent failures are not CNA failures; they are operating failures inside programmes that did not understand the layer. The patterns below show up most often in audits and incident reviews.

Capturing Defensible CNA-Aware Audit Evidence

The audit conversation about CNA-derived evidence reduces to a small set of artefacts. Build the set as a side effect of running the queue, and the audit collapses into a query rather than a multi-team scramble.

The minimum evidence set has six artefacts. The first is the CVE ID field on every CVE-backed finding in the operating inventory, populated at intake. The second is the CNA-record state captured at the point of triage (PUBLIC, REJECTED, DISPUTED) so a re-read of the queue weeks later can distinguish a valid finding from a stale REJECTED one. The third is the timestamped lifecycle of each finding (detected, prioritised, assigned, remediated, retested, closed) with the named user who performed each transition, so the per-finding work history is reconstructible. The fourth is the CVE-by-source rollup over the audit window, which lets an auditor see the inflow shape across CNA, internal pentest, and scanner sources. The fifth is the framework mapping (ISO 27001 8.8, SOC 2 CC7.1, PCI DSS 6.3.3, NIST SP 800-53 RA-5/SI-2, NIST CSF 2.0) so the evidence pack is portable across audits. The sixth is the disclosure record for any vulnerability the team itself reported externally, capturing the CNA path taken and the published CVE identifier.

SecPortal's findings management feature tracks each finding with a CVSS 3.1 vector, owner, evidence, and remediation status, and supports structured fields and tags so the per-finding CVE identifier and CNA state can be carried alongside the severity vector. The activity log keeps the timestamped chain of state changes by user across findings, engagements, scans, documents, comments, and team changes, with plan retention of 30, 90, or 365 days. The document management feature stores the CNA scope statement, the disclosure policy, and any per-CVE coordinated-disclosure timeline documents alongside the engagement record so the policy lives with the operational record. The compliance tracking feature maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST and exports the evidence pack as CSV. None of those features assign CVE identifiers or interact with the CVE Services API; SecPortal is not a CNA, and the platform does not file CVE requests on the team's behalf. What the platform provides is one record on which the CVE ID, the CNA state, the severity vector, the owner, the lifecycle, and the framework mapping all live so the audit query reads from the same source the operator runs from.

CNA in the Vulnerability Vocabulary Cluster

CNA is the upstream layer the rest of the public-vulnerability vocabulary depends on. Reading the layers in order makes the cluster legible. Our CVSS scoring explained guide covers the severity axis. Our EPSS score explained guide covers the likelihood axis. Our KEV catalog guide covers the observed-exploitation axis. Our CWE explainer covers the weakness-class axis. Our SBOM guide covers the component-inventory axis. Our VEX guide covers the exploitability-filter axis. Our SLSA explainer covers the build-provenance axis.

The CNA layer is the one that makes the others addressable. CVSS scores are attached to CVE records; EPSS estimates probabilities of CVE exploitation; KEV flags CVEs known to be exploited; CWE maps classes onto CVEs; SBOM lists components whose vulnerabilities reference CVEs; VEX expresses exploitability against specific CVEs; SLSA produces build provenance that gets cited in CVE references. Take the CNA layer away and the rest of the vocabulary loses its keying. That is why the CNA process, invisible most of the time, is one of the most load-bearing pieces of the public-vulnerability ecosystem.

Run a CNA-Aware Programme on a Single Record

CNA-aware operations are mostly a recordkeeping problem in disguise. The CNA hierarchy is public, the CVE record format is open, the lifecycle states are well-defined, and the framework integration is well-documented. What stops most programmes from getting clean CVE-and-CNA evidence is that the per-finding CVE values, the CNA state, the lifecycle audit trail, the framework mapping, and the disclosure record all sit on different records, so producing the evidence pack means reconciling four or five sources at audit time.

SecPortal is built around a single engagement record: findings management with CVSS 3.1 calibration and structured fields for the CVE ID and CNA state, the activity log for the timestamped chain of state changes across findings, engagements, scans, and team changes, document management for the disclosure policy and CNA scope statement, compliance tracking with ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST mappings and CSV export, external scanning and authenticated scanning so CVE-keyed scanner output flows into the same record, and AI report generation when leadership wants the executive summary.

None of these features make SecPortal a CNA, file CVE requests, or interact with the CVE Services API. The CNA decision and the disclosure path are yours to make. What the platform does is keep the CVE ID, the CNA state, the lifecycle, the evidence, the framework mapping, and the disclosure record on the same record so the audit conversation collapses into a query rather than a multi-team scramble. Pair the discipline with the vulnerability disclosure programme workflow and the control gap remediation workflow so the CNA-aware queue feeds the framework-mapped evidence loop.

Wider Reading

For programmes building CNA awareness into the operating model, the adjacent reading below covers the connected layers without duplicating ground.

• CISA KEV catalog vulnerability management guide for how the BOD 22-01 catalog keys exploitation evidence to CVE IDs.
• EPSS score explained for the likelihood model that estimates CVE exploitation probabilities over a thirty-day window.
• CVSS scoring explained for the severity decomposition that the CNA records and NVD enriches.
• Common Weakness Enumeration explained for the weakness-class axis that maps onto CVE records via the CNA-published CWE field.
• SBOM guide for how component inventories cite CVE IDs against listed components.
• VEX guide for the per-CVE exploitability filter that pairs with SBOM in supply-chain operations.
• SLSA framework explained for the build-provenance scaffold that supplies evidence cited in modern CVE references.
• Vulnerability disclosure programme setup guide for the VDP-side discipline a CNA application depends on.
• Vulnerability management program guide for the queue discipline that consumes CVE-keyed advisory inflow.
• Vulnerability management programme maturity model for the maturity grid that situates the CNA-ingest workflow on the discovery dimension.