What Happened
On April 15, 2026, NIST announced that the National Vulnerability Database (NVD) would stop providing comprehensive enrichment for most Common Vulnerabilities and Exposures (CVEs). Instead of analyzing and scoring all published CVEs, NVD will now focus on a "prioritized triage model," enriching only vulnerabilities that meet specific criteria, primarily those in CISA's Known Exploited Vulnerabilities (KEV) catalog.
This change was not due to a system failure or breach but was a deliberate policy shift driven by the sheer volume of vulnerabilities. In 2025, 48,185 unique CVEs were published, a significant increase from approximately 18,000 entries in 2020. Meanwhile, CISA's KEV catalog tracked about 245 new entries. The gap between existing vulnerabilities and those actively exploited had grown too wide for NIST to address with manual analysis.
For teams that relied on NVD's CVSS scores and CPE mappings for vulnerability management, this shift created operational challenges. Scanners dependent on NVD enrichment data suddenly had incomplete information for most new CVEs.
Timeline
2020: NVD processes approximately 18,000 CVE entries with full enrichment, including CVSS scoring and CPE applicability statements.
2020-2025: The CVE Numbering Authority (CNA) program expands, allowing more organizations to assign CVEs directly. This federated model increases both coverage and volume.
2025: 48,185 CVEs published. NVD enrichment backlog grows, with delays in analysis becoming noticeable.
April 15, 2026: NIST announces the prioritized triage model, focusing enrichment on vulnerabilities in the KEV catalog and other high-impact issues. Most CVEs will receive only basic metadata.
Post-announcement: Organizations relying solely on NVD data must choose between accepting incomplete vulnerability intelligence or building multi-source aggregation.
Which Controls Failed or Were Missing
This situation exposed architectural weaknesses in vulnerability management approaches:
Single Source Dependency: Teams built their vulnerability assessment processes around one database. When that database changed its model, workflows were disrupted. There was no redundancy or fallback.
Lack of Prioritization Framework: Organizations relying on NVD's CVSS score for risk assessment lacked internal capabilities to evaluate a vulnerability's relevance to their environment.
Inadequate Vendor Risk Management: Teams didn't track the sources of vulnerability data for their security tools. When NVD's coverage changed, they couldn't quickly identify affected scanners and SBOMs.
No CNA Evaluation Process: The federated CVE model means CNAs now provide initial severity assessments. Not all CNAs have the same analytical rigor, creating a new single-point-of-failure distributed across many CNAs.
What the Relevant Standards Require
ISO/IEC 27001:2022 Annex A.8.8 requires managing technical vulnerabilities, including "obtaining timely information" and "evaluating exposure." The standard doesn't mandate using NVD but requires a process for identifying and evaluating vulnerabilities. If your process fails when one data source changes, you're not meeting the control's intent.
The NIST Cybersecurity Framework v2.0 function ID.RA-1 calls for identifying and documenting asset vulnerabilities, emphasizing "multiple sources" for intelligence. A single-source approach was always a gap, now made evident by the NVD change.
PCI DSS v4.0.1 Requirement 6.3.1 requires identifying security vulnerabilities using "reputable outside sources" (plural). Relying only on NVD means non-compliance, as the requirement assumes cross-referencing multiple feeds.
NIST 800-53 Rev 5 control SI-5 requires receiving security alerts from "multiple sources" and taking action. Multiple sources are the baseline, not an advanced practice.
Lessons and Action Items for Your Team
Map your vulnerability data dependencies now. List every tool that uses vulnerability intelligence, such as scanners, SBOM analyzers, and threat intel platforms. Document where each tool gets CVE data. If it's "just NVD," you have a single point of failure.
Build a multi-source aggregation layer. You need at least three sources:
- NVD for the subset it still enriches
- Direct CNA feeds for vendor-specific vulnerabilities (e.g., GitHub Security Advisories for open source, vendor PSIRTs for commercial software)
- Commercial or community aggregators that compile and normalize data across CNAs
Consider models like Snyk, which combines automated analysis with CNA data and proprietary research. Use resources like OSV for open source components and VulnDB for commercial software, or build your own aggregation pipeline if feasible.
Establish CNA trust tiers. Not all CNAs are equal. For example, GitHub's Security Advisories team has mature processes. A new CNA for a niche software category may provide only basic severity estimates. Create a policy on which CNAs you trust for severity scoring and which require internal validation.
Implement context-based prioritization. Stop waiting for external CVSS scores. Build a decision framework:
- Is the vulnerable component internet-accessible in your environment?
- Does it run with elevated privileges?
- Does it process sensitive data?
- Is there proof-of-concept exploit code available?
If you can't answer these questions without NVD enrichment, you're not managing vulnerabilities effectively.
Test your response to incomplete data. Conduct a tabletop exercise: a new CVE is identified for a library you use, but the CNA provides only basic information. How long does it take your team to assess the impact? If the answer is "we'd wait for NVD," you need a new playbook.
The NVD policy change didn't break vulnerability management; it revealed that many organizations lacked a resilient process. Your action item isn't to find a new single source to replace NVD—it's to build a system that doesn't rely on any single source at all.
