In April, NIST changed how the National Vulnerability Database works. It now enriches only CVEs in CISA’s Known Exploited Vulnerabilities catalog, CVEs that affect federal government software, and CVEs in critical software as defined under Executive Order 14028. Everything else is marked “Lowest Priority” and is not scheduled for enrichment, including the backlog from before March 1. NIST cites volume as the reason, since submissions grew 263% between 2020 and 2025.
NIST has now issued a request for information on modernizing the NVD, asking for input from the people who work with this data every day. We plan to respond.
Gluware works on the network side of this problem, across routers, switches, firewalls, and load balancers from many vendors. More recently, that work has expanded to medical and IoT devices. Our perspective comes from the practical work of turning vulnerability data into answers about the devices our customers actually operate.
Missing vulnerability data can make a scan look clean when it isn’t
Enrichment adds product applicability data and, often, a severity score to a CVE. Tools that check your devices against the NVD depend on that data to determine whether a vulnerability applies. When a CVE hasn’t been enriched, those tools don’t raise an error. Instead, they find no match, which reads as “not affected.” Nothing in that workflow tells you that the CVE was never assessed in the first place.
NIST’s prioritization is understandable given the volume. The problem is that the rationing is invisible, which creates downstream risk. A clean scan could mean a device isn’t affected, or that nobody ever assessed the CVE. The report looks the same either way, leaving the team responsible for the device without a way to tell the difference.
Enriched CVEs are obviously helpful, but they present a different problem. Applicability data identifies an affected release, but doesn’t establish whether your particular device is exposed. Suppose a routing protocol bug affects a release that two of your devices are running. One has the vulnerable feature enabled; the other doesn’t. A scanner would flag both. However, one needs an emergency change window, while the other can wait.
In most organizations, sorting out that difference still requires manual work. Someone has to read the advisory, pull the device configurations, and determine which findings represent actual exposure. As CVE volume rises, with AI-assisted discovery pushing it higher, that manual assessment is the first part of the process to break down.
What we’d ask NIST for
We would start by making the rationing visible. From there, we would focus on making the data that does get enriched easier for machines to use.
First, unenriched CVEs should be labeled as unenriched in a machine-readable field. A tool needs to be able to distinguish “assessed, not affected” from “not assessed,” so that the people using it can understand what the result means. NIST should also publish its prioritization criteria and provide a request process that can scale with the volume. Today, requesting enrichment means sending an email.
Second, the enriched data needs to be precise enough to use against actual devices. Affected-product entries should allow a tool to compare them against a device’s specific version. The CPE update NIST has started is a good step, particularly for hardware. Exploit conditions also belong in structured fields. If a flaw only matters when a particular feature is enabled, a tool should be able to read that condition directly, rather than depend on someone finding and interpreting it in the description.
Third, fixes should be published in a machine-readable form. Fixed versions, mitigations, compensating controls, and workarounds are all more useful when automation can use that information directly. Teams need that information to move from identifying exposure to deciding what they can do about it.
Finally, if V-etalon or other AI is going to fill gaps in the data, the records need to identify which fields came from a vendor, which were inferred, and the confidence level of each inference. A tool acting on a record needs to know where its data came from and how much confidence to place in it.
IoT and Medical devices still have a significant gap
Operating systems fall within NIST’s critical software categories, so CVEs affecting Windows or Linux running on a medical or IoT device are likely to continue receiving enrichment. However, that doesn’t cover everything running on the device.
The gap is higher up the stack. NIST’s own explanatory material on the critical software definition recommended leaving embedded software and firmware out of the first phase, which is where much of a medical or IoT device’s own software lives. As a result, vulnerabilities in the device maker’s own applications and firmware are at risk of being marked as not scheduled for enrichment, unless a CVE reaches the KEV catalog first.
Gluware has an IoMT exposure solution for these devices. It assesses what is actually installed to determine which vulnerabilities a given device is exposed to. That work depends on the quality of the underlying vulnerability data, including whether the relevant CVEs have been enriched.
Here’s what we’d ask for from NIST: Use what device makers already have to produce. Under FDA rules, medical device manufacturers already provide a software bill of materials for newly-connected networked devices. NIST could ask makers to supply applicability data in a standard, machine-readable form, so this category could be enriched without adding analyst workload.
Where we come in, and how to respond
Our Exposure Management capability addresses the question at the device level. It checks a CVE against each device’s actual version and configuration to determine whether that device is exposed. When a device is exposed, it helps build the remediation.
If you run or secure networks, or manage fleets of IoT or IoMT devices, we encourage you to read the RFI and submit a response to NIST by October 13. The areas most relevant to our work are risk assessment and prioritization, remediation, and vulnerability data and standards. These are also areas where the experience of people working with the data every day can help inform what NIST does next.
We are preparing our own response and would be happy to talk with others working through the same questions.
