What Happened
In 2024, the National Institute of Standards and Technology (NIST)'s National Vulnerability Database (NVD) reduced its CVE enrichment operations, analyzing fewer vulnerabilities in depth. Traditionally, the NVD added CVSS scores, weakness classifications (CWE mappings), and affected product configurations to raw CVE records. Without this enrichment, CVE entries remain basic—just a description and an ID number.
This change was a strategic decision by NIST, not a technical failure. It significantly altered the vulnerability data landscape for organizations that relied on NVD-enriched feeds for patch management and risk scoring.
Timeline
The reduction occurred gradually in 2024, becoming noticeable when security teams observed:
- Q1 2024: Enrichment delays increased from days to weeks for new CVEs.
- Q2 2024: NIST confirmed resource constraints were limiting analysis capacity.
- Throughout 2024: A backlog of un-enriched CVEs grew; some CVEs never received CVSS scores or CWE mappings.
- Present: A significant portion of CVEs lack the structured data needed for automated risk assessment.
This was a degradation, not an outage. Your vulnerability scanner didn't fail; it began returning incomplete risk data.
Which Controls Failed or Were Missing
This situation highlights the need for resilient vulnerability intelligence pipelines. Three control gaps became apparent:
Single-source dependency: Many teams assumed every CVE would have an NVD-provided CVSS score. When scores stopped appearing, automated patch prioritization faltered. Tickets remained in "pending analysis" states, and SLAs became unenforceable due to missing data.
No data quality monitoring: Organizations didn't monitor their vulnerability feeds to detect when enrichment stopped. They had dashboards showing "vulnerabilities by severity," but no alerts for "percentage of CVEs missing severity scores this month." The issue went unnoticed until manual investigation revealed discrepancies in the patch queue.
Lack of fallback intelligence sources: Many programs treated NVD as the sole authoritative source without maintaining alternative feeds. When NVD enrichment slowed, there was no secondary data pipeline to query. Teams couldn't determine "Is this critical?" without waiting for NIST.
What the Standards Require
NIST 800-53 Rev 5, Control RA-5 (Vulnerability Monitoring and Scanning) requires organizations to update system vulnerabilities according to a defined frequency. The control doesn't specify using NVD, but it implies the need for current vulnerability intelligence. If your scanning tools can't score risks due to missing enrichment data, you're not meeting the control's intent.
ISO/IEC 27001:2022, Control 8.8 (Management of Technical Vulnerabilities) mandates obtaining information about technical vulnerabilities in a timely manner. Relying solely on a single source with capacity constraints doesn't meet this requirement if it introduces delays.
PCI DSS v4.0.1, Requirement 6.3.1 requires identifying security vulnerabilities using "industry-recognized sources for security vulnerability information." The plural "sources" indicates the expectation of comprehensive coverage. A single degrading feed doesn't meet this requirement.
These standards require a functional vulnerability intelligence capability. When your primary source degrades, the compliance gap is yours, not NIST's.
Lessons and Action Items for Your Team
1. Instrument your vulnerability data pipeline
Monitor data completeness, not just volume. Track:
- Percentage of CVEs in your asset inventory lacking CVSS scores.
- Median time from CVE publication to enrichment data availability.
- Number of "unknown severity" vulnerabilities blocking patch decisions.
Set alerts when these metrics degrade. You need to know within days when your intelligence feed quality drops.
2. Implement multi-source vulnerability intelligence
Consider these options to supplement or replace NVD enrichment:
- Vendor-specific feeds: RedHat, Ubuntu, Microsoft, and others publish their own severity assessments for CVEs affecting their products. These often appear faster than NVD enrichment.
- Commercial threat intelligence platforms: Services like VulnDB, Tenable VPR, or Qualys TruRisk offer alternative scoring and enrichment. Budget for at least one if you're in a regulated environment.
- FIRST EPSS scores: The Exploit Prediction Scoring System provides probability-of-exploit data. It's free and updates daily. Use it alongside CVSS for prioritization.
- CVE Numbering Authority (CNA) data: Many CNAs publish enrichment details when they assign CVEs. Query CNA feeds directly for faster data on specific vendors.
Define your vulnerability management policy to specify which sources you use and in what priority order. For example, "We use NVD when available; if no CVSS score appears within 72 hours, we apply vendor severity ratings."
3. Revise your SLAs to account for data availability
If your patch management SLA states "Critical vulnerabilities patched within 7 days of CVE publication," add: "or within 7 days of severity score availability, whichever is later." This acknowledges that you can't patch what you can't score.
For critical assets, consider: "High-risk assets are patched within 7 days of vendor security bulletin, regardless of CVE enrichment status." This removes dependency on NVD for your most sensitive systems.
4. Build internal enrichment capability for your stack
Focus on scoring CVEs affecting your specific technology stack. If you run a Python shop, maintain internal severity assessments for Python ecosystem CVEs based on your architecture. When NVD is silent, your security team can still make informed patch decisions for the libraries you use.
This involves documenting: "CVE-YYYY-XXXXX affects our authentication library and allows remote code execution in our configuration. Internal severity: Critical. Patch by [date]."
5. Participate in the CVE ecosystem
If your organization is large enough, become a CNA and publish enrichment for your products. If you're a consumer of open source, contribute severity assessments back to project maintainers. The CVE system improves when more entities contribute enrichment, not just NIST.
The issue isn't that NIST reduced enrichment; it's that organizations built fragile vulnerability programs that couldn't handle the reduction. Your vulnerability management process should withstand any single data source degrading. If it can't, you're one budget cut at a standards body away from compliance gaps you can't close.
