With NIST's National Vulnerability Database (NVD) now officially triaging only a fraction of incoming Common Vulnerabilities and Exposures (CVEs), security teams can no longer treat enrichment as a guaranteed public service and the organizations best positioned to weather that shift are the ones that have already diversified beyond NVD as their single source of truth. The rest must adjust. Swiftly.
Related:
George V. Hulme
That means building vulnerability management workflows that draw on alternative enrichment sources, including data from CVE Numbering Authorities, CISA's KEV (Known Exploited Vulnerabilities) catalog, open-source enrichment projects, and commercial threat intelligence feeds, while rethinking the internal processes: patch SLAs, compliance reporting, risk scoring. that were quietly subsidized by NIST's small team in Gaithersburg.
Ongoing vulnerability enrichment efforts
Several programs and platforms have stepped into the enrichment gap, with varying coverage, autonomy, and staying power offering security teams a patchwork of alternatives to rely on as NVD's role narrows.
For instance, CISA launched its Vulnrichment program in May 2024, maintaining a public GitHub repository where agency analysts run CVEs through the Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree and, for higher-risk entries, add CWE identifiers and CVSS scores. Vulnrichment data is pushed back into the CVE corpus through the Authorized Data Publisher container, so downstream consumers don't need to track the repository directly. It's a genuinely useful effort, though Vulnrichment's coverage is still a fraction of total CVE volume.
VulnCheck, a commercial provider that has automated its own SSVC generation, reported in early 2025 that it had SSVC coverage for roughly 245,000 CVEs compared to about 64,000 for CISA's program.
NIST leadership has been publicly ambivalent about Vulnrichment. In a January 2026 meeting, Jon Boyens, the NIST official whose division runs the NVD, told an advisory board he wasn't sure the program was solving the underlying problem and noted "duplicative efforts" between the two agencies. NIST has signaled it wants to eventually push more enrichment work to CVE Numbering Authorities themselves, but that transition requires guidance NIST hasn't yet written.
Commercial vendors such as Qualys, VulnCheck, Anchore, Mend, and others have been building their own enrichment pipelines for some time, and most have been open about not relying solely on the NVD for production data. The European Union is running its own European Vulnerability Database (EUVD), which went live in May 2025, and has mandatory actively-exploited-vulnerability reporting coming under the Cyber Resilience Act later this year. The EUVD still synchronizes heavily with the NVD and other sources, so it isn't yet a clean alternative, but the direction is clear.
For the most part, however, these vendor enrichment programs help organizations that can afford vendors, says Andrew Storms, security engineering lead at Kilo Code.
“It does not help the two person security team at a regional hospital, the solo sysadmin at a rural water utility, the open source maintainer triaging in their spare time, or the small MSP covering twenty businesses on a thin margin. Those folks were relying on NVD as a free public good, and no commercial vendor is going to enrich CVEs for them out of charity. That layer of the internet just got quieter,” Storms says.
What this means for security teams
The practical remedies aren't complicated, but they do require more work for those organizations that haven’t been doing it. “This should include preventative risk mitigation strategies, such as gaining full visibility of assets and related resources, testing and scanning upon changes, and efficient and/ or automated patching. It is good to address the high priority vulnerabilities based on the NIST NVD criteria,” says Melinda Marks, practice director of cybersecurity at Omdia.
To recover vulnerability context, organizations should:
First, stop treating the NVD as a single source of truth for vulnerability intelligence, if any organization still is. Most mature programs already cross-reference vendor advisories, GitHub Security Advisories, OSV, commercial feeds, and CISA's KEV catalog. Teams that haven't built that habit should.
Second, check what the in-house tools actually consume. If a scanner or SIEM is matching CVEs to installed software via CPE, the coverage holes in unenriched CVEs will quietly produce false negatives. Vendors should be asked directly how they're compensating — and whether "we enrich our own data" means a robust internal pipeline or a marketing slide.
Third, revisit compliance language. Policies that reference "CVSS score from NVD" as the trigger for a patch SLA need updating to reflect that the score may not exist, may come from a CNA of variable quality, or may need to be produced internally.
Fourth, factor the cost transfer into the security budget. The enrichment work NIST did as a public good hasn't evaporated. It has shifted to commercial providers and to internal teams. Smaller organizations without the budget for enterprise-grade threat intelligence feeds will feel this most acutely.
“Organizations should look for tools and processes that can give them the most context for reachability and how it would impact their environments. And the more they can automate things like patching and optimize remediation, the better,” Marks adds.
Chris Blow, director, cyber intelligence and adversarial operations at a Fortune 100 international insurance company, says organizations need to move beyond treating NVD scores and vendor-provided severities as their sole arbiters of risk. Those ratings are a useful baseline, but they’re blind to an individual company’s business context. It's better to apply a custom risk formula that factors in business and financial criticality, whether the affected system is external or internal, and how deeply it sits within the network behind existing controls. That context can legitimately raise or lower priority: a nominal “critical” vulnerability buried deep, behind strong segmentation and controls, may reasonably be handled as a high — or even medium — risk in practice, he explains.
Also, lean into AI. AI and GPT-style tools are now good enough that teams can offload much of the heavy lifting involved in building and tuning these custom risk scales. Instead of accepting generic scoring, security leaders can encode questions like “Is this system financially significant?”, “Is it internet-facing?”, and “What kind of data does it process?” into a simple model that adjusts severity based on real impact and exposure. Automating this classification work can help small and mid-size businesses in particular; with AI handling the tedious math and scaling, “we don’t have the resources” becomes a far weaker excuse for not doing smarter, context-aware vulnerability prioritization, Blow says.
What the future holds
Taking a step back, the NVD's retrenchment is less a failure than a signal that the mid-2000s model of centralized, government-run vulnerability analysis has run out of runway. The database was designed for a world that produced a few thousand CVEs a year. It is now being asked to absorb an order of magnitude more, generated partly by tools that didn't exist when the program was built.
NIST's own leadership has stated that running an operational data service of this scale was never a comfortable fit for an agency whose mission is research and standards. In the January advisory board meeting, Boyens described the NVD as an "outlier" in NIST's portfolio and said the agency wants to "get back to what NIST's core functions are."
That suggests NVD's long-term future isn't a return to the all-enrichment-for-all-CVEs model. It suggests the real action will be in CNA-driven enrichment, in CISA's Vulnrichment and its successors, in commercial data providers, and in whatever the EU and other jurisdictions end up building. And it suggests that enterprise security programs should treat this announcement not as a shock but as the formal end of a transition that has been underway for two years.
Those that have already diversified their vulnerability intelligence sources will barely notice the change. Those that haven't have some catching up to do. “Today’s successful programs will be less dependent on scoring and more tied to context on their assets and environments,” concludes Marks.
