On April 15, 2026, NIST made official what security teams had been living with for two years: the National Vulnerability Database will no longer try to enrich every CVE. The backlog started building in February 2024, when a contracting dispute with NVD's analysis vendor slowed CVSS scoring and CPE tagging to a crawl. It never recovered. CVE submissions rose 32% in 2024 alone and 263% cumulatively between 2020 and 2025, and by May 2024 an estimated 93.4% of newly published CVEs — and 50.8% of already known-exploited vulnerabilities — were sitting unanalyzed, according to reporting from Nextgov/FCW that cited independent tracking of NVD's own status pages. NIST actually enriched roughly 42,000 CVEs in 2025, 45% more than any prior year, and still lost ground. So the agency changed the rules: enrichment is now prioritized for CVEs in CISA's Known Exploited Vulnerabilities catalog, CVEs affecting software used by the federal government, and "critical software" as defined under Executive Order 14028. Every backlogged CVE published before March 1, 2026 was moved to a new "Not Scheduled" status. This piece walks through how that happened and what it means for how a security team should actually source vulnerability data going forward.
What changed in NVD's enrichment policy on April 15, 2026?
NIST published an update announcing that NVD will no longer attempt to enrich (assign CVSS scores and CPE identifiers to) every incoming CVE. Enrichment is now triaged into tiers: CVEs in CISA's KEV catalog get priority handling, followed by CVEs affecting federal-government software and software meeting the "critical software" definition from Executive Order 14028. Everything else is explicitly labeled lowest priority, and NIST said plainly it may never get to many of them. Backlogged CVEs published before March 1, 2026 were reclassified as "Not Scheduled" — not "pending," not "in queue," but a status that signals no committed timeline. A CRADA-based industry consortium NIST floated in March 2024 to bring outside analysts into the process was quietly dropped as too administratively cumbersome to stand up. The net effect: a CVE for a niche internal tool, a long-tail npm package, or a library outside the federal software list can now sit with no CVSS score and no CPE tag indefinitely, by policy rather than by accident.
Why did the backlog happen in the first place?
The proximate cause was a February 2024 contracting lapse at NVD's analysis vendor that cut enrichment throughput sharply just as submission volume began accelerating. But the deeper cause is structural: CVE issuance has decentralized faster than NVD's staffing has scaled. More CVE Numbering Authorities (CNAs) now mint IDs directly — vendors, bug bounty platforms, and open-source foundations among them — which is good for coverage but means NVD receives far more raw CVE records than it has analysts to score. VulnCheck and Socket.dev, two independent trackers that monitor NVD's public processing metrics, both reported the unanalyzed queue holding above 18,000 through late 2024 and continuing to grow into 2025 — with NIST ultimately reclassifying roughly 29,000 backlogged CVEs as "Not Scheduled" in April 2026 — even as NIST's own enrichment output hit a record high. Q1 2026 submissions ran about 33% above the same period in 2025 — the math simply never closed.
Why is CVSS-only prioritization already a blind spot even before this policy change?
Even when NVD was enriching every CVE, a raw CVSS score told you almost nothing about whether an attacker was actually using a flaw. CVSS measures theoretical severity — could this be bad — not real-world exploitation likelihood. That gap is why the Exploit Prediction Scoring System (EPSS), maintained by FIRST, and CISA's KEV catalog exist as separate signals: EPSS estimates the probability a vulnerability will be exploited in the next 30 days from observed internet scanning and exploit-code activity, while KEV lists vulnerabilities CISA has confirmed are being actively exploited right now. A team that triages purely by CVSS ≥ 7 routinely burns sprints on vulnerabilities no one is exploiting while missing lower-scored ones already weaponized in the wild — a mismatch documented for years before the 2026 enrichment change made the underlying CVSS pipeline itself unreliable for a growing share of CVEs.
What blind spots does a single-source NVD pipeline now have, structurally?
Before April 2026, an NVD-only pipeline had a timing problem: enrichment was slow, but it eventually arrived for most CVEs. Now it has a coverage problem: enrichment may never arrive for anything outside KEV, federal software, or EO 14028 critical-software categories. That is a large share of what most companies actually run — the internal tooling, the smaller open-source dependencies, the vendor products that aren't federally procured. A vulnerability-management program built to key off "does this CVE have a CVSS score in NVD" will now silently treat un-enriched CVEs as lower priority or invisible, regardless of actual exploitability, simply because NIST hasn't gotten to them. That's a policy-created blind spot, not a temporary lag, and it applies precisely to the software most teams have the least other visibility into.
How should a security team structure a multi-source vulnerability database strategy?
The fix is architectural, not procedural: no single feed should be a gating dependency. A resilient pipeline pulls from OSV.dev and GitHub Security Advisories (GHSA) for ecosystem-native, often faster-published vulnerability data; CISA KEV for confirmed active exploitation; FIRST's EPSS for exploitation-probability scoring independent of CVSS; and direct vendor/maintainer advisories for products where the vendor is the authoritative source before any CNA files a CVE at all. NVD remains useful — especially now for KEV and critical-software CVEs where its enrichment is fastest — but it should be one input merged with others, not the trigger that determines whether a finding gets scored at all. Concretely, that means matching dependencies against multiple vulnerability databases rather than one, scoring severity with EPSS and KEV membership alongside (or instead of) a possibly-absent CVSS number, and treating "not yet in NVD" as a data gap to fill, not a signal that nothing is wrong.
How does reachability and independent discovery reduce reliance on any vulnerability feed timing?
The most durable answer to feed-timing risk is not waiting for any external database at all. Safeguard's ESSCM prioritizes vulnerabilities using EPSS, CISA KEV membership, and call-path reachability analysis together, so a finding's urgency is set by whether your code can actually execute the vulnerable path and whether it's being exploited — not by whether NVD got around to assigning it a CVSS score. Separately, Safeguard's TAOR pipeline (Trace, Analyze, Observe, Report) ingests commits and releases directly from package registries and discovers vulnerabilities independent of CVE publication, requesting CVE assignment only after a finding is validated — which means detection doesn't sit behind any registry's enrichment queue in the first place. Neither approach requires NVD to move faster; both are built on the assumption that it won't always be able to.