What Happened
In 2025, the National Vulnerability Database (NVD) announced it would no longer provide enrichment data—such as CVSS scores, CWE classifications, and affected product configurations—for most newly published CVEs. NVD will now focus on vulnerabilities that meet specific criteria: those in CISA's Known Exploited Vulnerabilities catalog, those affecting widely deployed products, or those receiving significant attention from the security community.
This change is permanent and driven by a 263% increase in CVE submissions between 2020 and 2025. NVD's enrichment capacity hasn't kept pace, leading to a strategic decision to concentrate on the highest-impact vulnerabilities.
The immediate consequence: thousands of CVEs now appear in your vulnerability scanner feeds without severity scores, weakness classifications, or configuration guidance. Your team must determine the relevance of each CVE without the metadata you've relied on for years.
Timeline
2020-2024: CVE volume increases steadily. NVD enrichment delays grow from days to weeks, then months. Security teams express concerns but continue using NVD as their primary source.
Early 2025: NVD announces a selective enrichment model, prioritizing vulnerabilities based on exploitation activity, product prevalence, and community attention.
Mid-2025: The policy takes effect. Flashpoint tracked 44,509 disclosed vulnerabilities in 2025, with 14,593 having publicly available exploits. The gap between disclosed and enriched vulnerabilities widens significantly.
Present: Security teams find their vulnerability management workflows—built around NVD CVSS scores—no longer function as designed. Scanners report CVEs without severity, risk models falter, and compliance auditors question unenriched vulnerabilities in scope.
Which Controls Failed or Were Missing
This situation reveals control failures across the industry:
Single-source dependency for vulnerability intelligence: Many organizations relied solely on NVD as their authoritative source. When NVD changed its model, these programs lost their foundation.
Lack of alternative enrichment pipelines: Teams lacked processes for obtaining CVSS scores, CWE mappings, or affected version data from other sources. Their tools and workflows assumed NVD would always provide complete data.
Inadequate risk assessment frameworks: Organizations that depended exclusively on CVSS scores for prioritization struggled to adapt when those scores disappeared. They lacked secondary methods for evaluating unenriched CVEs.
Missing validation of third-party dependencies: Security teams didn't ensure their vulnerability scanners, SBOMs, or risk platforms could function without NVD enrichment. When the data stopped, they discovered their tools couldn't make decisions without it.
What the Relevant Standards Require
No standard explicitly mandates using NVD, but several require actions that NVD's enrichment historically supported:
PCI DSS v4.0.1 Requirement 6.3.1: You must identify and address security vulnerabilities with risk rankings based on industry practices and potential impact. If NVD doesn't enrich a CVE affecting your cardholder data environment, you still need that assessment.
ISO/IEC 27001:2022 Control 8.8: You must identify technical vulnerabilities and take appropriate measures, including evaluating their potential impact, regardless of whether NVD provides a CVSS score.
NIST 800-53 Rev 5 SI-2: Organizations must remediate vulnerabilities according to risk assessments. Risk assessment can't stop because enrichment data is missing.
SOC 2 Type II CC7.1: Your control environment must detect and evaluate vulnerabilities, whether or not they arrive with complete metadata.
Standards assume you have a functioning vulnerability management program. They don't specify NVD as the implementation. When NVD's model changes, your obligation to identify, assess, and remediate vulnerabilities remains.
Lessons and Action Items for Your Team
Build a multi-source vulnerability intelligence pipeline: Integrate feeds from operating system vendors, language ecosystem security teams, and commercial vulnerability intelligence providers. Configure your scanners to pull enrichment data from multiple sources, not just NVD.
Implement fallback enrichment logic: When a CVE appears without NVD enrichment, your tools should automatically query alternative sources. GitHub Advisory Database, OSV, and vendor security bulletins often provide CVSS scores and affected version ranges faster than NVD. Automate enrichment attempts from three sources before flagging a CVE for manual review.
Develop a risk assessment process that doesn't require CVSS: Build a decision tree: Is the vulnerable component in a production system? Does it handle sensitive data? Is it exposed to untrusted input? Is an exploit publicly available? You can answer these questions without waiting for an enrichment score.
Audit your compliance evidence collection: Document your multi-source approach. Show how you evaluate unenriched CVEs. Demonstrate that your program functions independently of any single intelligence source.
Test your vulnerability management process with synthetic unenriched CVEs: Verify your team can triage and remediate a CVE that arrives with no CVSS score, no CWE, and no affected version data. If you can't, fix your process now.
Revisit SLAs and policies that reference NVD or CVSS exclusively: Rewrite policies to account for alternative scoring methods and manual risk assessment.
The NVD's selective enrichment model isn't a failure—it's a realistic response to unsustainable volume growth. The failure is building a security program that assumes any single external service will always meet your needs. Diversify your intelligence sources, build resilient processes, and ensure your team can assess risk even when metadata is incomplete.
