Understanding the CVE Ecosystem and NIST’s Changing Role

TL;DR NIST is changing how it prioritizes vulnerabilities for deeper analysis. This is a formal acknowledgment of what we, and other security firms, have been shouting for the last few years. CVE enrichment cannot keep pace with the volume of new CVEs being issued. These NIST changes will have impacts on smaller security teams that rely on that enriched data for deeper understanding and impact. However, the larger firms have already begun steering away from relying on deeper analysis in favor of self-review. But this is manageable if teams act. Companies need to take a proactive approach to their threat landscape and prioritize risk-based patch management.

What's what

If you have not seen the latest headlines, the National Vulnerability Database (NVD), operated by National Institute of Standards and Technology (NIST), announced that starting April 15, 2026, they will shift enrichment of Common Vulnerabilities and Exposures (CVE) prioritization from a "get to it when we can" approach to a firmer, prioritized model. The NVD has decided to align its enrichment prioritization on three main facets:

• CISA's Known Exploited Vulnerabilities (KEV) catalog
• federal government software
• critical software under Executive Order 14028

Everything else will be treated as "lowest priority" and will not be scheduled for immediate enrichment. This new approach feels focused on prioritizing government systems first, and that is because it is. This does not mean no enrichment will come, just less, and for some vulnerability types, a lot less.

Bishop Fox's Threat Enablement and Analysis (TEA) team has operated under a similar focused, true risk-based threat triage model for the last few years. Nate Robb, Senior Operator on the TEA team, explained the thought process in a previous blog post: Sipping from the CVE Firehose. Clients have found, and continue to find, benefit from this prioritized review as it helps narrow things down to what is critical to their infrastructure. Not every CVE warrants an "all-hands on deck" approach; in fact, we would argue that many of them do not.

Please continue to patch!

Even if the vulnerability is mostly benign for now, patching keeps you safer than not patching. The changes to NVD only help to highlight the need for others to adopt similar structures in their approach to security. We have seen some compare this to MITRE losing funding. This analogy is inaccurate; when MITRE was underfunded, we were going to lose a major player in the CVE issuing body. This maintains that process but loses the aftercare. What this does do is shift the burden back to internal security teams to truly understand their own attack surfaces. It will be painful at first, but we will manage in the long run. What it does not do is fix the growing problem of the increased number of CVEs being issued that need to be reviewed. For that, we need to look at those issuing the CVEs. But we have digressed enough already; that will need to be the focus of another blog post.

To understand the service that NIST provided, we must understand the process a little.

First, a CVE identifier (generally shortened to just CVE) contains two main parts prefixed with "CVE-": the year of issuance and the ID value (e.g., CVE-2026-12345). This allows the community to refer to the same vulnerability using the same unique identifier globally.

Second, CVE IDs are assigned by authorized organizations called CVE Numbering Authorities (CNAs). This includes MITRE, a federally funded organization, and other approved non-federal partners. Notably, NIST is not a CNA. It is the job of the CNA to write the initial CVE record and issue the CVE Identifier. As of this writing, there are more than 500 CNA partners worldwide that can issue CVEs; note that some partners can only submit CVEs for their own products while others can issue CVEs for any product.

Lastly, we need to establish a baseline for what is going to be covered by NIST moving forward. The update states they will focus on KEV, federal government software, and Executive Order 14028 software. The only publicly available list of federal software is the FedRAMP list. Executive Order 14028 contains no list of software either, but there is a list of the software categories they define in their first pass:

• software that controls access to data;
• cloud-based and hybrid software;
• software development tools such as code repository systems, development tools, testing software, integration software, packaging software, and deployment software;
• software components in boot-level firmware; or
• software components in operational technology (OT)

The major takeaway from the Order is they track "critical software," which they define as:

…[A]ny software that has, or has direct software dependencies upon, one or more components with at least one of these attributes: 

• is designed to run with elevated privilege or manage privileges;
• has direct or privileged access to networking or computing resources;
• is designed to control access to data or operational technology;
• performs a function critical to trust; or,
• operates outside of normal trust boundaries with privileged access

Just generic enough to give you the warm and fuzzies. The good in this is they are being very transparent with their focus! The bad is there does not seem to be any real transparency to what software this focus will review; at least, not a definitive one. That means the tier will be applied by analyst judgment, not a known lookup pattern, and that's another place where the community loses auditability.

This means fewer CVEs for your security team, right... right?

No. As stated prior, it is the job of a CNA to issue the CVE, not NIST. CNAs are the gatekeepers of the process and all roads lead to them. The researcher reaches out to a CNA and provides them relevant information: vulnerability, impact criteria, versions, description, etc. The CVE is reserved and assigned as a unique identifier. After some communications with the researcher and the vendor, the CVE is released publicly. This is the point where NIST steps in. They get the details, analyze the vulnerability, and add more color to it. All NVD data additions sit downstream of the CVE process. The NVD's value-add was always deeper enrichment after a CVE record was issued. NIST attaches additional context around the Common Vulnerability Scoring System (CVSS), Common Platform Enumeration (CPE), Common Weakness Enumeration (CWE) classifications, and cross-referenced links. And you thought we were done with acronyms. All that to say, it shows defenders' context around how easily an attacker can exploit their systems using this vulnerability and whether it is as bad as the researcher or vendor claims. Your teams will still need to be on guard as CVEs continue to roll in.

NIST has previously reported that CVE submissions more than tripled (263% growth) between 2020 and 2025, and early 2026 volume is running roughly a third higher than the prior year. The NVD enriched about 42,000 CVEs in 2025, which is 45% more than any previous year. This is not sustainable with manual review alone; while automations help, the key data points still need reviewing.

Reading about the increase is one thing, but visualizing takes it to another level. We took the liberty of graphing out the growth of reserved CVEs, publicly disclosed CVEs, and NIST Enriched CVEs. For clarity, a reserved CVE is a CVE issued by a CNA but has not been publicly released. This is why you may have seen some CVE-2024-XXXX vulnerabilities released in 2026. One note on the Enriched line before you read the chart: NIST's own 2025 figure is "nearly 42,000" enriched CVEs. Our chart shows 25,453. Both are correct. NIST counts any CVE their analysts touched in any way. We counted CVEs where NVD produced any detectable enrichment artifact in the public JSON feed: a Primary CVSS score, a CWE classification, or populated CPE configurations.

We can see in the graph the sharp growth that NIST described that started around 2016-2017. The yellow line tells the other half of the story. NIST enrichment grew steadily through 2023, peaked in 2024 at 29,817 CVEs, then fell to 25,453 in 2025, even while reservations kept climbing. The widening space between the pink Reserved line and the yellow Enriched line is the backlog NIST is now formalizing.

Why did the enriched line start falling around 2023? The roots of it go back to 2016-2017, when MITRE published the first formal CNA Rules and stopped being the bottleneck. The problem NIST is highlighting is not new. For years, researchers have complained about the CVE process being slow and cumbersome. So, they opened the doors to new CNAs and now we have an influx of data that needs massaging. We are on the other side of the gate now. In 2024, 40,077 new CVEs were issued, and another 48,244 followed in 2025. Most of those did not warrant equal attention from any defender. NIST is finally making policy out of what experienced triage teams have been doing informally all along: treating CVEs as a stream to be filtered, not a list to be completed. The signal to noise has always been an issue in this industry. NIST being overwhelmed is a symptom of the current CVE industry.

Where this leaves us

So why does this feel like a larger impact than it is? Because now the quiet part is being said out loud. NIST is drowning. Just as MITRE fixed the CVE-assignment bottleneck with CNA Rules, NIST needs a parallel fix for the enrichment bottleneck. The good news is the CVE Program has already built most of it, and NIST has started adopting it. CVE Record Format v5 lets CNAs populate deeper fields themselves, and the Authorized Data Publisher (ADP) role lets trusted third parties add enrichment directly to CVE records. As of this writing, there is only one approved ADP according to the CVE Programs ADP page. CISA's Vulnrichment is an ADP, and NIST has been surfacing that ADP data through the NVD 2.0 API since July 2024. That is a real step forward, and one a lot of the commentary around NIST is undercounting. The remaining gaps are scale and reach:

• Scale: CISA should not be the only ADP the NVD leans on. The model was designed for more, and it needs more.
• Reach: NIST's legacy data feeds still do not carry ADP-contributed enrichment, which means every downstream tool that has not migrated to the NVD 2.0 API misses the community's work entirely.

Fix those two, and the ecosystem is in better shape than any new tiering policy can deliver. The plumbing exists. It needs to be scaled up and plumbed through.

What it costs the rest of us

NIST did, and still does, provide a great service to the community. In fact, NIST is still going to be adding enrichment data to vulnerabilities. The automated scanners and companies that rely on that feed will continue to function as expected. But now NIST has the power to choose what to prioritize based on things that may not impact the broader industry. We do not have to agree with NIST's choice of approach, but it does reveal where its priorities are. Although focusing on government software first makes sense for a government agency, it does not map cleanly onto a private-sector's everyday defender attack surface. The downstream burden is real. When NIST stops routinely producing its own CVSS, CPE, and CWE data for non-priority CVEs, every consumer further down the pipeline inherits that gap: vulnerability scanners, SBOM tools, compliance pipelines, managed security providers. CVSS is improving but remains inconsistent across 500+ CNAs. In practice, "Not Scheduled" is going to mean "Not Actionable" for a large part of the industry.

While this has the feel of a large-scale impact on the industry, this should be treated no differently than when any piece of open-source software suddenly becomes deprecated or abandoned. Defenders should always prioritize protecting their systems and data, because the next big zero-day is usually closer than anyone thinks. We aren’t losing CVEs, we just might not have the same fidelity of information on each one.

What you can do about it

What this looks like in practice: when a new threat lands, ask some of the same questions our TEA team asks. Can it be exploited without authentication? Is the system reachable by external parties? Is the affected software running in the configuration the exploit requires? A "yes" to all three is a strong signal that the CVE belongs at the top of today's queue. A "no" anywhere does not mean you're safe, but this threat may not be your top choice for immediate remediation if there are other, more pressing threats. Everything still needs patching (see above). But patch in risk order, not severity order. That re-ordering, applied at scale against a known attack surface, is what risk-based triage looks like in practice. It is what our team does for clients every day. Whether you use Cosmos or run your own process, the principle is the same: figure out the risks first, because what counts as 'critical' for your environment is not the same as what counts as 'critical' for ours.

Stay safe out there!