
NIST Just Changed How It Tracks and Prioritizes CVEs
For years, security teams built their entire vulnerability management prioritization around one assumption: NIST will enrich every CVE. NIST just proved that wrong.
On April 15, 2026, CVE submissions had grown 263% since 2020. NIST enriched a record 42,000 CVEs in 2025, its highest ever, and Q1 2026 was already running 33% ahead of Q1 2025. The volume broke the model.
Now, NIST only enriches CVEs tied to active exploits, federal software, or critical infrastructure. Everything else goes to "Not Scheduled."
Your scanner does not tell you that.
What the NVD actually does and why enrichment matters
The NVD is where a raw CVE entry becomes useful. When a vulnerability gets submitted, it is just an ID and a description. NIST takes that entry and adds the context security teams actually work with: CVSS severity scores, CPE product identifiers, references, and weakness classifications.
That enriched data is what feeds your scanner, your patch management platform, your SIEM, and your compliance workflows. Strip the enrichment out and you have a number with no actionable context.
This is why the NVD CVE prioritization change hits harder than it looks on the surface. When NIST stops enriching a CVE, it does not disappear from the database. It sits there, listed, with no severity score and no product mapping. Your tools pull it in. Your dashboard shows it. But the data your team needs to act on it is missing.
Security teams have been operating on the assumption that every CVE in the NVD is a complete record. From April 15, 2026, that assumption no longer holds.
The CVE surge that broke the old model
The volume problem did not appear overnight. It has been building for years, and the numbers make it hard to ignore.
CVE submissions grew 263% between 2020 and 2025. To put that in perspective, NIST enriched nearly 42,000 CVEs in 2025, which was 45% more than any previous year. A record output by any measure. And it still was not enough to clear the backlog.
The backlog itself started forming in early 2024. NIST could not enrich CVEs fast enough to match the rate they were coming in. By the time 2026 arrived, Q1 submissions were already running 33% ahead of the same period last year. There was no trajectory where the old model survived this.
The NIST NVD update 2026 is a direct response to this reality. NIST was not sitting on unused capacity. It was already running at its highest throughput ever, and the gap between submissions and enrichment kept widening. Adding more manual analysts was never going to close that gap at this scale.
So NIST did what any operation does when demand permanently outpaces capacity. It stopped treating all CVEs equally and built a system around where the real risk sits.
How the new prioritization model actually works
The NIST NVD update 2026 introduces a three-tier system. Not every CVE gets the same treatment anymore, and the criteria for what gets enriched are specific.
Tier 1: CISA KEV catalog CVEs
If a CVE appears in CISA's Known Exploited Vulnerabilities catalog, NIST targets enrichment within one business day of receipt. These are vulnerabilities with confirmed active exploitation in the wild. They sit at the top of the NVD CVE prioritization queue for good reason.
Tier 2: Federal government software
CVEs affecting software used within the federal government get enriched as a priority. Given that federal agencies are high-value targets and operate under strict compliance requirements, this tier makes operational sense.
Tier 3: Critical software under Executive Order 14028
CVEs for software classified as critical under EO 14028 also get prioritized for enrichment. This covers software that performs functions critical to national security, economic security, or public health and safety.
Everything outside these three tiers gets labeled "Not Scheduled" in the NVD. The CVE is still listed. It is still publicly visible. But the CVE enrichment process stops there unless someone specifically requests it.
That request mechanism exists. Any user can email nvd@nist.gov to ask NIST to enrich a specific unscheduled CVE. NIST will review it and schedule enrichment as resources allow. It is not a guarantee, but it is an option most teams do not know about.
One more thing worth flagging. NIST also acknowledged that this tiering system will not catch every high-impact CVE. A vulnerability outside these categories can still cause serious damage to the systems it affects. The prioritization is about systemic risk at scale, not individual impact.
Understanding the new CVE status labels
Alongside the prioritization changes, NIST updated its CVE status labels to communicate enrichment state more clearly. Here is what each status means when you pull data from the NVD:
| Status | What it means |
|---|---|
| Awaiting Analysis | CVE received, enrichment not yet started |
| Undergoing Analysis | NIST is actively enriching this CVE |
| Analyzed | Enrichment complete, CVSS score and CPE data available |
| Modified | The CVE record has been updated after enrichment |
| Modified After Enrichment | CVE was enriched, then modified, and NIST has NOT re-analyzed it |
| Not Scheduled | CVE does not meet prioritization criteria, no enrichment planned |
| Rejected | CVE was withdrawn or determined to be invalid |
The two statuses that matter most right now are "Not Scheduled" and "Modified After Enrichment." Both are new signals that most tools are not surfacing to end users yet. Full status definitions are available on the NVD vulnerability status page at nvd.nist.gov/vuln/vulnerability-status.
The NVD update did not stop at prioritization
The prioritization model is the headline, but NIST made three other operational changes in the same announcement. Each one has a direct effect on how vulnerability management prioritization works in practice.
No more duplicate severity scoring
Until now, NIST has provided its own CVSS score for every CVE, even when the CVE Numbering Authority that submitted it had already attached a score. That duplication is ending. Going forward, NIST will not routinely produce a separate severity score for CVEs that already carry one from the submitting CNA.
For most teams, this means the CVSS score on a given CVE will now come exclusively from the CNA that filed it. NIST will no longer validate or independently score it unless specifically requested. CNA scoring quality varies. Some CNAs are thorough. Others are not. That variance now lands directly in your vulnerability management workflow with no independent check on it.
One additional layer worth understanding. NVD supports both CVSS v3.1 and the newer CVSS v4.0 scoring standard. CNAs may submit only one version, and many still default to v3.1. Without NIST independently scoring CVEs, a vulnerability in your environment may only carry a v3.1 score when a v4.0 assessment would produce a materially different severity rating. CVSS v4.0 introduced finer-grained metrics around exploit maturity and safety impact that v3.1 does not capture. If your prioritization logic depends on CVSS scores, know which version you are working with and where it came from.
Modified CVE re-analysis is no longer automatic
Previously, if a CVE was modified after NIST had already enriched it, NIST would re-analyze the full entry. That policy is gone. NIST will now only re-analyze a modified CVE if the modification materially affects the enrichment data.
In practice, this means a CVE in your environment could be updated with new information, and your NVD-sourced data may not reflect that change. When this happens, the CVE gets a status of "Modified After Enrichment." That status is a data quality signal. It means the record was once enriched, something changed, and NIST has not reviewed whether that change affects the severity score, CPE mapping, or any other enrichment field. If you are consuming NVD data programmatically, treat "Modified After Enrichment" as an incomplete record until re-analysis is confirmed. Teams can request a re-analysis via email, but it will not happen automatically.
The backlog is being shelved
This one is significant. The CVE backlog that formed from early 2024 onwards is not being cleared. Every unenriched CVE with a publish date before March 1, 2026, is being moved to "Not Scheduled." NIST will consider enriching them under the new prioritization criteria as resources allow, but there is no timeline attached to that.
If your environment contains CVEs published before March 2026 that were never enriched, they are now officially in the backlog queue with no scheduled enrichment date. The only exception is CVEs already in the CISA KEV catalog, which NIST has always prioritized and are not part of the shelved backlog.
What this means for your security program right now
The NIST NVD update 2026 does not just change how NIST operates. It changes what your security program can rely on and where it has blind spots it did not have before.
Your scanner is pulling incomplete data, and you may not know it
Most vulnerability scanners consume NVD data directly. When a CVE sits in "Not Scheduled" with no CVSS score and no CPE mapping, your scanner still ingests the entry. It just has nothing useful to work with. Depending on how your tool handles missing enrichment data, that CVE may surface with no severity rating, get scored incorrectly, or get skipped entirely. None of those outcomes are acceptable in a production environment.
- Audit which CVEs in your current pipeline fall outside the three prioritized tiers
- Check how your scanner handles CVEs with missing CVSS scores or CPE data
- Do not assume a CVE appearing in your dashboard has complete enrichment behind it
If you are running regular CVE scanning and relying on NVD as your only data source, this gap is active right now.
The KEV catalog needs to be a first-class input in your workflow
NIST has effectively confirmed that CISA's Known Exploited Vulnerabilities catalog is the highest-priority signal in the CVE enrichment process. If you are not already tracking KEV directly and feeding it into your vulnerability management prioritization logic, start now.
- Subscribe to KEV catalog updates directly at cisa.gov rather than waiting for your scanner to surface them
- Any CVE on the KEV list will be enriched by NIST within one business day, making it the most reliable NVD signal available
- Build KEV status as a first-tier filter in your remediation SLA logic
CNA-provided CVSS scores need more scrutiny
With NIST stepping back from independent severity scoring, the scores on most CVEs will come solely from the CNA that submitted them. CNA quality is inconsistent. Some organizations score conservatively. Others inflate severity. Without NIST's independent validation sitting on top of that, your team needs to apply more judgment to severity scores rather than treating them as ground truth.
- Check which CVSS version the CNA submitted: v3.1 or v4.0 scores can differ significantly
- Cross-reference high-severity CVEs against threat intelligence sources before prioritizing remediation
- Flag CVEs where the only available score is CNA-provided and treat them as unvalidated until proven otherwise
This is exactly why CISOs are moving toward AI-driven vulnerability prioritization rather than relying on a single score from a single source.
Use the request mechanism
Most teams will never know that emailing nvd@nist.gov can get an unscheduled CVE moved into the enrichment queue. If you identify a CVE that affects a critical system in your environment and it sits in "Not Scheduled," submit a request.
- Email nvd@nist.gov with the CVE ID and a brief justification
- NIST will review and schedule enrichment as resources allow
- This is not guaranteed, but it is the only lever available outside the three prioritized tiers
Compliance frameworks tied to NVD data need a second look
If any part of your compliance reporting, audit evidence, or risk scoring pipeline pulls directly from NVD enrichment data, that pipeline now has gaps.
- Identify which compliance controls rely on NVD-sourced CVSS scores or CPE data
- CVEs in "Not Scheduled" or "Modified After Enrichment" status will appear as incomplete records
- Review how your tools interpret missing enrichment data and whether that creates false negatives in your risk scoring
Teams adopting Continuous Threat Exposure Management (CTEM) are better positioned here because they do not depend on a single enrichment source to drive prioritization decisions.
Where NIST is heading next
The operational changes NIST made on April 15 are not the end state. NIST was explicit about this. The risk-based triage model is a bridge, not a permanent fix. The destination is automated enrichment systems and workflow enhancements built to handle CVE volumes at scale without manual processing bottlenecks.
NIST has not published a timeline for those systems. What it has done is update the NVD Dashboard to reflect real-time CVE status and statistics across all entries. That is a small but meaningful signal. It shows NIST is investing in transparency and tooling infrastructure, not just managing the immediate backlog problem.
The broader direction is clear. Manual enrichment of every submitted CVE is a model that does not survive the current growth trajectory. The 263% submission increase between 2020 and 2025 is not an anomaly. CVE volume will keep climbing as software complexity grows, as more researchers submit findings, and as the CVE program continues expanding its network of numbering authorities.
Automation in the CVE enrichment process is the only path that scales. When NIST builds and deploys those systems, the NVD CVE prioritization model will likely evolve again. The tiers may shift. The "Not Scheduled" category may shrink. Enrichment turnaround times may improve significantly.
Until then, the current model is what security teams have to work with. The gap between CVE submission volume and enrichment capacity is real, and it is not closing anytime soon. Building your vulnerability management prioritization around that reality is the practical move right now.
The NVD you relied on yesterday is not the NVD you have today
NIST made a calculated operational decision under real pressure. The CVE flood is not slowing down, and the old model of enriching every submission was always going to hit a wall. April 15, 2026, is just when that wall became official policy.
The risk-based approach is logical. Prioritizing actively exploited vulnerabilities, federal software, and critical infrastructure over everything else is a defensible call. But it creates coverage gaps that did not exist before, and most security teams are not set up to handle them yet.
The security programs that feel this the least will be the ones that stop treating NVD enrichment as a given. They will track the KEV catalog directly, apply independent judgment to CNA-provided severity scores, audit their CVE pipeline for "Not Scheduled" entries, and use the request process when it matters.
The ones that feel it the most will be the ones that keep assuming their scanner has complete data.
NVD just told you it cannot cover everything. The question is not whether you have gaps. The question is whether you know where they are.
Strobes finds them before they find you. Curious what your environment looks like right now? Schedule a demo.