NIST Just Gave Up on Rating Most New Vulnerabilities—The National Vulnerability Database Became a Triage Queue

For two decades, the U.S. National Vulnerability Database has been the closest thing the industry has to a universal source of truth for software flaws. CVE identifiers come from MITRE, but the context that makes a CVE actionable—CVSS scores validated by a second pair of eyes, Common Platform Enumeration matches against specific product versions, weakness classifications, reference links cleaned of noise—has come from NIST staff at the National Institute of Standards and Technology. Every major vulnerability scanner, every SIEM correlation rule, every third party risk score, and every regulatory compliance framework from PCI DSS to FedRAMP depends on that enrichment pipeline.

That pipeline has formally narrowed. NIST announced on April 17, 2026 that effective April 15, the NVD will only enrich vulnerabilities that meet one of three criteria. Everything else goes into a new status bucket called "Not Scheduled."

The Numbers Behind the Decision

NIST's own figures explain the retreat. The agency enriched more than 42,000 CVEs in 2025—an unprecedented annual volume. Submissions in early 2026 are running 263% higher than the comparable period a year earlier, and the trajectory continues to accelerate. The NVD has been visibly struggling since early 2024, when unenriched entries began piling up in public view. The official acknowledgment now ratifies what the backlog already revealed.

Under the new policy, NIST will only enrich a CVE if one of the following is true:

• The vulnerability is already on CISA's Known Exploited Vulnerabilities (KEV) catalog—the authoritative list of flaws observed in active attacks.
• The vulnerability affects software used by U.S. federal government systems.
• The vulnerability involves "critical software" as defined by Executive Order 14028 on improving the nation's cybersecurity.

Every other CVE—which is to say the overwhelming majority—inherits only whatever scoring and metadata the original CVE Numbering Authority provided. The enrichment that defenders have been pretending is authoritative will simply not exist for most of what is published.

Why CNA Only Scores Are a Problem

CVE Numbering Authorities are the 400+ organizations licensed to assign CVE identifiers. Most of them are software vendors scoring their own products. The incentive problems are visible in every direction: vendors routinely under score severity to avoid reputational damage, over score severity to pressure customers into upgrades, miscategorize the affected component, or leave out the Common Platform Enumeration entries that let scanners match the CVE to specific installed software.

NIST's enrichment staff historically caught those errors. They rescored inconsistent CVSS submissions, normalized product identifiers across the database, and added the metadata that scanner vendors could not have produced on their own. Without that second pass, a CVE's published score becomes whatever the reporting vendor felt like putting on it. Two CVEs with identical real world severity can carry wildly different CVSS numbers depending on who submitted them.

For defenders running automated patch prioritization keyed to CVSS thresholds—which describes most enterprise vulnerability management programs—this introduces variance that cannot be resolved without manual review. The tool that was supposed to reduce manual review has started producing data that requires it.

The Volume Problem Was Structural

The 263% spike is not a one off. It reflects three durable shifts in the industry.

First, automation. Researchers now run AI assisted fuzzers and static analysis at scale across the open source ecosystem. Anthropic's research team documented finding a 27 year old vulnerability in 1,000 tries using a coordinated set of model calls. When one researcher can file dozens of valid CVEs per week, the submission pipeline fills faster than any human review team can drain it.

Second, the expansion of the CNA program. More vendors and more bug bounty platforms now assign CVEs directly, widening the contribution pool without widening the editorial review capacity. MITRE's CNA count grew from about 200 in 2022 to more than 400 by 2026. Each new CNA adds submission volume; none of them add enrichment throughput at NIST.

Third, budget. NIST's information security funding has been flat or declining in real terms since 2020. The agency asked for supplemental appropriations to scale NVD operations through 2025 and received partial funding that did not keep pace with submission growth. Congress's continuing resolution cycle made planning for sustained hiring impossible.

Who Actually Relied on NVD Enrichment

If you are running a commercial vulnerability scanner—Tenable, Qualys, Rapid7, Wiz, Lacework, or any of their peers—your product consumes NVD feeds as a primary input. The vendor layers its own research on top, but the foundation of the CVE database in the scanner is the NVD's enrichment. The same is true for open source scanners like Trivy, Grype, and OSV-Scanner, and for every GRC tool that maps CVEs to compliance frameworks.

Compliance regimes that reference CVSS scores by threshold—such as PCI DSS's requirement that "high" severity findings be remediated within 30 days—have always depended on NIST's scoring being trustworthy and consistent. If the authoritative score for most new CVEs is whatever the reporting vendor chose to put on it, those compliance timelines become unstable. A CNA that scores its own flaws at CVSS 7.4 stays under the "critical" compliance threshold. A different CNA scoring identical behavior at CVSS 9.1 does not.

Incident responders pulling CVE context during an active investigation will also feel the gap. The CPE strings NIST used to add are what let a scanner correlate "we have this vulnerability" with "this specific product version is installed on this host." Without them, an analyst ends up reading the vendor advisory directly and doing the mapping by hand.

The Alternatives Filling the Gap

Multiple parallel databases have already started filling roles the NVD used to fulfill.

CISA's Known Exploited Vulnerabilities catalog has become the de facto "must patch" list for both federal agencies under Binding Operational Directive 22-01 and private sector programs that mirror the federal posture. KEV inclusion now carries more operational weight than NVD CVSS scores, because it encodes evidence of exploitation rather than theoretical severity.

The Exploit Prediction Scoring System (EPSS), maintained by FIRST, produces daily probability estimates for whether a given CVE will be exploited in the next 30 days. For teams that cannot patch everything, EPSS weighted prioritization has been a demonstrably better input than CVSS for several years. The NIST decision is likely to accelerate that shift.

The EU's upcoming European Vulnerability Database, operated by ENISA and scheduled to go live later in 2026, will duplicate much of the NVD's role for the European market. Commercial aggregators—VulnCheck, VulnDB by Risk Based Security, and Snyk's vulnerability intelligence feeds—have been adding NIST style enrichment behind paywalls for years. Their pitch just got stronger.

What Security Programs Should Do This Quarter

Practical adjustments for teams that relied on NVD enrichment:

• Shift prioritization logic from CVSS to KEV + EPSS. CVSS scores on the vast majority of new CVEs will not be NIST validated. KEV listing and EPSS probability give you exploit weighted signal instead of theoretical severity.
• Audit your compliance documentation. Any internal policy or contractual obligation that references "NVD CVSS score" without specifying a source of truth needs updating. Explicit fallback language for unenriched CVEs should be added.
• Validate your scanner's CVE ingestion. Ask your vendor where their data comes from for "Not Scheduled" CVEs and how they handle the absence of NVD enrichment.
• Request enrichment when it matters. NIST accepts requests at nvd@nist.gov to enrich specific low priority CVEs that are operationally critical to the requester's environment.
• Subscribe to CISA KEV updates. If you have not already automated the ingestion of KEV additions into your ticketing system, this is the quarter to do it.

A Public Good That Markets Are About to Price

The broader implication is that vulnerability enrichment was always a public good paid for by a public agency, quietly subsidizing the entire commercial vulnerability management industry. For decades, scanner vendors, GRC vendors, and compliance auditors consumed NVD data as if it were free and infinite. The retreat from that subsidy means the commercial ecosystem now has to fund enrichment itself—either by paying data brokers, by contributing back to CISA and FIRST, or by running parallel enrichment pipelines internally.

Over the medium term the most likely outcome is fragmentation. Large vendors will build proprietary enrichment that becomes a differentiator. Smaller vendors will pool resources into shared feeds. Open source tools will lag, because the people who used to volunteer CPE mappings on a weekend were NIST contractors, not community hobbyists. Security teams at organizations without enterprise scanner budgets will feel the gap first.

If Congress appropriates emergency NVD funding later this year, the policy could reverse. If it does not, April 15, 2026 will be remembered as the date the single most important public vulnerability database in the world formally admitted that the volume had exceeded what a public agency can sustain—and left the rest of the industry to figure out what comes next.