I’ve been in security a little over twenty years, long enough to remember formatting pentest reports by hand in Word. For a stretch of that time, I was the security director on the receiving end of those reports. No shortage of findings would come through, but nobody was handing me headcount for addressing all of them. What I really needed to know was which findings to chase that month and which ones would sit.
I bring it up now that NIST has announced that the National Vulnerability Database (NVD) will stop attempting to enrich every reported CVE. Vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog now get analyst attention within a business day, as does software the federal government runs (along with anything marked critical under Executive Order 14028). The rest still get listed, just tagged lowest priority and not scheduled for enrichment. Around 29,000 backlogged CVEs published before March 1st moved into that bucket in one shot, and NIST will no longer routinely add its own severity score when whoever filed the CVE already attached one.
Blame the math, not the agency
It’s pretty hard to blame them with submissions up 263% since 2020. The first three months of 2026 ran almost a third hotter than the same window last year, and NIST got through roughly 42,000 records in 2025 and still fell further behind. A bigger budget line isn’t fixing that problem.
Much of the reaction I’ve seen is frustration aimed at the agency, and that frustration very recently went official. The Commerce Department’s inspector general released a report faulting NISTs planning for the backlog, and NIST pushed back hard on the framing. Watching two arms of the government argue over whose fault this is misses the point for anyone with a patch queue to run. A small federal team was never going to score every software flaw on earth fast enough to feed everyone’s patching queue. Anyone who watched enrichment nearly grind to a halt back in the spring of 2024 saw this coming, and betting a program on NIST keeping up was always a gamble.
It can be a tempting answer to then lean on the scores that vendors and researchers attach when they file a CVE. In my experience that coverage is spotty across the industry, though, and those scores draw far less outside scrutiny than NIST’s did. A vendor grading the severity of its own bug also has a proverbial thumb on the scale. I’d treat them more as a data point, much less as a verdict.
When 9.8 doesn’t equal 9.8
Severity-first triage was creaking anyway. I’ve watched two findings with identical 9.8 scores mean wildly different things, one sitting on a lab box with no path to anything of value, the other on an internet-facing system tied to revenue with a public exploit going around. Funneling both into the same queue because they were the “same rating” was convenient, but not necessarily an efficient or effective security strategy.
Plenty of teams saw the same thing and patched around it. A script gets written to pull NVD fields into a spreadsheet, then the SLA clocks start based on severity bands, then somebody adds a routing rule that cuts a ticket whenever a score crosses 7.0, and soon enough half the program runs on a dashboard that goes blank if the score field never populates. Duct tape and bailing wire, basically, and I say that with some affection because I’ve built my share of it! The catch is that every bit of it assumes the upstream data arrives. Analysts who have studied the new criteria figure the prioritized categories cover maybe 15-20% of incoming volume, which leaves a long tail of CVEs that may never get a NIST score or product mapping at all.
Walk your own triage logic first
If I were back in the CISO chair I’d walk the triage logic end to end and find every place a missing CVSS field could clog the workflow, which would determine every SLA trigger or audit control keyed to a threshold that may simply never populate. Next, I’d take stock of what the program can answer on its own regarding the risk presented by the new, sparse CVE data. Is the asset internet-facing? Does it sit on a known attack path? Has anyone seen exploitation in the wild, and does the same finding keep turning up across the environment? None of that was coming out of NIST anyway, because it lives in your scan data, your pentest results, your asset inventory, your remediation history, etc.
The compliance side deserves a hard look too. Plenty of frameworks and customer contracts hang remediation timelines on CVSS thresholds, and a vulnerability with no score has no slot in a queue defined by one. Far better to hash that out with your auditors and GRC team now than in the middle of an assessment.
No more excuses
NIST has been clear that the NVD isn’t going anywhere, and teams can still request enrichment for lower-priority records, which is fine. Just don’t conflate that with what ended on April 15: the habit of treating a federal database as the brain of a vulnerability program. The call on what gets fixed first, and why, belongs inside the building where the context lives. It always did, in my opinion, but the difference now is that the excuse for pretending otherwise is gone.
_____
About Dan DeCloss
Dan DeCloss is the founder and a current executive at PlexTrac. He started his career in the Department of Defense and then moved on to the private sector where he worked for various companies including Telos, Veracode, Mayo Clinic, and Anthem. Dan’s background is in application security and penetration testing, involving hacking networks, websites, and mobile applications for clients. Prior to founding PlexTrac, Dan was the director of cybersecurity for Scentsy.
Join our LinkedIn group Information Security Community!
