A quiet policy shift at NIST has created a dependency gap in most corporate vulnerability programs. Here's what it means — and what to do about it.

On April 15, 2026, the National Institute of Standards and Technology made an announcement that barely registered outside of cybersecurity circles. But its consequences will ripple through boardrooms, IT budgets, and risk registers at companies of every size.

NIST, the federal agency that runs the National Vulnerability Database (NVD) officially stopped enriching most newly reported security vulnerabilities.

Not pausing. Not deprioritizing. Stopping.

If that sentence didn't land with the urgency it deserves, let me reframe it. For the past two decades, your security tools — the scanners, dashboards, and patch management platforms your team uses — have been pulling critical data from one central, free, public source: the NVD. That source just told you it can no longer keep up.

What Just Changed

Every time a security vulnerability is discovered and assigned a CVE identifier, it gets submitted to the NVD. NIST analysts then "enrich" that entry — adding a severity score, identifying which software products are affected, classifying the weakness type, and linking to patches or advisories. That enriched data is what your tools consume to tell you how serious a vulnerability is and whether you need to act.

Starting April 15, NIST will only perform that enrichment for three categories of vulnerabilities:

• CVEs listed in CISA's Known Exploited Vulnerabilities (KEV) catalog — meaning flaws already actively being used by attackers
• Vulnerabilities affecting software used by the U.S. federal government
• Vulnerabilities in software designated as critical under Executive Order 14028 — "Improving the Nation's Cybersecurity" issued by US President on May 12, 2021, mandating a massive modernization of federal cybersecurity.

Everything else gets a new label: "Not Scheduled."

That means no severity score from NIST. No affected product list. No weakness classification. No patch links. Just a CVE number, a name, and whatever minimal data the submitting organization provided.

Why Now? The Volume Problem No One Solved

This didn't happen overnight. NIST has been sounding quiet alarms since early 2024, when its backlog of unenriched CVEs started growing visibly. The agency increased its output dramatically — enriching nearly 42,000 CVEs in 2025, a 45% improvement over any prior year. It wasn't enough.

The math is stark: CVE submissions grew 263% between 2020 and 2025. Submissions in the first three months of 2026 were already one-third higher than the same period last year. Conservative forecasts put 2026 at 59,000+ total CVEs. Other analysts, accounting for AI-assisted discovery tools now being deployed at scale, put the number closer to 70,000 — before accounting for the full effect of AI vulnerability research platforms just entering the field.

Why This Is a Business Problem, Not Just a Security Problem

Most corporate vulnerability management programs are built on a simple premise: scan your environment, receive severity scores, patch in order of criticality. The entire workflow assumes the severity scores are there and that they're accurate.

That assumption just broke. Tools pulling CVSS scores from the NVD for unenriched CVEs will come back empty. Automated prioritization workflows that sort tickets by severity band will silently misfire — not crashing, not alerting, just quietly missing vulnerabilities that were never scored.

"Not Scored" will get treated as "Not Important." This is the most dangerous failure mode. In overburdened security teams, the operational reality is that unenriched vulnerabilities without a severity number will fall to the bottom of queues or never appear at all. Some of those vulnerabilities will be serious.

The liability exposure is real. If a breach occurs through a vulnerability that was reported, was in your environment, and was never prioritized because it lacked NVD enrichment, the question your lawyers and insurers will ask is: did you have a reasonable process for tracking vulnerabilities without severity scores? Most companies today cannot answer yes to that question.

The Scoring Gap No One Was Talking About

There's a second problem baked into the new policy that deserves its own conversation.

For CVEs that do get scored, NIST has announced it will no longer routinely produce its own independent CVSS score when the CVE Numbering Authority — the organization that submitted the CVE — has already supplied one. The assumption is that the submitter's score is good enough.

The data says otherwise.

Analysis of 1,567 CVEs where both NVD and GitHub Advisory independently assigned scores found that the two sources disagreed in the majority of cases. The largest single gap was 6.9 severity points. A significant cluster showed drift of 4.0 points or more — the difference between a vulnerability classified as medium severity and the same vulnerability classified as critical.

Going forward, more of the vulnerability data will carry scores from the organizations that found and reported the vulnerabilities. Those organizations have varying motivations, methodologies, and incentives. Treating those scores as equivalent to independent analysis is a risk that has now been formalized into the default.

What a Resilient Vulnerability Program Looks Like Now

The companies least exposed to this change are those that never fully outsourced their triage logic to NVD severity scores. Here's what they do differently — and what organizations still dependent on NVD enrichment need to build toward.

1. KEV membership as a primary signal, not a supplement. CISA's Known Exploited Vulnerabilities catalog is short, curated, and represents confirmed active exploitation. If a vulnerability is in the KEV, treat it as on fire. This list should sit at the top of your prioritization logic, above any CVSS score.

2. Asset exposure as a filter. A critical vulnerability in software you don't run is irrelevant. A medium vulnerability in an internet-facing system with no compensating controls is urgent. Map CVEs to your actual asset inventory before assigning remediation priority. This sounds obvious; most programs don't do it systematically.

3. Vendor advisories as a parallel track. Major software vendors publish their own security advisories — Microsoft Patch Tuesday, Cisco advisories, Adobe bulletins — with affected version data and severity assessments that don't depend on NVD. These should be integrated into your workflow as a direct data source, not as a fallback.

4. Exploit availability as a triage accelerator. Vulnerability intelligence platforms (Tenable, Qualys, Rapid7, and others) track whether public exploits exist for a given CVE. A vulnerability with a working public exploit — regardless of its NVD score — needs to move to the front of the queue.

5. Threat intelligence context. Is this type of vulnerability being actively targeted in your industry? Are there indicators that threat actors are scanning for it? This context doesn't come from NVD. It comes from threat intelligence subscriptions, ISACs, and vendor feeds. If you don't have those inputs, this is a good time to start.

The Honest Conversation to Have With Your Board

The NVD change provides a useful forcing function for a conversation many security leaders have been deferring: the vulnerability program as currently structured is not sufficient.

This isn't about buying more tools. It's about process design.

The questions worth asking:

• What happens when a CVE in your environment returns no severity score? Is there a documented process, or does it fall through?
• Who owns the decision on unenriched vulnerabilities? Is it automated, manual, or effectively nobody?
• What's your current coverage beyond NVD? Do you have vendor advisory integrations, exploit intelligence, or threat context — or are you single-source?
• Can your security team actually execute at current vulnerability volumes? The answer in most organizations is no, and that gap is growing.

The companies that use this moment to pressure-test their triage assumptions and build redundant data inputs will be in a materially better position than those waiting for NVD to solve its capacity problem. NIST has signaled it's working on automation and better tooling. There is no timeline. There have been timelines before.

The Bottom Line

The NVD is not going away. It remains a critical part of the vulnerability ecosystem. But it is no longer a universal enrichment service, and the operational assumption that it will tell you what matters and how urgently — for every vulnerability your scanners find — is no longer valid.

This is the moment to retire single-source dependency in your vulnerability program.

Your security team may already know what needs to change. The NVD announcement gives them the external evidence to make the case. Use it.