CVE Numbering Authority (CNA) rules, explained: how CVE IDs actually get assigned

The rules describe a layered structure. Roots oversee and administer a set of CNAs; Top-Level Roots (TL-Roots) sit above Roots in the hierarchy and can set additional rules for everyone beneath them (which "MUST NOT conflict with the primary CNA Operational Rules"); ordinary CNAs assign CVE IDs within their own agreed Scope Definition; and CNAs of Last Resort (CNA-LRs) exist specifically to catch overflow and first-refusal cases — the rules note they "typically have broader scopes than CNAs" and "MAY limit effort to optimize service given resource constraints, for example, by not notifying Suppliers who are not CNAs." MITRE itself occupies multiple roles at once: per the rules, "MITRE currently acts as the Secretariat, a TL-Root, and a CNA-LR."

Every CNA operates inside a documented Scope Definition — "CNAs MUST develop, document, and operate within a Scope Definition that describes the types of Vulnerabilities for which the CNA will assign CVE IDs" (3.1.1), approved by the CNA's Root or TL-Root and published in the Program's List of Partners. The rules give model phrasings a Supplier CNA can use: "All of a Supplier's Products," a named product list, a covered-and-excluded list, or explicit End-of-Life (EOL) product coverage. Scope disputes escalate through the Root/TL-Root/Council of Roots chain and, if unresolved, to the CVE Board itself (3.1.10).

CVE ID assignment follows "a 'right of first refusal' model" (4.2.1): the CNA with the most appropriate scope gets first opportunity. For a vulnerability that is already Publicly Disclosed, three triggers hand assignment elsewhere — the scoped CNA preemptively declines, explicitly declines within 72 hours, or simply doesn't respond within 72 hours — at which point "an appropriate Root MUST make a Vulnerability determination" and direct another CNA or CNA-LR to assign "no later than 72 hours after becoming aware of the first refusal." For vulnerabilities not yet public, the rules instead route disagreement through the Program's formal dispute process (4.2.1.3) rather than a timed handoff.

Every CVE Record also has substantive content rules (Clause 5): it must name at least one affected product, classify the vulnerability type (the rules recommend using CWE for this), carry a prose description, and cite at least one public reference that isn't the CVE Record itself — "A CVE Record MUST NOT be the first Public Disclosure of a Vulnerability" (5.3.1).

The rules explicitly acknowledge that mechanical application isn't always possible: "CNAs are expected to exercise discretion and judgment, especially when making complicated Vulnerability determination (4.1) and CVE ID assignment (4.2) decisions" (4.4). When a CNA genuinely cannot reach a clear call after good-faith effort, the guidance tilts toward inclusion, not exclusion: the CNA "SHOULD err on the side of assignment and SHOULD assign CVE IDs," on the reasoning that doing so "allows CVE users to identify and discuss the 'Vulnerability-like' issue." Separately, the rules draw hard lines on what is never a CVE-worthy "vulnerability": general-purpose deliberately malicious code (4.1.8), a product simply reaching End-of-Life (4.1.13), and routine dependency updates — "updating a library to address a Vulnerability in that library MUST NOT be determined to be a new Vulnerability in a Product that uses the library" (4.1.12) — are all explicitly out of scope.

CVE Records are published under the CVE Program's own Terms of Use (cve.org/Legal/TermsOfUse), catalogued by SPDX under the identifier cve-tou. The grant is broad — a perpetual, worldwide, royalty-free, irrevocable copyright licence to reproduce, create derivative works of, publicly display and distribute the CVE List — conditioned on reproducing MITRE's copyright designation and the licence terms in any copy. This guide quotes the SPDX catalogue's summary of that grant rather than reproducing the full legal text; consult cve.org's own Terms of Use page for the authoritative wording before relying on it for redistribution decisions.

Trade press, not a primary CVE Program governance statement, is the source for this paragraph: in April 2025, a lapsing CISA funding contract briefly put the entire CVE Program's continuity in question before CISA exercised an 11-month contract extension with MITRE; the scare also prompted a group of CVE Board members to launch the independent CVE Foundation as a possible alternative governance path. As of this guide's research (October 2026), MITRE continues to operate the Program as Secretariat/TL-Root/CNA-LR under CISA sponsorship, and funding has reportedly been placed on steadier footing — but this guide has not verified the current contract terms against a primary CVE Program or CISA document, and treats the long-term governance structure as unsettled rather than citing a specific end-state.

The CNA Operational Rules govern identifier assignment, not disclosure policy itself — the rules are explicit that "the CVE Program itself does not follow or require a specific Vulnerability disclosure policy" (3.2.6). A PSIRT handling inbound reports still needs its own coordinated disclosure process, which is where ISO/IEC 29147 and 30111 and the FIRST PSIRT Services Framework apply, alongside a published vulnerability disclosure policy and, for CRA-scoped products sold into the EU, the 24-hour/72-hour CRA reporting obligations that run on a separate clock from anything in the CNA rules above. Becoming a CNA is a separate, voluntary step from any of those obligations — a Supplier can run a fully compliant PSIRT and disclosure program without ever becoming a CNA, by relying on a Root or CNA-LR to assign CVE IDs instead.