On April 17, 2026, NIST published an update explaining changes to how it operates the National Vulnerability Database. The short version is that NVD can no longer keep up with the volume of CVEs being published, so it is shifting to a triage-based model that prioritizes enrichment for the highest-impact vulnerabilities. That is a significant operational change for a database that many organizations have treated as the authoritative source of vulnerability information for decades.
But the more interesting question is why this is happening now, and what it signals about the direction of vulnerability management going forward.
The numbers behind the change
NIST's update describes a 260-plus percent increase in CVE volume between 2020 and 2025. That is not a small drift. It is a structural change in the rate at which vulnerabilities are being discovered and disclosed. In 2020, the CVE program published roughly 18,000 vulnerabilities. By 2025, that number had grown past 40,000. The NVD team, which enriches CVE records with CVSS scores, CWE classifications, CPE affected product mappings, and other metadata, has not scaled proportionally.
The result is a growing backlog. NIST has already been visibly behind on enrichment for a while, and this update makes official what many in the security community have observed informally: full enrichment of every CVE is no longer a realistic goal with current resources.
What the triage model means
NIST's response is to prioritize. Under the updated approach, NVD enrichment will focus first on vulnerabilities that appear in CISA's Known Exploited Vulnerabilities catalog and on vulnerabilities in widely deployed or critical software. Lower-priority CVEs may receive delayed enrichment or limited metadata.
This is a pragmatic decision, but it has real implications. Security tools, vulnerability scanners, and risk management platforms that pull from NVD and assume full enrichment will start returning incomplete data for a larger share of CVEs. Organizations relying entirely on NVD as their single source of vulnerability intelligence will have gaps.
The practical response is to treat NVD as one input among several rather than a complete picture. CISA's KEV catalog, vendor advisories, and commercial vulnerability intelligence feeds fill in what NVD may not cover in depth or on time.
AI's role in this problem
NIST's update explicitly names AI-assisted software development as a contributing factor to the CVE volume increase. That is worth taking seriously, because it points to something structural rather than coincidental.
When development accelerates, so does the rate at which code is written, and the rate at which bugs appear. AI coding assistants do not introduce a new category of vulnerability so much as they increase the throughput of code reaching production. More code means more attack surface. More attack surface means more vulnerabilities to find. When security researchers apply their own AI-assisted tools to analyze that expanded surface, the discovery rate climbs as well. The entire cycle speeds up.
There is also a secondary effect. As AI tooling lowers the barrier to security research, more people are able to find and report vulnerabilities who previously lacked the technical depth to do so. That is genuinely good for security, but it also adds volume to the disclosure pipeline that the CVE program and NVD have to absorb.
So the pressure on NVD is not arbitrary. It reflects a real change in how software is being built and how security research is being done.
Why this matters beyond the database itself
The NVD changes are a useful signal about where vulnerability management is heading, and what assumptions need to be revisited.
For a long time, security teams could operate with a relatively simple model: wait for NVD to enrich a CVE, pull the CVSS score, prioritize by severity, and patch from the top down. That model was always imperfect, but it worked well enough when CVE volume was lower and NVD enrichment was reasonably timely.
That model now has more cracks in it. Delayed enrichment means you may not have a CVSS score when a vulnerability is first disclosed. Triage-based prioritization means some vulnerabilities in your environment may sit in a lower-enrichment tier for longer. If your patching workflow depends heavily on NVD metadata being available and accurate, you need a backup plan.
The better model is one that does not depend on any single data source being complete. KEV tells you what is actually being exploited in the wild, which is often more operationally relevant than CVSS scores alone. Vendor advisories typically contain the most accurate and timely information about specific products. Threat intelligence feeds provide context about active exploitation campaigns. Used together, these sources give a more accurate picture than NVD alone ever did.
NIST is also expanding the CVE program itself
Alongside the NVD changes, NIST has been expanding the network of CVE Numbering Authorities. CNAs are organizations authorized to assign CVE IDs directly for vulnerabilities in their own products or within their scope of coverage. The expansion of CNAs is part of how the program has tried to scale assignment capacity, but it has also contributed to the volume problem by distributing the pipeline across more sources.
The result is a system where CVE IDs are published faster and in greater numbers than the enrichment infrastructure can keep up with. Addressing that imbalance requires either more enrichment capacity, smarter prioritization, or both. NIST's update is focused on the prioritization side.
What organizations should do with this information
The practical takeaways from NIST's announcement are fairly direct.
First, if your vulnerability management program treats NVD CVSS scores as the primary driver of prioritization, you need to add other signals. CISA's KEV catalog is a strong supplement, because it reflects actual exploitation rather than theoretical severity. Actively exploited vulnerabilities in the KEV catalog deserve immediate attention regardless of their NVD enrichment status.
Second, for any vulnerability in software your organization runs, check vendor advisories directly rather than waiting for NVD metadata. Vendors know their products and typically publish patching guidance faster than NVD enrichment catches up.
Third, be aware that your scanner or vulnerability management platform may be pulling from NVD in ways that create blind spots. Ask your vendor how they handle unenriched CVEs and what supplementary sources they use.
Fourth, invest in context beyond severity scores. A high-CVSS vulnerability in software you do not run is less urgent than a medium-CVSS vulnerability being actively exploited in software central to your operations. Scores matter, but exploitability, exposure, and business context matter more.
The bigger picture
The NVD update is a symptom of something larger. The volume of software being written, the number of people capable of finding vulnerabilities in it, and the pace at which disclosure pipelines are expected to operate are all increasing. The infrastructure that was built to track and communicate vulnerability information is being asked to scale faster than it was designed to.
That is not a criticism of NIST. It is an observation about where the field is. AI-assisted development and AI-assisted security research are both accelerating the cycle in ways that put pressure on every part of the system, from code review to patch testing to disclosure coordination to the databases that security teams rely on.
The organizations best positioned to handle this environment are the ones that have moved away from passive dependence on any single data source and toward active, context-aware vulnerability management. The ones most at risk are the ones still running a model built for a slower era.
NIST's update is a good prompt to audit which category you are in.
Sources: - NIST Updates NVD Operations to Address Record CVE Growth