NIST Stops Enriching Every CVE. Here's What That Actually Costs Defenders.

Effective April 15, 2026, NIST officially stopped treating the National Vulnerability Database as a complete, enriched record of every software flaw ever disclosed. The agency will now enrich only the CVEs it considers highest risk, leaving everything else as a bare listing with no severity score, no weakness classification, and no product data. The announcement came the same week Anthropic published its Claude Mythos Preview red team assessment — a disclosure that makes clear the submission volume NIST is already failing to handle is about to increase by an order of magnitude.

The NVD has been the default starting point for vulnerability triage since NIST launched it in 2005. Security teams, compliance auditors, scanner vendors, and government agencies all built workflows around the assumption that any disclosed CVE would eventually carry NIST's enrichment: a severity score, a weakness classification, CPE data linking the flaw to specific product versions. Harold Booth, supervisory computer scientist and NVD project lead at NIST, announced the policy change at VulnCon26 in Scottsdale, Arizona, on April 15 — the same day the official announcement went live. That assumption is now void for the majority of submissions.

The Numbers That Broke the Model

The scale of what happened to CVE volume over the past five years is worth sitting with. Between 2020 and 2025, submissions to the NVD climbed 263%. In 2025 alone, 48,171 CVEs were recorded — a total NIST enriched only partially, processing nearly 42,000 entries, a 45% increase over any prior year, and still fell further behind. A backlog of more than 30,000 CVEs had accumulated since early 2024, when a funding gap and staffing constraints first visibly slowed the enrichment pipeline. The NVD team stayed at 21 analysts throughout this growth, a fact NVD program manager Tanya Brewer acknowledged publicly at VulnCon in 2024. In Q1 2026, new submissions were running nearly one-third higher than the same period the previous year.

"Our ability to keep up is just not there." — Harold Booth, supervisory computer scientist and NVD project lead, NIST, VulnCon26, April 15, 2026. Booth told attendees that CVE reporting keeps increasing, NVD sees every submission, and the backlog continues to grow because current methods cannot absorb the volume.

In February 2026, FIRST — the global forum overseeing the CVE program — forecast that 2026 would be the first year to surpass 50,000 total CVE disclosures. Jerry Gamblin, principal engineer at Cisco Threat Detection and Response, published an even higher projection of 70,135 CVEs by year-end, reflecting a 45.6% growth rate over 2025. Both forecasts were made before Anthropic disclosed Claude Mythos Preview's autonomous vulnerability discovery capabilities in early April. FIRST has also modeled scenarios in which annual CVE submissions crack 100,000. Jay Jacobs, Empirical Security founder and EPSS special interest group lead at FIRST, put it plainly: if it is not Mythos driving the surge, "something is going to come out next week," making the acceleration structural rather than event-driven.

What Changed on April 15

NIST will now apply full enrichment to three categories of CVEs. First, any CVE appearing in CISA's Known Exploited Vulnerabilities catalog, with a stated goal of enriching KEV additions within one business day of receipt. Second, CVEs affecting software used within the federal government. Third, CVEs for software classified as critical under Executive Order 14028. NIST's definition of EO 14028 critical software is specific and should not be read too broadly: it covers identity, credential, and access management (ICAM) systems; operating systems, hypervisors, and container environments; software with privileged access to networking or computing resources; software controlling access to data or operational technology; and, in certain cases, libraries and packages that are integral to the operation of software in those categories. Software that does not fall into one of these buckets — including a large portion of commercial and open-source software used outside the federal government — does not qualify under this definition even if it is widely deployed or carries significant risk.

Everything outside those categories gets listed in the NVD without enrichment under a new label: "Lowest Priority — not scheduled for immediate enrichment." The record exists. The severity score, weakness mapping, and CPE product data may not. NIST openly acknowledged the limitation: the new criteria "may not catch every potentially high-impact CVE," and even CVEs outside scope may carry significant risk for affected systems. The label matters practically because it signals NIST does not plan to enrich these CVEs on any routine timeline — enrichment remains possible only if explicitly requested or if the CVE is reclassified under the priority criteria. NIST also stopped generating its own CVSS score for CVEs where the submitting CVE Numbering Authority has already provided one, deferring entirely to the submitter's assessment. This is a meaningful change because the existence of a CNA-provided score no longer triggers independent review; NIST will only intervene if it determines the CNA's score is inconsistent with the vulnerability. Modified CVEs will only be reanalyzed if NIST determines the change materially affects its original enrichment data.

Organizations can request enrichment for any lowest-priority CVE by emailing nvd@nist.gov. NIST committed to reviewing those requests and scheduling enrichment as resources allow, with no binding timeline. The agency also updated CVE status labels — the previous "Deferred" status for the 2025 backlog is now reclassified as "Modified After Enrichment," and unenriched backlogged CVEs from before March 1, 2026 are moving to "Not Scheduled" — and launched a real-time NVD Dashboard to make the status of all CVEs visible to users.

NIST framed the changes as a stabilization measure, stating that the agency needs time to build the automated systems and workflow improvements required for long-term sustainability. Large language models, AI agents, and robotic process automation are on the agency's public to-do list. Booth mentioned pilot automation tools for Linux kernel enrichment and ongoing research into machine learning-assisted methods at VulnCon. No timelines were given — a pattern consistent with missed deadlines stretching back to 2024, when the agency first pledged to clear the backlog before the end of fiscal year 2024.

The CNA Score Problem Defenders Haven't Priced In

NIST's decision to defer to CNA-provided severity scores by default introduces a risk the policy announcement did not address directly. CVE Numbering Authorities vary enormously in scoring quality. Jerry Gamblin demonstrated the problem at VulnCon26 itself: analyzing 1,567 CVEs where both the NVD and GitHub Advisory Database had assigned scores, NVD scored higher in 885 cases and GitHub scored higher in 682 cases. The largest single divergence was 6.9 points — enough to separate a medium from a critical on the same vulnerability. A cluster of cases showed gaps of 4.0 points or more. Gamblin built a public tool called Consensus Engine to make this disagreement visible at scale.

The problem has structural roots. VulnCheck has previously documented that of 120,000 CVEs with CVSS v3 scores in the NVD, roughly 56% of those with both a NIST score and a vendor score had conflicting values. Error rates on CNA-submitted scores for specific vulnerability classes have reached 15% in VulnCheck's analysis. With NIST no longer providing an independent check on CNA submissions, that error rate becomes the operational baseline for any team not cross-referencing externally.

Tom Alrich, who leads the OWASP SBOM Forum and Vulnerability Database Working Group, captured the contradiction directly: after years of discarding CVSS scores and CPE data created by CNAs when they failed NIST's quality threshold, the agency is now shifting responsibility to those same CNAs. Mayuresh Dani, Security Research Manager at the Qualys Threat Research Unit, flagged the downstream impact on scanner tools: without CPE data, security scanners built on NVD cannot programmatically match unenriched CVEs to specific software versions in an environment. A critical vulnerability against software an organization actually runs may generate no scanner alert at all if its CPE record is absent.

Nine Facts Most Experts Have Wrong

The conversation around the NVD's enrichment change has surfaced a lot of received wisdom — some of it accurate, much of it imprecise. The following facts are specific, documented, and frequently unknown even to practitioners who work with vulnerability data daily. They matter more now that the data pipeline is being restructured.

The AI Problem NIST Didn't Name

NIST's announcement attributed the submission surge to general growth in vulnerability research and disclosure practices. What it did not name directly is the structural force now reshaping the front end of that pipeline: AI-assisted and autonomous vulnerability discovery.

On April 7, 2026, Anthropic published its Claude Mythos Preview red team assessment. The model had autonomously discovered thousands of high-severity zero-day vulnerabilities across every major operating system and web browser. The specifics are precise and verified. In OpenBSD, Mythos Preview identified a 27-year-old integer overflow vulnerability in the TCP SACK implementation — two crafted packets crash any host responding over TCP, and the flaw dates to OpenBSD's 1998 SACK implementation. The full discovery campaign across roughly 1,000 scaffold runs cost under $20,000; the specific run that found the flaw cost under $50. In FFmpeg, the model found a 16-year-old out-of-bounds write flaw in the H.264 codec that survived more than 5 million automated fuzzer runs without triggering. In FreeBSD, Mythos Preview autonomously identified and fully exploited CVE-2026-4747, a 17-year-old remote code execution vulnerability in the NFS server that grants unauthenticated root access — no human involvement after the initial prompt, and a 20-gadget ROP chain split across multiple packets. On a Firefox 147 exploit-writing benchmark, Mythos produced 181 successful full-exploit runs out of 250 trials, compared to 2 out of several hundred for Claude Opus 4.6 — a roughly 90x improvement. One important caveat from Anthropic's own system card (page 52): when the two easiest bugs are removed from that corpus, Mythos's full-code-execution rate drops from 72.4% to 4.4%, with the system card noting "almost every successful run relies on the same two now-patched bugs." The 181 figure accurately describes benchmark performance on those 250 specific trials; it does not represent 181 distinct novel Firefox vulnerabilities discovered. The broader point — that the model's autonomous exploit development capability represents a qualitative step beyond any prior model — holds regardless of that caveat.

Anthropic is not releasing Mythos Preview publicly. The model is available only to roughly 40 organizations through Project Glasswing, including Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks. But the capability it demonstrates is not exclusive to Anthropic. Google's Big Sleep autonomous system found 20 real-world zero-days in open source projects by mid-2025. AISLE, an AI security firm operating discovery pipelines since mid-2025, has submitted over 180 externally validated CVEs across more than 30 projects, including 15 CVEs in OpenSSL in a single security release. Snehal Antani, co-founder and CEO of Horizon3, put the trajectory plainly: the cost and effort to discover vulnerabilities will approach zero over time as models commoditize and open-source alternatives emerge.

A specific caveat is worth stating here, because coverage of Mythos has not always made it explicit. Anthropic's most striking results — including the OpenBSD TCP SACK find and the FFmpeg codec flaw — were achieved with full source code access. Open-source projects are where this approach works best, because the entire codebase is available for analysis. Closed-source commercial software presents a fundamentally different challenge: without source code, a model must work from compiled binaries, API surfaces, and web interfaces, which is harder and more constrained. Anthropic's own red team documentation acknowledges this distinction. It does not mean Mythos cannot find vulnerabilities in closed-source software — it has — but the discovery economics and scalability are quite different from what the open-source numbers suggest. Additionally, AISLE's independent research found that several of the flagship vulnerabilities featured in Anthropic's announcement were also detected by much cheaper open-weights models, including one with 3.6 billion parameters costing $0.11 per million tokens. The implication, as AISLE put it, is that the bottleneck in AI vulnerability security is the system and the scaffold around the model, not the model itself. Defenders and threat actors alike will have access to capable discovery tools well before Mythos-class capability becomes broadly commoditized — because smaller, cheaper models can already close much of the same gap on open-source targets.

The convergence of these forces — a shrinking enrichment program, deteriorating CNA score quality, and AI discovery pipelines operating at volumes no human process can absorb — arrives at the same moment the EU is building its own parallel infrastructure. ENISA's European Vulnerability Database (EUVD), operational since May 2025, aggregates data from EU CSIRTs, vendors, and multiple vulnerability databases. Starting September 11, 2026, the EU Cyber Resilience Act mandates that manufacturers report actively exploited vulnerabilities within 24 hours of becoming aware of them, with a full notification due within 72 hours, feeding directly into ENISA's Single Reporting Platform. That reporting obligation will generate a new stream of vulnerability intelligence that feeds the EUVD independently of the NVD — a structural decoupling that was already underway before NIST's announcement accelerated it. ENISA's standing in the global CVE program has also expanded in ways the article's original phrasing understated: ENISA became a CVE Root CNA — not merely a standard Numbering Authority — in November 2025, giving it authority to onboard and oversee other European CNAs. At VulnCon26, ENISA's Nuno Rodrigues Carvalho revealed the agency is now being onboarded by CISA toward Top-Level Root CNA status (one rung above Root in the CVE hierarchy, currently held only by CISA and MITRE), with Carvalho saying he hopes ENISA can achieve that status "in 2026 or early 2027." That distinction matters: a TL-Root CNA participates directly in governing the CVE Program at its highest level, not simply coordinating regional CNAs under an existing root structure. Europe's vulnerability infrastructure is being built with a degree of operational independence that did not exist two years ago.

What Defenders Lose and What to Do About It

Security teams that relied on NVD as their sole or primary enrichment source now face a concrete operational problem: the database will list flaws they cannot quickly evaluate. No CVSS score means no rapid severity triage. No CPE data means scanner correlation becomes unreliable — Immanuel Chavoya of RiskHorizon AI noted after the announcement that CPEs remain a particular problem because NVD is the authoritative source, and without them, "the data can't be operationalized." No weakness classification means detection rule training data goes thin.

The organizations that will feel this most severely are those running vulnerability management programs built entirely around NVD output — particularly in sectors where compliance frameworks have historically pointed to NVD as the authoritative source. Those frameworks were written for a world where centralized enrichment was feasible. That world ended on April 15.

The data on actual exploitation makes the required shift clearer. VulnCheck cataloged over 40,000 CVEs in 2025; of those, only 422 — roughly 1% — were exploited in the wild. FIRST's own research found that only about 2.3% of CVEs scored CVSS 7 or higher were observed in exploitation attempts over a given month, and in Q1 2025, 28% of exploited vulnerabilities carried only medium CVSS base scores. The security program that patches everything rated 7.0 and above is systematically deprioritizing a significant share of what attackers are targeting and flooding response capacity with vulnerabilities that will never be weaponized.

The practical shift requires treating CISA's KEV catalog as the primary signal for urgent action, supplemented by the Exploit Prediction Scoring System (EPSS). EPSS, governed by FIRST and updated daily, estimates the probability that a given CVE will be exploited in the wild within the next 30 days — providing the real-world exploitability signal that CVSS scores structurally cannot. CISA's Vulnrichment project, which independently enriches CVE records with CVSS, CWE, and SSVC data, continues to operate and should be integrated as a secondary enrichment source for records NVD will not touch. Commercial threat intelligence feeds that track proof-of-concept code and active exploitation in real time, and vendor security advisories for software the organization actually runs, complete the replacement stack.

A note on what "treat KEV as your primary signal" means in practice, because genuine confusion exists about this in the field. CISA's KEV catalog ended 2025 with 1,484 total entries and added 245 during the year. It is not a complete list of dangerous vulnerabilities. It is a list of vulnerabilities with confirmed exploitation evidence for which CISA has verified a patch or mitigation is available. CISA does not add a CVE to the KEV until remediation guidance exists — a deliberate policy that makes the catalog operationally clean but also means it lags real exploitation. As of May 2025, VulnCheck's independent KEV catalog tracked over 3,600 exploited vulnerabilities — 173% more than CISA's list — and published exploitation evidence on average 27 days faster, precisely because VulnCheck does not require patch availability before listing (the catalog has grown since those figures were published). In 2025, roughly 32% of newly exploited vulnerabilities were weaponized within 24 hours of public disclosure. CISA's catalog structurally cannot capture all of those in time. When this article recommends treating KEV as the primary triage signal, that means anything on the CISA KEV requires immediate action. It does not mean nothing outside it poses a threat. For teams that can absorb additional intelligence load, monitoring VulnCheck KEV or comparable commercial exploitation feeds alongside CISA's catalog substantially closes that coverage gap.

"NIST just stopped pretending it could enrich every CVE." — Kip Boyle, vCISO, Cyber Risk Opportunities LLC. Boyle's fuller point: CVSS 7+ patch coverage has been sold as a strategy for years and never was one. Vendors who built programs around that metric were optimizing for a vanity number. KEV coverage is the operationally honest replacement.

Trey Ford, Chief Strategy and Trust Officer at Bugcrowd, framed the structural point: the research community has long understood that centralizing vulnerability triage at this volume cannot hold, and NIST's announcement is simply that understanding made official policy. Caitlin Condon, VP of security research at VulnCheck, acknowledged the policy was expected but identified the core consequence: a significant share of vulnerabilities now have no clear path to enrichment for organizations that have relied on NIST as their authoritative source. Vincenzo Iozzo, CEO of SlashID, added that LLMs are approaching the point where individual organizations can use them to prioritize and contextualize vulnerabilities in their own environment, reducing the structural dependency on centralized enrichment — the automation answer NIST itself is working toward but has not yet deployed.

One more point worth raising directly: EPSS is widely recommended here and throughout the industry as a replacement signal for absent CVSS data, but there is an active debate about what it can and cannot do that the field sometimes collapses into oversimplification. EPSS predicts global exploitation probability based on internet-wide threat activity data. What it does not assess is whether a specific vulnerability is reachable inside your environment, whether your compensating controls would stop an exploit attempt, or whether a low-scoring vulnerability on a critical exposed asset poses more organizational risk than a high-scoring one on an isolated internal system. A vulnerability with a high EPSS score behind a well-configured WAF and restricted network segment may be far less urgent for your organization than EPSS alone implies. The reverse is also true: a low EPSS score does not make a CVE safe — it means exploitation has not yet been widely observed across the internet, which may simply reflect limited attacker awareness of your specific exposure. EPSS is also blind to zero-days by definition: it requires a CVE to exist before it can be scored, meaning the vulnerabilities AI discovery tools are finding before disclosure carry no EPSS signal at all. Use EPSS as an efficient filter and exploitability signal, not as a final risk verdict. Your asset context, network exposure, and compensating controls still have to close that last mile.

Key Takeaways

1. The NVD is no longer a comprehensive enrichment source: CVEs outside CISA's KEV catalog, federal software scope, and EO 14028 critical software will be listed without severity scores, weakness mappings, or CPE data. Security workflows dependent on NVD enrichment for those categories need alternative data sources now, not at the next review cycle.
2. CISA's KEV catalog is the new floor for prioritization, not the ceiling: NIST committed to enriching KEV entries within one business day. For everything below that threshold, defenders need EPSS, CISA Vulnrichment, commercial intel, and vendor advisories to fill the gap. KEV coverage is now a more operationally useful metric than CVSS coverage.
3. CNA-provided scores are now the default and their quality is uneven: Of 1,567 CVEs where NVD and GitHub Advisory Database both scored the same vulnerability, the two sources disagreed in every case. Gaps exceeding 4.0 CVSS points — medium vs. critical — are documented. Every CNA-only score should be cross-referenced before driving remediation priority.
4. AI discovery is what broke the volume math, and it is accelerating: FIRST forecast 50,000+ CVEs in 2026 before the Mythos Preview disclosure. Cisco's Jerry Gamblin projected 70,135. AISLE is already submitting AI-discovered CVEs at scale. The backlog NIST cannot clear will grow faster than it can be reclassified.
5. The disclosure pipeline itself has structural gaps AI will widen: Vulnerabilities classified as architectural limitations, or patched without CVE assignment, never appear in NVD regardless of enrichment policy. The set of real exploitable flaws with no public record is growing alongside the set of enumerated-but-unenriched ones.
6. Treat this as an infrastructure change, not a policy note: Updating threat intel sources, replacing scanner configurations that depend on CPE data, integrating EPSS and CISA Vulnrichment, and renegotiating compliance interpretations that cite NVD as authoritative are operational tasks with deadlines — not awareness items for the backlog.

The NVD was built for a world where vulnerabilities were found by humans, disclosed through researchers or vendors, and processed at a pace a 21-person federal team could manage. That world is gone. NIST's announcement is a public acknowledgment that a centralized, manually operated model cannot absorb what AI-assisted discovery is delivering today, let alone what it will deliver once open-source models reach comparable capability. The question for defenders is not whether to adapt. It is how fast, and what they build in place of the assumption that a government database would do this work for them.

How to Replace NIST NVD Enrichment in Your Vulnerability Management Program

With NIST now enriching only a fraction of submitted CVEs, security teams need a concrete sequence of steps to replace what the NVD used to provide automatically. The following workflow gives a practical path from the current state to a multi-source enrichment posture.

1. Establish CISA KEV as your primary triage signal. Subscribe to the Known Exploited Vulnerabilities catalog feed at cisa.gov. NIST has committed to enriching KEV additions within one business day, making it the only guaranteed enrichment signal in the new model. Any CVE appearing on the KEV catalog requires immediate triage regardless of whether other enrichment data is present. KEV coverage — the percentage of KEV entries your team has addressed — is now a more operationally meaningful metric than overall CVSS patch coverage.
2. Integrate EPSS scoring for unenriched CVEs. EPSS, maintained by FIRST and updated daily, estimates the probability that a given CVE will be exploited in the wild within 30 days. It provides the real-world exploitability signal that static CVSS scores cannot. Add an EPSS feed to your vulnerability management platform and configure your triage workflow to pull EPSS scores automatically for any CVE that arrives without a NIST-generated severity rating. FIRST's research shows that combining EPSS, KEV, and CVSS can reduce urgent prioritization workload by as much as 95% compared to CVSS-only triage. That figure refers specifically to the reduction in false positives when filtering CVSS ≥7 vulnerabilities through an EPSS lens — not a promise that 95% of remediation work disappears. The practical reduction is significant but will vary by environment. EPSS also has known blind spots: it cannot score vulnerabilities that have no CVE assigned, it predicts global exploitation patterns rather than your organization's specific exposure, and it cannot account for your compensating controls. A high EPSS score on a vulnerability your WAF blocks may be less urgent than a moderate-EPSS CVE on a directly internet-exposed asset. Use it as a prioritization filter and exploitability signal, not as an autonomous risk verdict.
3. Add CISA Vulnrichment as a secondary enrichment source. CISA's Vulnrichment project independently enriches CVE records with CVSS, CWE, and Stakeholder-Specific Vulnerability Categorization (SSVC) data. It is already an authorized data provider in the CVE program and continues to operate independently of the NVD enrichment changes. For CVEs that fall outside NIST's new scope, Vulnrichment data may be available even when NVD enrichment is not.
4. Validate CNA-provided severity scores before acting on them. NIST now defers to CVE Numbering Authority scores by default. Analysis of 1,567 CVEs where NVD and GitHub Advisory Database both assigned scores found disagreement in every case, with gaps reaching 6.9 CVSS points. Cross-reference any CNA-only score against at least one external source — EPSS, a commercial threat intelligence feed, or Vulnrichment — before using it to drive remediation priority. Treat a 4.0+ point divergence between sources as a flag requiring manual review.
5. Subscribe to vendor security advisories for every major product in your environment. For software outside the federal and EO 14028 critical scope, vendor advisories are now the primary source of weakness classification and patch guidance. Configure direct advisory feeds — RSS, email, or API — for every major vendor in your environment. Silently patched vulnerabilities with no CVE assignment will not appear in any vulnerability database; vendor release notes and changelogs are the only signal for some of the most operationally relevant flaws.
6. Request enrichment for high-impact unenriched CVEs. NIST accepts enrichment requests at nvd@nist.gov. For CVEs that fall outside automatic enrichment criteria but affect systems critical to your environment, submit a request promptly. There is no binding SLA, but NIST has stated it will review requests and schedule enrichment as resources allow.
7. Audit compliance documentation that cites NVD as authoritative. Any internal policy, control framework mapping, or compliance evidence package that references NVD severity scores as the triage standard now reflects a broken assumption. Update those documents to name the alternative data sources your program uses — KEV, EPSS, Vulnrichment, vendor advisories, commercial feeds — and verify that your compliance auditors accept the substitution before your next assessment cycle. For EU-regulated organizations, the Cyber Resilience Act's mandatory vulnerability reporting requirement takes effect September 11, 2026, and ENISA's European Vulnerability Database provides an independent enrichment track. ENISA became a CVE Root CNA in November 2025 and is currently being onboarded toward Top-Level Root CNA status, meaning its role in global vulnerability governance is expanding alongside the EUVD's reporting obligations — the two reinforce each other as structural alternatives to US-only infrastructure. One important caveat on compliance: some regulatory frameworks — including certain PCI-DSS controls and federal requirements under NIST SP 800-53 — explicitly reference NVD or CVSS-based scoring as part of their vulnerability management requirements. Swapping in EPSS and KEV without first confirming your auditors accept that substitution may create a compliance gap even if your operational security posture is objectively stronger. Have this conversation with your compliance team proactively. Document your rationale — specifically that NIST has formally announced NVD no longer provides comprehensive enrichment and that your alternative sources demonstrably support more accurate risk prioritization — before your next audit cycle, not during it.

Frequently Asked Questions

What does it mean that NIST is limiting CVE enrichment?

NIST will no longer automatically add CVSS severity scores, CWE weakness classifications, and CPE product configuration data to every CVE submitted to the National Vulnerability Database. Only CVEs meeting specific criteria receive full enrichment: those in CISA's Known Exploited Vulnerabilities catalog, those affecting federal government software, and those in software classified as critical under Executive Order 14028. All other CVEs will still be listed in the NVD — they receive a CVE identifier and a basic record — but will carry no analytical data and are assigned a "Lowest Priority — not scheduled for immediate enrichment" status. "Not Scheduled" is the specific label applied to pre-March 2026 backlogged CVEs that NIST is not returning to. The practical effect is the same for defenders: neither category will receive enrichment unless explicitly requested.

Why did NIST change its CVE enrichment policy?

CVE submissions climbed 263% between 2020 and 2025, reaching 48,171 disclosures in 2025 alone. Despite enriching nearly 42,000 of those — a 45% year-over-year increase requiring the same team of 21 analysts to work faster than ever — NIST accumulated a backlog exceeding 33,000 unenriched CVEs. Submissions in Q1 2026 were running nearly one-third higher than the same period in 2025. NIST's Harold Booth stated publicly at VulnCon26 that with current methods, catching up is not possible. The policy formalizes a triage model the agency had been operating informally for over two years.

Which CVEs will NIST still fully enrich?

Three categories receive full enrichment: CVEs added to CISA's Known Exploited Vulnerabilities catalog, with a target of enrichment within one business day; CVEs affecting software used within the federal government; and CVEs for software classified as critical under Executive Order 14028. The EO 14028 definition is specific — it is not a catch-all for widely-used or high-risk software. NIST defines it as covering identity, credential, and access management (ICAM) systems; operating systems, hypervisors, and container environments; software designed to run with elevated or managed privilege; software with privileged access to networking or computing resources; software controlling access to data or operational technology; software operating outside normal trust boundaries with elevated access; and, in specific cases, libraries and packages that are integral to the operation of software in those categories. Commercial and open-source software that does not fall into one of these specific categories — even if widely deployed or carrying significant risk — will not automatically qualify.

What happens to CVEs that NIST will not enrich?

New CVEs that do not meet the priority criteria are assigned a CVE identifier and listed in the NVD with a "Lowest Priority — not scheduled for immediate enrichment" label, meaning NIST has no plan to analyze them on any routine timeline. They receive no CVSS score, no CWE weakness mapping, and no CPE data linking the flaw to specific product versions. Separately, backlogged CVEs with an NVD publish date earlier than March 1, 2026 that were never enriched are being reclassified as "Not Scheduled" — a permanent deferral. Without CPE data, security scanners cannot automatically match a CVE to software in an organization's environment, meaning a vulnerability may not surface in routine scans at all. NIST stated explicitly that it will not systematically clear either category retroactively.

How should security teams respond to the NIST NVD changes?

Treat CISA's KEV catalog as the primary enrichment signal for triage decisions — but understand it is a floor, not a ceiling. CISA's 1,484-entry catalog requires patch availability before listing, which means it lags real-world exploitation. For teams with capacity, supplementing with VulnCheck's KEV or similar commercial exploitation feeds closes a significant coverage gap. Add EPSS scoring from FIRST as a daily exploitability signal for CVEs outside NIST's enrichment scope, and note that EPSS is a global prediction, not an assessment of your specific environment or controls. Integrate CISA's Vulnrichment project as an independent enrichment source. Subscribe directly to vendor security advisories for all major software in your environment. Cross-reference any CNA-only CVSS score against at least one external source before acting on it. Update compliance documentation that cites NVD severity scores as an authoritative standard, and verify auditor acceptance of your alternative sources before the next assessment cycle — some frameworks reference NVD explicitly and that conversation requires proactive documentation.

What is CISA Vulnrichment and how does it help?

Vulnrichment is a CISA-operated project that independently enriches CVE records with CVSS scores, CWE weakness classifications, and Stakeholder-Specific Vulnerability Categorization (SSVC) decision data. It is an authorized data provider in the CVE program, meaning its enrichment data appears directly in CVE records at cve.org. Vulnrichment continues to operate independently of the NVD enrichment changes and provides a supplementary data track for CVEs that NIST will no longer enrich. It is not a complete substitute — SSVC data requires organizational context to apply — but it covers a meaningful subset of the gap.

Can organizations request that NIST enrich a specific CVE?

Yes. NIST accepts enrichment requests at nvd@nist.gov. The agency has committed to reviewing requests and scheduling enrichment as resources allow, but has made no binding timeline commitments for out-of-scope CVEs. For organizations with a large number of affected systems or an upcoming compliance audit dependent on enriched data, submitting a request early is advisable — NIST acknowledged at VulnCon26 that it had already received feedback and offers of support from the user community.

How does AI vulnerability discovery affect the CVE pipeline going forward?

Autonomous AI systems can now scan major open-source codebases and generate high-severity zero-day findings at a cost measured in tens of thousands of dollars per campaign. Anthropic's Mythos Preview discovered thousands of zero-days in a matter of weeks; AISLE has been operating a continuous discovery pipeline since mid-2025 and has submitted over 180 validated CVEs. FIRST forecast 50,000+ CVE disclosures for 2026 before the Mythos announcement; Cisco's Jerry Gamblin projected 70,135. FIRST has also modeled scenarios where annual submissions exceed 100,000. Additionally, AI-identified vulnerabilities that vendors classify as architectural limitations may never enter the CVE program at all, creating a growing category of exploitable flaws with no NVD record regardless of enrichment policy. One widely cited caveat: Mythos's headline results were achieved primarily against open-source software where full source code was available. Closed-source targets present a harder problem due to binary-only access. And AISLE's independent testing found that several of Mythos's showcase vulnerabilities were also detected by significantly cheaper open-weights models — suggesting the accelerating timeline to widespread AI-assisted discovery applies broadly, not exclusively to frontier-model access.

What is the EUVD and does it replace NVD for European organizations?

The European Vulnerability Database (EUVD), operated by ENISA and live since May 2025, aggregates vulnerability intelligence from EU CSIRTs, vendors, and existing databases including NVD. It provides three dashboard views covering critical vulnerabilities, actively exploited vulnerabilities, and EU-coordinated disclosures. Starting September 11, 2026, the EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities to ENISA within 24 hours of awareness, creating a mandatory reporting stream that feeds the EUVD independently through ENISA's Single Reporting Platform. On ENISA's standing within the global CVE program: ENISA became a CVE Root CNA in November 2025, giving it authority to onboard and oversee European CNAs — a step above being a standard Numbering Authority. At VulnCon26, ENISA disclosed it is being onboarded by CISA toward Top-Level Root CNA status, a designation currently held only by CISA and MITRE that represents direct participation in governing the CVE Program at its highest level. ENISA's Nuno Rodrigues Carvalho indicated at VulnCon26 that he hopes the Top-Level Root CNA designation can be achieved sometime in 2026 or early 2027. The EUVD does not yet function as a full NVD replacement — it currently relies heavily on NVD as a source — but it represents a deliberate decoupling from US-only vulnerability infrastructure that NIST's policy change will accelerate. EU organizations should treat the EUVD as a supplementary enrichment track now, and a progressively more independent one as its mandatory reporting pipeline activates in September 2026.

What is the difference between the CVE Program and the NVD, and does this policy change affect both?

The CVE Program and the NVD are distinct systems that are often conflated. The CVE Program — run by MITRE under contract with CISA — is the global registry that assigns CVE identifiers to disclosed vulnerabilities. It controls the numbering system and manages the network of CVE Numbering Authorities (CNAs) that submit vulnerability records. A vulnerability entering the CVE Program receives a CVE ID; that is the extent of what the program itself provides. The NVD is NIST's separate database, which ingests CVE records and layers additional analytical data on top of them: CVSS severity scores, CWE weakness classifications, and CPE product configuration data. NIST's April 15 policy change affects only the NVD enrichment layer. The CVE Program continues to assign identifiers and accept submissions at its current pace. The practical consequence of this distinction is that a CVE will still exist as a numbered, publicly listed record — it will appear in the CVE Program's database at cve.org — but the enrichment that made it operationally usable in scanners and triage workflows comes from NIST, and that enrichment will now be selective. Organizations that query cve.org directly will see a record; organizations querying nvd.nist.gov for severity scores and product data for out-of-scope CVEs may see nothing beyond the raw identifier.

How does this affect security scanners and commercial vulnerability management tools?

The impact on scanner tools is structural, not cosmetic. Most commercial vulnerability management platforms — including tools across the enterprise scanner market — rely on NVD as a primary or contributing data source for CPE mappings that link CVEs to specific software versions. CPE data is what allows a scanner to answer the question: does this CVE affect the version of this product we are running? Without a CPE record, a scanner cannot make that match programmatically. A CVE affecting software in your environment will not surface in a routine scan if its CPE record is absent from the NVD. The scanner does not generate an alert and does not flag the vulnerability. The tool behaves as if the vulnerability does not exist in your environment. This is not a new problem — it existed during the 2024–2025 backlog period — but NIST's policy formalizes it as a permanent condition for a large share of CVE submissions. Organizations should ask their scanner vendors directly: what is your fallback enrichment source for CVEs without NVD CPE data? Vendors with their own enrichment pipelines or relationships with commercial threat intelligence providers are positioned better than those that pass NVD data through without supplementation. Vendor advisories, VulnCheck, and similar services that maintain independent CPE or product-matching data become the operational backstop. The practical test: run a query against your scanner for a recently disclosed CVE in software you run that falls outside the KEV/federal/EO 14028 scope, and verify whether the scanner surfaces it.

Is NIST's automation roadmap realistic, and what is the actual timeline?

NIST has cited automation as its path to long-term sustainability, naming large language models, AI agents, and robotic process automation as the tools it intends to develop. Harold Booth mentioned a pilot automation tool for Linux kernel CVE enrichment at VulnCon26 and referenced ongoing research into machine learning-assisted methods. No public timelines were given. The track record warrants skepticism. NIST first publicly acknowledged the backlog problem in early 2024 and pledged to clear it before the end of fiscal year 2024. That deadline passed without resolution. At the 2024 VulnCon, NVD program manager Tanya Brewer said the backlog would be cleared by September 2024. It was not. The agency's current announcement is explicitly framed as a stabilization measure to buy time while those automated systems are built — not a statement that the automation is ready or imminent. CISA's Vulnrichment project exists in part because NIST's timeline slipped long enough to require an independent parallel track. Any planning assumption that NIST will restore comprehensive enrichment on a defined timeline is not supported by the available evidence. Organizations whose vulnerability programs are currently gap-reliant on NVD should plan as if the current scope restrictions are permanent, not transitional, and build the multi-source enrichment posture accordingly.

Why has NIST's analyst team stayed at 21 people while CVE volume nearly tripled?

The staffing constraint has two overlapping causes: federal hiring processes and budget pressure. NIST operates within federal hiring rules that make rapid team expansion structurally difficult even when funding is available. The 2024 backlog crisis was triggered in part by a contracting gap — NIST's third-party support contract lapsed, removing external analytical capacity that had supplemented the in-house team. The team stayed at 21 federal employees throughout. Beyond the contracting issue, NIST has faced sustained budget pressure. The Trump administration's DOGE-driven cuts to federal agencies including CISA have tightened the broader cybersecurity funding environment, and NIST itself has operated under resource constraints that informed the decision to stop commissioning enrichment work it could not sustain. Vulnerability historian Brian Martin has been publicly critical of the resource allocation, writing on LinkedIn that the funding allocated to this work is inadequate given the scale of what is being asked, and arguing that independent database operations have delivered comparable enrichment quality at a fraction of NIST's per-CVE cost. The 21-analyst figure against 48,000-plus annual submissions — roughly 2,300 CVEs per analyst per year before the backlog — illustrates why the math stopped working without any reference to willingness or competence. Whether the funding environment improves under future budget cycles is a political question the agency does not control.

What is SSVC, and how is it different from CVSS scoring?

Stakeholder-Specific Vulnerability Categorization (SSVC) is a decision-tree framework for vulnerability prioritization developed originally by Carnegie Mellon University's Software Engineering Institute and adopted by CISA as the basis for its Vulnrichment enrichment data. Where CVSS produces a numeric severity score by evaluating a fixed set of technical characteristics — attack vector, privileges required, impact on confidentiality and integrity — SSVC is explicitly designed to produce a remediation decision rather than a score. The SSVC tree asks a structured sequence of questions: Is this vulnerability being actively exploited? Is exploitation automated? Is the affected component present in your environment? What is the safety and mission impact if exploited? The output is an action — Act, Attend, Track, or Track&Collect — rather than a number. The practical difference matters for triage. CVSS scores a vulnerability in isolation; the same flaw gets the same score regardless of whether it is being actively exploited in the wild or whether your organization runs the affected software at all. SSVC incorporates exploitation status and environmental relevance into the prioritization decision directly. CISA's Vulnrichment records include SSVC data alongside CVSS and CWE classifications, but applying SSVC's full decision tree requires knowing which affected components are present in your specific environment — context that Vulnrichment cannot supply and your team must provide. Teams evaluating Vulnrichment should treat SSVC data as a starting point for a contextual decision, not an autonomous verdict.

What should small and mid-sized organizations do if they lack a dedicated vulnerability management team?

The multi-source enrichment posture described in this article assumes a team with tooling capacity, threat intelligence subscriptions, and the bandwidth to cross-reference CNA scores. Smaller organizations that lack those resources face a narrower but still actionable path. The most important single step is subscribing to CISA's KEV catalog and treating it as a mandatory patch obligation rather than an advisory list. NIST has committed to enriching KEV entries within one business day, so the KEV feed provides the most reliable signal available under the new model. CISA makes the KEV catalog available as a free JSON feed at cisa.gov. The second step is enabling automatic vendor update channels for every significant software product in the environment — not just operating systems but also applications, network equipment firmware, and any internet-facing services. For organizations using managed detection and response (MDR) or managed security service providers (MSSPs), verifying that those providers have updated their enrichment sources beyond NVD-only pipelines is an immediate priority. Ask the provider specifically whether they can alert on a CVE affecting software you run if that CVE has no NVD CPE mapping. If the answer is uncertain, that is the gap to close. CISA's Vulnrichment is free and publicly accessible, and integrating it does not require a large-enterprise tool stack. For organizations using cloud-native environments, the major cloud providers — AWS, Azure, GCP — maintain their own vulnerability intelligence pipelines that do not depend on NVD enrichment; their native security services will generally surface relevant CVEs regardless of NVD status. The irreducible minimum is: KEV subscription plus vendor advisory monitoring. Everything above that reduces blind spots further but is optional, not foundational.