POSITION PAPER FULL STATEMENT

Reconsidering the NVD Triage Decision

Three design choices within NIST's 15 April 2026 decision are independently fixable at roughly the same cost and the window in which those refinements can credibly be made is about ninety days.

NTSC THE FUTURE OF CVE JUNE 2, 2026

On 15 April 2026, the National Institute of Standards and Technology (NIST) announced that the U.S. National Vulnerability Database (NVD) will no longer provide full enrichment for most Common Vulnerabilities and Exposures (CVEs) submitted to it. This paper sets out a position on how that decision should be challenged. The position is not that the announcement should be reversed in full. Rather, it is that three specific design choices within the announcement are independently fixable at roughly the same cost to NIST, that fixing them would materially reduce the risk created for organizations that depend on NVD enrichment, and that the window in which those refinements can credibly be made is approximately ninety days.

What NIST announced

NIST stated that it will focus NVD enrichment efforts on three priority groups of vulnerabilities: CVEs listed in CISA's Known Exploited Vulnerabilities (KEV) catalog; CVEs affecting software used across the United States federal government; and CVEs associated with "critical software" as defined in Executive Order 14028, a U.S. federal procurement definition published in 2021.

All other CVEs will continue to be listed in the NVD, but marked Not Scheduled - no enrichment work is planned. CVEs published before 1 March 2026 that were still awaiting enrichment have been moved into the same Not Scheduled state, to be revisited only if resources permit.

Two additional changes warrant explicit attention. First, NIST will no longer routinely provide its own independent severity score (CVSS) when a score has already been supplied by the organization that disclosed the vulnerability - in practice shifting responsibility for severity assessment to the disclosing party. Second, product identification data used by security tools to match vulnerabilities to deployed software (Common Platform Enumeration, or CPE) has been cut back alongside CVSS analysis, even though generating product identifiers is substantially more amenable to automation than severity analysis.

A subsequent NIST announcement on 28 May 2026 partially addresses the product-identification question, and it is important to characterize it precisely. Effective 17 June 2026, the NVD will include the "affected" product information already present in a CVE record - the field within the CVE Record Format that can carry product identifiers - in its data feed and API, alongside Stakeholder-Specific Vulnerability Categorization (SSVC) data from CISA. This is a welcome and constructive step. It is, however, a decision to surface what a submitter has already provided, not to generate or guarantee that information. The NVD will pass through whatever product identification a submitter included; it does not commit NVD to producing an identifier where the submitter supplied none, and submitter population of these fields remains optional under the CVE Record Format. The distinction between surfacing existing data and ensuring usable data exists for every CVE is the precise gap the first of the three asks below addresses.

Why the timing is the issue

The timing of the NVD decision materially increases its impact. Multiple frontier artificial-intelligence models have recently demonstrated the ability to discover, analyze, and operationalize software vulnerabilities with minimal human involvement, dramatically compressing the time between public disclosure of a vulnerability identifier and the creation of a working exploit. Tasks that previously required highly skilled researchers days or weeks can now be performed autonomously in hours, at very low marginal cost.

This shift affects defenders and attackers differently. Defenders gain new capabilities to identify weaknesses earlier - but only if existing disclosure, patching, and enrichment pipelines can absorb that information quickly. Attackers, by contrast, can take immediate advantage of newly disclosed vulnerabilities without needing organizational change or additional process. NVD enrichment sits directly in this gap: it is one of the primary mechanisms defenders use to triage, prioritize, and act within a shrinking window. Reducing that enrichment at the same moment exploitation is accelerating does not eliminate analyst work; it shifts effort and advantage toward attackers who no longer need it.

The risks to factor in

The announcement in its current form directly amplifies several categories of risk - the considerations that should drive a request for refinement.

• Reduced vulnerability detection in tools. Many scanners and software-composition tools rely on accurate product identifiers to determine whether a published vulnerability applies to a given environment. When those identifiers are missing or outdated, vulnerabilities are silently missed. This falls most heavily outside the three priority tiers - particularly on open-source and third-party components, a growing share of disclosed vulnerabilities and increasingly targeted by automated discovery.
• Increased compliance and audit exposure. Many regulatory and industry frameworks - payment-card standards, healthcare regulations, financial controls, and emerging European digital-resilience requirements assume an authoritative, independent severity score. When severity now comes solely from the disclosing organization, the organization using that score must document and defend its provenance, introducing new audit questions for teams that relied on NVD scoring as a neutral reference.
• Greater contractual and customer risk. Contracts, SLAs, and customer security questionnaires commonly reference severity and remediation timelines implicitly grounded in NVD data. As that external reference weakens, organizations must justify their own scoring and prioritization decisions to customers, partners, insurers, and regulators who may not share the same context or methodology.
• Higher incident-response and litigation risk. After an incident, reviews commonly examine whether the organization was positioned to identify and remediate the vulnerability involved. Where a vulnerability was publicly disclosed but lacked sufficient NVD enrichment for tools to match it, the defensive posture becomes harder to defend - and shorter exploitation timelines make this scenario more likely over the next year.
• Divergence across security tools. Vendors will respond to reduced NVD enrichment by sourcing or generating alternative data in different ways and on different schedules. In the near term this produces materially different results for the same vulnerability across tools more noise and confusion exactly where faster, clearer triage is required.

Our position, and why it makes sense

This position does not ask NIST to expand its workload or revisit its capacity constraints. It accepts the tiered approach as the working framework and does not argue for a return to historical levels of enrichment. Instead, it identifies three narrow refinements that are defensible on engineering, cost, and governance grounds consistent with existing security, compliance, and risk-management objectives, and committing no one to a broader policy stance.

The three asks

Each request addresses a specific harm created by the current policy design.

1. Ensure usable product identification exists for every submitted CVE - not merely that existing data is surfaced. The 28 May announcement is the right direction: NVD will now surface the product identification a submitter provides. The remaining gap is that surfacing is not ensuring. Where a submitter provides no usable identifier - and population remains optional - the field is surfaced empty, and the vulnerability stays invisible to the scanners and software-composition tools that depend on a machine-readable product reference. The ask is that every submitted CVE carry a usable product and version identifier even when severity analysis is deferred - by NVD generating one where the submitter did not, or by making submitter population a requirement. Because identifier generation is substantially more automatable than severity analysis, closing this gap avoids disproportionate downstream harm at relatively low cost. It completes the direction NIST has already started: from generating identifiers under the old model, to surfacing them as of 28 May, to ensuring a usable identifier exists for every record.
2. Align prioritization with exploitation risk rather than federal procurement scope. One enrichment gate rests on a 2021 U.S. federal procurement definition of "critical software." That definition was designed for acquisition planning and explicitly deferred several technology categories to subsequent phases - including cloud and hybrid software, developer and CI/CD tooling, boot-level firmware, and operational technology - phases never completed. Used as a public vulnerability-enrichment filter, it systematically deprioritizes areas where exploitation pressure is increasing. NIST should retire this criterion or replace it with an NVD-specific criticality model - developed with CISA and the CVE community - that reflects real-world deployment and observed exploitation.
3. Retain independent severity scoring where exploitation likelihood is high. Commit to providing an independent CVSS score when certain signals are present - a high Exploit Prediction Scoring System (EPSS) value, use of a CNA-of-last-resort, or a validated community request. This preserves the independence that compliance, insurance, and regulatory processes rely on, without reinstating full population-wide scoring.

The ninety-day window

Over the next ninety days, security-tool vendors, regulators, and audit bodies will adapt their guidance and workflows to the new NVD operating model. After that point, changes become disruptive rather than corrective, and the cost - political and operational - of revisiting the policy rises sharply. The same period is when advanced Al models for vulnerability discovery and exploitation are likely to see broader real-world use. The window in which refinement is both most feasible and most necessary is therefore the same window.

Closing

NIST may be correct in its assessment of resource constraints. The design of the cut is the element that can still be improved. Automated vulnerability discovery and exploitation do not slow to match enrichment capacity, and the publication of a CVE identifier now marks the beginning of the race between defenders and attackers. Three focused, cost-neutral refinements - preserving product identification, prioritizing enrichment by exploitation risk, and retaining independent severity scoring where it matters most restore a critical defensive layer without reopening the broader capacity debate. This is the decision NIST should be asked to make while the opportunity still exists.