NVD Enrichment Triage: Enterprise Vulnerability Programs Must Adapt

Key Takeaways

Effective April 15, 2026, NIST fundamentally changed how it enriches the National Vulnerability Database (NVD), shifting from universal coverage to a risk-based triage model that prioritizes only a narrow subset of CVEs. Security teams that have built vulnerability management programs around the assumption of consistent, complete NVD metadata now face a significant gap in that foundation.

The core risk is operational invisibility. CVEs that fall outside NIST’s new priority categories—those not in CISA’s Known Exploited Vulnerabilities (KEV) catalog [13], not affecting federal government software, and not tied to Executive Order 14028 critical software—will receive no CVSS scores, no CPE identifiers, and no CWE mappings from NIST, potentially indefinitely. Without CPE data, vulnerability scanners that rely exclusively on NVD-derived enrichment cannot match a CVE to a product—the alert that should trigger a remediation workflow may never fire. The gap is not theoretical: approximately 29,000 backlogged CVEs have already been reclassified as “Not Scheduled,” and the forecast for 2026 suggests between 50,000 and 70,000 new CVE submissions will arrive before the year ends [1][4].

Compounding the enrichment gap is the reliability question surrounding CNA-provided scores. NIST will no longer routinely generate its own CVSS scores when a CVE Numbering Authority has already provided one—yet research indicates that vendor-supplied and NIST-assigned scores disagree in more than half of cases where both exist, with individual divergences reaching 6.9 points on the ten-point scale [5]. A gap of that magnitude is the difference between an emergency patch sprint and a deferred maintenance ticket.

Organizations that adapt quickly—by diversifying their enrichment sources, integrating EPSS-based prioritization, and moving away from NVD as a single source of truth—will maintain operational resilience. Those that do not will face an expanding blind spot at exactly the moment CVE volume is reaching historic highs.

Background

The National Vulnerability Database has served as the authoritative enrichment layer for the Common Vulnerabilities and Exposures (CVE) system since 2005. Where the CVE list maintained by MITRE provides identifiers and basic descriptions, the NVD adds the structured metadata that makes vulnerabilities operationally useful: CVSS severity scores, CPE product identifiers, CWE weakness classifications, and references. Security scanners, risk management platforms, and patch management tools across the enterprise depend on NVD enrichment to translate a raw CVE identifier into actionable intelligence.

That dependency has been accumulating structural risk for years. CVE submissions increased 263% between 2020 and 2025, growing from roughly 12,000 annual submissions to 48,185 in 2025 alone [1][3][11][12]. NIST invested significantly in processing capacity, enriching nearly 42,000 CVEs in 2025—a 45% increase over the prior record—yet the submission volume still outpaced enrichment throughput [4]. By early 2026, the visible NVD backlog had grown to more than 33,000 unenriched CVEs before NIST reclassified approximately 29,000 of them as “Not Scheduled” [4].

The root cause is structural, not operational. NIST computer scientist Harold Booth acknowledged as much in public remarks: “CVE reporting keeps increasing—and trust me, at the NVD, we see them all—and our ability to keep up is just not there” [4]. The agency’s enrichment workforce, working against a submission rate now projected at one-third higher in Q1 2026 compared to Q1 2025, has reached the limits of human-paced analysis.

NIST’s response, announced April 15, 2026, is a formal transition to risk-based enrichment triage. Rather than attempting to enrich all CVEs, the NVD will concentrate resources on three categories: CVEs appearing in CISA’s Known Exploited Vulnerabilities catalog (targeted for enrichment within one business day of receipt), CVEs affecting software used by the U.S. federal government, and CVEs for software designated as critical under Executive Order 14028—a category that includes operating systems, web browsers, identity management systems, endpoint security tools, and network infrastructure software [1]. All other submissions receive “Lowest Priority – Not Scheduled” status, with enrichment available on request via [email protected] and subject to uncertain review timelines.

The implications extend beyond inconvenience. CVE reporting has quietly become a critical infrastructure function that the vulnerability management industry treated as an unlimited public good. The April 2026 announcement signals that this assumption is no longer valid.

Security Analysis

The CPE Blindspot: When Scanners Go Silent

The most operationally immediate consequence of reduced enrichment is the loss of CPE (Common Platform Enumeration) data. CPE strings are the mechanism by which vulnerability scanners map a CVE to a specific vendor, product, and version combination. A CVE record without CPE data cannot be matched against an asset inventory, which means a scanner relying exclusively on NVD-derived CPE will generate no alert for that vulnerability, regardless of its actual severity.

VulnCheck, which operates an enrichment layer called NVD++, has documented that NVD’s CPE coverage reached only approximately 41% of CVEs published in 2024—implying that roughly 60% of CVEs lacked the CPE data needed for scanner matching [16][7]. The concern raised by practitioners is concrete: tools that are “hardcoded” to NVD’s CPE strings will simply not surface CVEs that were never enriched, creating a class of organizational exposure that security operations teams have no mechanism to detect through their existing workflows [6].

This is not a future risk. For the 29,000 CVEs reclassified as “Not Scheduled” from the pre-March 2026 backlog, and for the projected tens of thousands of new CVEs that will not meet NIST’s priority criteria in 2026, the CPE gap is present today. Organizations whose vulnerability scanners rely on NVD CPE data without supplementary feeds are already operating with reduced visibility.

The CNA Score Reliability Problem

NIST’s decision to stop generating independent CVSS scores when a CNA has already provided one introduces a second, less visible risk: the quality and consistency of vendor-assigned severity ratings. The CVE program’s distributed model relies on approximately 400 organizations authorized as CVE Numbering Authorities, each of which can assign CVSS scores when submitting a CVE. The assumption embedded in the new NIST policy is that CNA-provided scores are sufficiently reliable to stand alone.

Available evidence suggests that assumption is questionable. Research by Cisco principal engineer Jerry Gamblin documented 1,567 CVEs for which both NVD and GitHub’s CNA had assigned CVSS scores—and found the two disagreed. Individual gaps reached 6.9 CVSS points, and the scores differed enough in many cases to cross severity tier boundaries [5]. A shift from 8.2 (High) to 6.1 (Medium) is not a minor calibration difference; it determines whether a CVE triggers an emergency patch cycle or lands in a weekly maintenance window. ENISA’s Nuno Rodrigues Carvalho publicly cautioned that critical infrastructure organizations “should not depend excessively on a potential ‘single point of failure’” and that enrichment responsibility should be distributed across multiple trusted actors [2].

Vendors acting as CNAs understand the architecture of their own products better than a NIST analyst does, but they also face disclosure incentives that may favor conservative severity ratings. With independent NIST analysis no longer routine for the majority of CVEs, organizations have lost a second-opinion check that historically helped normalize scoring outliers.

Scope and Concentration Risk

The scale of the affected population deserves explicit attention. NIST’s three priority categories—KEV, federal software, and EO 14028 critical software—cover a relatively narrow slice of enterprise software environments. Commercial off-the-shelf applications, line-of-business software, cloud SaaS dependencies, open source libraries, and developer tooling that sit outside federal procurement will broadly fall into the “Not Scheduled” category unless the vendor or relevant CNA pursues independent enrichment or files an enrichment request with NIST.

This creates asymmetric coverage. Large enterprise software vendors with dedicated security research teams and CNA status—Microsoft, Google, Adobe, Oracle—will continue generating enriched CVE records through their own disclosures. Smaller vendors, open source maintainers, and the long tail of commercial software producers that lack CNA status or enrichment capacity will not. The practical result is that the CVEs most likely to affect broadly deployed commercial and open source software are the ones least likely to receive timely enrichment, inverting the expected relationship between software ubiquity and data quality.

The forecasted CVE volume amplifies this concern. Projections of 50,000 to 70,000 new submissions in 2026 imply that the gap between published CVEs and enriched CVEs will continue widening unless NIST’s planned automation improvements materialize—and the agency has provided no firm timeline for those improvements [4].

Recommendations

Immediate Actions

Security operations teams should audit their vulnerability management toolchain this week to determine exactly which data sources feed CPE matching and CVSS scoring. Many commercial vulnerability scanners and exposure management platforms ingest NVD data, but the degree to which they supplement it with alternative feeds varies significantly by vendor and configuration. Teams should contact their scanner and SIEM vendors directly to understand how they are responding to the NVD enrichment reduction and whether automatic supplementary data feeds are already in place or planned.

Teams should also cross-reference their CVE alert backlog against the NVD API to identify any recently published CVEs that show “Awaiting Analysis” or “Not Scheduled” status. These records are visible in the database but lack the metadata that vulnerability management tools need to generate actionable alerts. Any CVE affecting software in active use by the organization should be manually triaged using whatever vendor or CNA data is available in the CVE record itself.

Organizations can request expedited enrichment of specific CVEs by emailing [email protected]. This is a manual process with uncertain turnaround times, but for high-priority software dependencies outside the federal and critical software categories, it is currently the only official mechanism to accelerate NIST enrichment.

Short-Term Mitigations

The most effective near-term defense against the enrichment gap is source diversification. CISA’s KEV catalog provides daily-updated, operationally verified exploitation signals for the highest-risk CVEs and should already be integrated into any mature vulnerability prioritization workflow; if it is not, that integration should be the first deliverable from this guidance [1][13]. Beyond KEV, the Exploit Prediction Scoring System (EPSS), maintained by FIRST.org and updated daily, provides probability-based scores estimating the likelihood that a given CVE will be exploited in the wild within 30 days [9]. EPSS v4, released March 2025, demonstrated substantially better predictive precision than CVSS alone for identifying which vulnerabilities will actually be exploited—making it a practical complement to severity-based prioritization in environments where enrichment coverage is uneven [15].

Several organizations now operate enriched CVE feeds that supplement or extend NVD data. VulnCheck’s NVD++ provides community-accessible CPE enrichment with vcConfigurations labels, created independently for CVEs that NIST has not yet processed [7]. The Open Source Vulnerabilities (OSV) database at osv.dev provides structured enrichment for open source library vulnerabilities, drawing directly from ecosystem maintainers and package security advisories across PyPI, npm, Maven, and similar registries. The GitHub Security Advisory Database (GHSA) functions as a parallel enrichment layer for code hosted on GitHub. Security teams supporting software-intensive organizations should evaluate all three as supplementary inputs to their vulnerability management platform.

Strategic Considerations

The NVD enrichment reduction is best understood not as a temporary operational disruption but as a permanent inflection point in the vulnerability data ecosystem. NIST has explicitly stated that the new prioritization model reflects the sustainable operating capacity of the program, and the agency’s planned automation improvements—while real—may require years to close the gap against CVE volume growing at one-third annually. Organizations that rebuild their vulnerability management programs around the assumption of returning to universal NVD coverage will be making a costly strategic mistake.

The emerging model, signaled by NIST and echoed across industry commentary, is distributed enrichment responsibility: software producers providing complete, accurate metadata at the point of CVE assignment; commercial vendors operating enrichment layers as competitive features; government agencies like CISA focusing enrichment resources on confirmed exploited vulnerabilities; and enterprise security teams integrating multiple authoritative feeds rather than treating any single source as complete. Procurement decisions for vulnerability management platforms should now explicitly evaluate multi-source enrichment capability as a selection criterion, not an optional feature.

Security programs that have achieved SSVC (Stakeholder-Specific Vulnerability Categorization) or similar contextualized prioritization frameworks are better positioned to navigate enrichment gaps, because their prioritization logic is anchored to asset criticality, exploitability signals, and business context rather than CVSS scores alone. Organizations still operating primarily CVSS-threshold-based patching policies are most exposed to the enrichment reduction and should treat this as a forcing function to mature their prioritization methodology.

CSA Resource Alignment

The NVD enrichment reduction directly engages several dimensions of CSA’s published guidance on cloud and infrastructure security.

CCM v4.1 — Threat and Vulnerability Management Domain: The Cloud Controls Matrix version 4.1, released December 2025, expanded the TVM domain with controls specifically emphasizing risk-based response practices and threat modeling integration [10]. The enrichment reduction from NIST makes CCM TVM controls more rather than less important: organizations implementing risk-based vulnerability triage in accordance with CCM v4.1 are architecturally better positioned to absorb the loss of centralized NVD enrichment because their prioritization logic does not depend on uniform severity scoring from a single source.

CSA Top Concerns with Vulnerability Data (2024): CSA’s Vulnerability Data Working Group published a comprehensive analysis of the CVE and CVSS ecosystem’s structural weaknesses in 2024, examining CVSS accuracy limitations, the scalability constraints of human-paced enrichment, and the gaps between static severity scores and actual exploitability risk [8]. Independent analysis examining approximately 25,000 CVEs with both primary and secondary CVSS scores found that 56% had conflicting scores across sources [14]—a figure that reinforces the structural concern about relying on any single scoring source as authoritative. The April 2026 NIST announcement validates these analyses and should be read as confirmation that the concerns they identified have now materialized into operational policy changes requiring enterprise response.

AI Controls Matrix (AICM): Where AI systems or AI-assisted development pipelines are part of an organization’s software estate, vulnerabilities in AI frameworks, inference libraries, and model-serving infrastructure face the same enrichment gap as all other software categories. Given that most AI infrastructure dependencies—PyTorch, Hugging Face Transformers, ONNX Runtime, and similar libraries—fall outside federal procurement categories, they are unlikely to receive priority NVD enrichment. Organizations applying the AICM to govern AI systems in production should ensure their vulnerability management processes for AI components do not rely exclusively on NVD-derived metadata.

CSA STAR Program: Cloud service providers participating in the STAR program’s continuous monitoring tier should review their vulnerability management attestations in light of the enrichment changes. Statements of coverage that reference NVD-sourced CVSS scores as the basis for risk-based patching policies may no longer be accurate if the underlying NVD records are unenriched. STAR assessors and auditors should treat the source and completeness of vulnerability enrichment data as an explicit review criterion.

Zero Trust Architecture Guidance: CSA’s zero trust guidance emphasizes continuous validation of device and software posture as a prerequisite for trust decisions. Vulnerability management quality is foundational to posture assessment: an asset with unenriched CVEs affecting its software stack will appear clean in posture checks that rely on NVD-derived scanner output, even when it is not. Zero trust implementations that feed vulnerability scanner output into access decisions should evaluate whether their scanner configurations supplement NVD with the alternative enrichment sources described above.

References

[1] NIST. “NIST Updates NVD Operations to Address Record CVE Growth.” NIST News, April 2026.

[2] Help Net Security. “NIST admits defeat on NVD backlog, will enrich only highest-risk CVEs going forward.” Help Net Security, April 16, 2026.

[3] The Hacker News. “NIST Limits CVE Enrichment After 263% Surge in Vulnerability Submissions.” The Hacker News, April 2026.

[4] Infosecurity Magazine. “NIST Drops NVD Enrichment for Pre-March 2026 Vulnerabilities.” Infosecurity Magazine, 2026.

[5] Socket.dev. “NIST Officially Stops Enriching Most CVEs as Vulnerability Volume Surges.” Socket Blog, 2026.

[6] SecureWorld. “The NVD Course Correction: Navigating NIST’s Strategic Pivot for 2026.” SecureWorld, 2026.

[7] VulnCheck. “Enhancing Access to NIST NVD Data: Introducing CPE Enrichment in VulnCheck NVD++.” VulnCheck Blog, 2024.

[8] Cloud Security Alliance. “A Vulnerability Management Crisis: The Issues with CVE.” CSA Blog, November 21, 2024.

[9] FIRST.org. “Exploit Prediction Scoring System (EPSS).” Forum of Incident Response and Security Teams, 2026.

[10] Cloud Security Alliance. “CCM v4.1: Strengthening Cloud Security.” CSA Blog, December 2, 2025.

[11] Cybersecurity Dive. “NIST limits vulnerability analysis as CVE backlog swells.” Cybersecurity Dive, 2026.

[12] Jerry Gamblin. “2025 CVE Data Review.” JerryGamblin.com, January 1, 2026.

[13] CISA. “Known Exploited Vulnerabilities Catalog.” Cybersecurity and Infrastructure Security Agency, continuously updated.

[14] VulnCheck. “CVSS Accuracy Issues: How Vendors and NVD Disagree on Severity Scores.” VulnCheck Blog, 2024.

[15] Empirical Security. “Introducing EPSS Version 4.” Empirical Security Research, March 2025.

[16] VulnCheck. “Outpacing NVD: VulnCheck CPE Coverage Analysis.” VulnCheck Blog, 2024.