NIST announced recently that it’s overhauling National Vulnerability Database (NVD) operations to keep up with record CVE growth.
The volume has outpaced their capacity to enrich every submission, so they’re changing the model. Only a subset of CVEs will receive full enrichment going forward. Everything else gets a new status label: “Not Scheduled.”
This is a good thing. Genuinely.
But here’s the part nobody is saying: more CVE data, faster, doesn’t reduce risk. Instead, it exposes how broken everything downstream of the CVE already is. The enrichment and prioritization work NIST can no longer do at scale now falls on your vulnerability management backlog and the people responsible for clearing it.
Learn what NIST actually changed, what it means for your CVE prioritization workflow, and where the real bottleneck in CVE remediation sits.
What NIST Actually Changed
The announcement revealed several interesting details, including how CVE submissions grew 263% between 2020 and 2025, that Q1 2026 is running nearly a third higher than the same period last year, and how NIST enriched almost 42,000 CVEs in 2025, 45% more than any previous year, and it still wasn’t enough.
So, NIST is moving to a risk-based enrichment model with three categories being prioritized:
- CISA KEV catalog entries: CVEs with confirmed active exploitation. NIST’s goal is enrichment within one business day.
- Federal government software: CVEs affecting software used across federal agencies.
- Critical software under EO 14028: CVEs affecting software categories that NIST has formally defined as critical infrastructure, as defined in EO 14028.
Everything else still appears in the NVD but carries a “Not Scheduled” label. No NIST-provided severity score, product enumeration, or enrichment data. Teams can request enrichment for specific CVEs by emailing NIST directly.
The backlog gets the same treatment. Every unenriched CVE published before March 1, 2026, is being reclassified as “Not Scheduled” in batches over two weeks. NIST isn’t clearing the backlog, but rather acknowledging that the backlog can’t be cleared at the current volume.
Two Other Important Changes
The announcement also flagged two additional changes.
- NIST will no longer provide a separate severity score when the submitting CNA has already scored the CVE.
- Previously enriched CVEs will only be re-analyzed if a modification materially impacts the enrichment data.
Both remove layers of independent validation that many vulnerability programs treat as default inputs. NIST also updated its NVD Dashboard with real-time status reporting and introduced new status labels to reflect the changed workflow.
What This Means for Your Vulnerability Program
If your prioritization workflow depends on NVD enrichment data, you now have a coverage gap. Most CVEs your scanners find won’t be in the KEV catalog, won’t affect federal software, and won’t qualify under EO 14028. They’ll sit in “Not Scheduled” with no NIST-provided severity score and no product context.
That shifts the prioritization burden entirely to your team. The CVSS score your CNA provided might be all you get. Whether that score reflects actual risk in your environment is a question NIST was never answering anyway, but now there’s no second opinion on the table.
The backlog reclassification matters too. If your team had open tickets waiting on NVD enrichment for pre-2026 CVEs, that enrichment isn’t coming. Those CVEs aren’t queued because they’re shelved.
The practical effect: more CVEs flowing in, fewer arriving with usable context, and the same team expected to sort through all of it. Detection tools create more work, not outcomes, when there’s no remediation capacity behind them.
Why the CVE Was the Easy Part
Detection has never been the bottleneck because your scanners already see everything.
The work that actually reduces risk starts the moment a CVE lands in your environment. And it has nothing to do with the CVSS score. Getting this right requires answering the hard question, like:
- Is this reachable in my environment?
- Does it touch production data, or is it sitting in a sandbox nobody uses?
- Who owns the workload — platform, app team, or that contractor who left in March?
- Is the patch safe to apply, or will it break the service it’s protecting?
- What’s the right fix path — image rebuild, config change, identity tightening, or all three?
That’s where months go, and where high-severity findings die in a queue. Cloud vulnerability prioritization based on CVSS alone doesn’t account for any of it. Not because teams don’t know about them, but because the investigation, ownership routing, and safe execution required to close each one take more capacity than most cloud security teams have, causing mean time to remediate (MTTR) to rise.
NIST fixing NVD enrichment doesn’t touch any of it. In fact, it makes the pile taller. More enriched CVEs flowing in faster means a longer, sharper, better-prioritized list of work your team still can’t get to.
One problem: better visibility into unfinished work is still unfinished work.
What Actually Moves the Needle
Four things have to happen between “CVE published” and “risk reduced.” Every one of them is where teams stall.
1. Prioritization That Reflects Your Environment, Not the CVE’s Score
A 9.8 CVSS on a workload nobody can reach is less urgent than a 6.4 on the path to your customer database. Severity scores don’t know that, but CTEM-aligned prioritization does.
This is where environment-aware scoring makes all the difference. With Tamnoon, Tami scores every alert against the actual conditions in your cloud: reachability, identity exposure, data adjacency, and business context. The list shrinks from thousands to dozens, and your engineers stop processing noise and start working on what moves the risk needle.
2. Routing the Work to the Human (or System) Who Can Actually Fix It
The biggest pipeline blocker is ownership ambiguity, not visibility. CVEs land in a security queue, get bounced to a platform team, get reassigned to an app team, and lose two weeks before anyone touches them.
Tami maps every prioritized exposure to the right service owner, routes through the workflows those teams already use, and tracks the fix to completion. Mobilization becomes a workflow, not a coordination problem.
3. Investigation That Uses Context, Ensuring Correct Fixes the First Time
Most automation tools throw a recommendation over the wall and call it done. That’s how production breaks.
Tami pulls in the surrounding context before proposing a fix: dependencies, IAM relationships, network paths, recent changes, and blast radius if the patch fails. Your team gets a full investigation plan for every alert that needs human judgment. For the alerts that don’t, Tami executes safely on its own.
4. Safe Remediation with the Confidence to Prove It
The fear every security leader carries: what if the fix breaks production? It’s the single biggest reason remediation stalls, and why most automation initiatives stall.
Every Tami action carries a Remediation Confidence Indicator (RCI): SAFE, RISKY, or UNSAFE, with the reasoning behind the classification. This is what makes agentic remediation production-safe at scale.
Who’s Closing the Tickets When the List Doubles?
NIST solved the data quality layer underneath detection, which is necessary, but the work that actually reduces risk happens entirely downstream of what they announced.
This includes prioritizing what matters in your environment, routing to the right owner, investigating with context, and executing without breaking production.
Faster CVE intake is welcome. The question every security leader needs to answer next is the one nobody likes. When your visible workload doubles, do you have the capacity and the confidence to close it?
That’s the gap Tamnoon was built to close. Book a demo today to see how it works.
FAQs
What did NIST change about the NVD?
NIST moved to a risk-based enrichment model. Only CVEs in the CISA KEV catalog, federal government software, and critical software under EO 14028 will receive full enrichment. Everything else is labeled “Not Scheduled” and won’t be enriched unless manually requested.
What does “Not Scheduled” mean for a CVE?
It means NIST won’t provide a severity score, product enumeration, or enrichment data for that CVE. The CVE still appears in the NVD, but with no additional context beyond what the submitting authority provided.
Why did NIST make this change?
Volume. CVE submissions grew 263% between 2020 and 2025, and Q1 2026 is running a third higher than last year. NIST enriched a record 42,000 CVEs in 2025 and still couldn’t keep pace. The new model focuses limited resources on the highest-impact vulnerabilities.
How does this affect CVE prioritization for cloud security teams?
Teams that relied on NVD enrichment data to prioritize now have a gap. Most CVEs from cloud scanners won’t qualify for NIST’s priority categories. That means the prioritization burden, including severity assessment and environment-specific context, shifts entirely to your team.
Does faster CVE enrichment reduce risk?
No. Enrichment improves the quality of vulnerability data, but risk only decreases when someone actually remediates the finding. Faster enrichment without remediation capacity just builds a better-organized backlog.
What is the CVE remediation gap?
The distance between a published CVE and a closed fix. It includes investigation, ownership routing, safety assessment, and execution. Most security teams stall in this gap because the work requires environment-specific context and cross-team coordination that no scanner or database provides.
