top of page

NIST Will Enrich Fewer CVEs: What Businesses Need to Know

  • Apr 20
  • 5 min read
NIST

For years, many security teams treated the National Vulnerability Database, or NVD, as the default source for vulnerability context. They looked to it for severity scores, affected product details, and the extra information needed to decide what to patch first. That model is changing. NIST announced that it will no longer automatically enrich every CVE in the NVD, and that shift has real consequences for businesses that rely on scanners, dashboards, and patching workflows built around NVD timing.


This is not just a technical change. It is an operations issue, a risk management issue, and for many companies, a leadership issue. When the public source your team depends on provides less context for more vulnerabilities, your internal process has to get stronger.


What changed in the NVD


On April 15, 2026, NIST said it would move to a risk-based model for CVE enrichment. Going forward, it will prioritize enrichment for three groups of vulnerabilities: CVEs in CISA’s Known Exploited Vulnerabilities catalog, CVEs affecting software used by the federal government, and CVEs affecting “critical software” as defined under Executive Order 14028. CVEs outside those categories will still appear in the NVD, but they may be categorized as lowest priority or “not scheduled” for immediate enrichment. Users can request enrichment for specific records, but it will happen as resources allow.


NIST also said it will no longer routinely publish a separate NIST severity score when the CVE Numbering Authority, or CNA, already supplied one. In addition, NIST will only reanalyze previously enriched CVEs when later changes materially affect the enrichment data. As part of the operational reset, backlogged CVEs with an NVD publish date earlier than March 1, 2026, are being moved into the “Not Scheduled” category unless they fall into the new priority path.


Why the change? Volume. NIST said CVE submissions increased 263% between 2020 and 2025. It also said submissions in the first three months of 2026 were nearly one-third higher than the same period the year before. Even after enriching nearly 42,000 CVEs in 2025, which NIST said was 45% more than any prior year, the agency concluded it could not keep up under the old model.


Why this matters to businesses, not just security teams


More CVEs will appear without full NIST context

The first business takeaway is simple: more vulnerabilities will still be listed publicly, but many will arrive without the same NIST-added detail your tools or team may be used to seeing. That can affect how quickly you identify what is exposed, what is urgent, and what maps to actual assets in your environment. Several industry outlets and analysts highlighted the same concern: the issue is not that CVEs disappear, but that defenders may have less centralized context to prioritize them.

If your current process depends on the NVD to do the thinking for you, this change will expose that weakness.


“No score yet” does not mean “low risk”

A common mistake inside busy IT and security teams is to treat missing or delayed enrichment as a sign that a vulnerability is not urgent. That was risky before, and it is even riskier now. CISA’s KEV catalog exists precisely because active exploitation matters more than raw severity alone, and FIRST’s EPSS model is built around the probability that a CVE will be exploited in the next 30 days. In other words, a missing NIST score is not the same thing as low business risk.


For executives, this matters because patching is always a resource decision. Teams do not need more noise. They need a better way to separate “high likelihood and high impact” from “visible but lower priority.”


Backlog and “Not Scheduled” records can create blind spots

NIST’s backlog is not brand new. The agency publicly acknowledged a growing backlog in early 2024 and said at the time that it was already prioritizing the most significant vulnerabilities while exploring longer-term fixes. The new April 2026 change is the clearest sign yet that the old model is no longer sustainable as a universal enrichment service.


For businesses, the risk is operational blind spots. A vulnerability may be real, relevant, and urgent to your environment even if it is no longer getting immediate NVD enrichment. That is especially true for companies with internet-facing systems, remote access tools, cloud workloads, line-of-business applications, and third-party software dependencies.


What business should do now


Stop relying on one vulnerability source

This is the moment to retire the idea that one public database should drive your full vulnerability program. The NVD is still important, but it should be one input, not the only input. Security teams should also pull from vendor advisories, CISA’s KEV catalog, EPSS, the GitHub Advisory Database, and OSV for open source exposure. GitHub says its advisory database includes CVEs and GitHub-originated advisories, and OSV describes itself as a distributed vulnerability database for open source.

For many businesses, especially mid-market companies, the bigger issue is not lack of feeds. It is lack of process. Someone has to decide which sources matter, how to reconcile conflicting data, and how to turn that into action.


Prioritize based on exploit risk and business exposure

A mature vulnerability program should weigh at least five things together:

  • active exploitation or presence in KEV

  • exploit likelihood signals such as EPSS

  • whether the affected system is internet-facing

  • whether the asset is business-critical or regulated

  • whether compensating controls already reduce the risk


That is how you move from “patch by score” to “patch by business risk.”

A healthcare group with remote clinics, a law firm handling confidential documents, or a manufacturer with exposed VPN and OT dependencies should not wait for perfect public enrichment before making decisions. They need a repeatable, internal prioritization model tied to real exposure.


Tighten asset visibility and patch governance

This NIST change makes asset inventory more important, not less. You cannot prioritize what you cannot map. If your team does not have a reliable picture of external assets, cloud workloads, critical SaaS dependencies, privileged systems, and unsupported software, then reduced public enrichment will hurt more.


Now is a good time to tighten:

  • asset inventory and ownership

  • patch SLAs by asset criticality

  • exception handling and risk acceptance

  • vulnerability review meetings

  • executive reporting on remediation backlog and exposure trends


The goal is not to patch everything instantly. The goal is to prove that the riskiest items are being addressed in a disciplined way.


Add leadership-level oversight

This is where cybersecurity leadership matters. A vulnerability program is not just a scanner and a ticket queue. It is a business decision engine. Someone has to set priorities, challenge false assumptions, work with IT and vendors, and explain risk in plain English to leadership.


That is one reason more businesses are leaning on vCISO support. When public data sources become less complete or less predictable, companies need stronger internal governance, clearer triage standards, and better executive reporting.


What this means for mid-market and regulated organizations


For mid-sized businesses in Los Angeles and across the U.S., this change is likely to hit hardest where teams are already stretched thin. Many organizations do not have a dedicated vulnerability research function. They rely on MSPs, internal IT, a few tools, and public sources to make patching decisions. That can work, until the underlying source changes.


Regulated organizations face a second problem. Auditors, insurers, customers, and boards do not just want to hear that vulnerabilities are scanned. They want to know how risk is prioritized, who owns remediation, how exceptions are handled, and whether the company can show a defensible process.


That is the real lesson here. The NVD change is not a reason to panic. It is a reason to mature.


How Purple Shield can help


At Purple Shield Security, we help companies turn vulnerability management into a business-led process instead of a tool-led routine.


That includes:

  • reviewing your current vulnerability workflow

  • identifying where you rely too heavily on one data source

  • improving prioritization using exploitability, exposure, and business impact

  • aligning patch governance with leadership reporting

  • strengthening incident readiness when a critical vulnerability breaks fast


For business owners and executives, the value is simple: fewer blind spots, clearer priorities, better reporting, and faster decisions when something serious hits.


 
 
bottom of page