In February 2024, NIST paused enrichment processing for new CVE entries in the National Vulnerability Database. Over the following three months, thousands of newly published CVEs sat in the database with no CVSS scores, no CPE identifiers, and no analysis data — just a CVE ID, a description, and a reference link. Vulnerability scanners that relied on NVD as their sole CVE data source either couldn't score new findings at all or defaulted to "unknown severity" for anything published after the enrichment pause began. Security teams lost weeks of prioritization data for vulnerabilities that were being actively discovered and disclosed.
NIST attributed the pause to a combination of increased CVE submission volume and a change in support contract structure. The underlying issue — that the global vulnerability intelligence infrastructure depends substantially on a single government-managed database with a history of underfunding and staffing constraints — is not new. The 2024 pause was the highest-profile disruption but not the first. NVD enrichment lag has been a documented problem for years, with average time-to-enrichment running 30-60 days for new CVEs in peak periods.
What NVD Provides and What It Doesn't
NVD is the authoritative public source for CVE data enrichment in the US. When a new CVE is published to the MITRE CVE List, NIST adds CVSS scores (Base, Temporal, Environmental), CPE applicability entries (which product versions are affected), CWE category mappings, and reference link classification. This enrichment is what transforms a raw CVE ID into actionable scanner data — without CPE entries, a scanner can't automatically associate a CVE with specific products in your inventory.
What NVD doesn't provide: exploit availability status, proof-of-concept indicators, active exploitation confirmation, affected configuration context, or remediation-specific guidance. Those are added by downstream intelligence layers — CISA KEV for exploitation confirmation, VulnCheck for exploit intelligence, vendor advisories for remediation specifics. NVD is the base layer, not the complete stack.
The 2024 pause revealed how many scanners were treating NVD as their complete stack. When NVD enrichment stopped, those scanners degraded significantly — not because NVD is the only source of this data, but because they were built to use NVD exclusively rather than as one source among several.
Alternative CVE Data Sources
Several organizations publish CVE data that complements or supplements NVD, with different coverage priorities and update speeds:
CISA NVD Backup Feed: After the 2024 enrichment pause, CISA began publishing its own enrichment data for CVEs that NIST had not yet processed, specifically for CVEs relevant to US government systems. This feed is available via the same API format as NVD and can serve as a direct fallback for unprocessed entries. It doesn't cover the full CVE corpus, but covers the highest-priority subset.
OSV (Open Source Vulnerabilities): Google's OSV database focuses on open source package vulnerabilities and publishes data in a machine-readable schema that maps CVEs directly to affected package versions in specific ecosystems (npm, PyPI, Maven, Go modules, etc.). For organizations running significant open source dependencies, OSV provides faster and more precise version-level data than NVD's CPE entries, which can lag by weeks. The osv.dev database is openly available and well-maintained.
Vendor Security Advisories: Microsoft MSRC, Cisco PSIRT, Red Hat Product Security, and other major vendors publish their own vulnerability advisories that include severity scores, affected product versions, and remediation guidance — often before or simultaneously with NVD publication. Vendor advisories for products in your environment are the fastest source of patch-ready CVE data, because they include the exact package version to patch to. Aggregating vendor advisory feeds for your major vendors is a lower-volume but high-quality complement to NVD.
VulnCheck NVD++: VulnCheck maintains an enriched version of the NVD database that adds exploit availability data (Metasploit module presence, public PoC availability, active exploitation indicators) to each CVE entry. During the 2024 NVD pause, VulnCheck published their own CVSS scores for unprocessed entries, serving as a commercial substitute for the missing NVD enrichment. This is a paid service but provides materially better prioritization signal than NVD alone.
Building Feed Redundancy Into Your Vulnerability Pipeline
A multi-source CVE feed architecture has a primary source, one or more fallback sources, and a merge layer that combines data from multiple sources into a single enriched record per CVE. The merge logic needs conflict resolution rules: if NVD and a vendor advisory disagree on affected versions, which source takes precedence? (Vendor advisory, typically — they have the most specific product knowledge.) If NVD has no CVSS score and VulnCheck does, use VulnCheck's score with a source annotation.
PatchGuard's CVE database update cycle pulls from five sources on different schedules: NVD full feed (daily sync), CISA KEV (4-hour interval), vendor advisory RSS feeds for 47 major vendors (hourly), OSV (daily sync for relevant ecosystems), and VulnCheck exploit intelligence (daily). When a CVE is first seen in a vendor advisory before NVD has processed it, PatchGuard can score and surface it based on the vendor data alone — so scanner findings for that CVE appear correctly in your dashboard within hours of the vendor's advisory, not days after NVD processes it.
The CVE Publication Volume Problem
A secondary consequence of NVD lag is that the backlog during the 2024 pause revealed just how many CVEs NIST processes annually. In 2023, NIST processed roughly 28,000 CVEs. In 2024, the new submissions rate increased further — driven partly by the growth of automated CVE scanning tools and partly by expanded CNA (CVE Numbering Authority) programs that let more organizations assign CVE IDs directly. The NVD processing infrastructure, designed for a much lower volume, couldn't keep pace without additional resources.
For security teams, the practical implication of volume growth is that raw CVE counts will continue to increase faster than remediation capacity. The answer isn't scanning more aggressively or adding more CVE sources — it's better prioritization of the CVE data you already have. A vulnerability program that can score, triage, and act on 200 high-confidence findings per week is more effective than one that tries to track 2,000 findings of varying quality and enrichment status.
What the NVD Pause Revealed About Scanner Dependencies
The organizations least affected by the 2024 NVD enrichment pause were those running scanners with direct vendor advisory integrations and those using CISA KEV as their primary prioritization signal. For their highest-priority findings — actively exploited CVEs and major vendor advisories — they had multiple independent data sources, so the NVD gap didn't create blind spots in the most critical parts of their vulnerability queue.
The organizations most affected were those running open-source scanners with NVD as their only upstream feed, without vendor advisory integrations or KEV cross-referencing. Their scanners correctly continued detecting installed package versions, but couldn't score or prioritize new findings for months. Teams that weren't aware of the NVD pause may have concluded from their scanner dashboards that few new critical vulnerabilities were being published — when in reality, new CVEs were being published and exploited at normal rates, just without NVD enrichment.
The audit question to ask your scanner vendor: "What happens to your scoring and prioritization if NVD is unavailable or delayed for 30 days?" If the answer is "we fall back to vendor advisories and CISA KEV," that's a resilient architecture. If the answer is "our data wouldn't be updated," that's a dependency worth understanding before the next infrastructure disruption reveals it operationally.