The question at hand
NIST's April 2026 decision to stop enriching most CVEs in the National Vulnerability Database has divided vulnerability management teams. Some see this as proof that CVSS-centric scanning was never enough and want to overhaul their approach. Others argue that CVSS remains a practical baseline and that using multiple scoring systems adds complexity without reducing risk proportionally.
Both sides agree the old model is flawed. NIST admitted its severity scores matched independent assessors only 12% of the time. Submissions to the NVD increased 263% between 2020 and 2025, and the agency's backlog more than doubled last year. Thousands of pre-March 2026 records were moved to a "Not Scheduled" category that may never be addressed.
The real question isn't whether CVSS is perfect. It's whether your team can afford to rebuild your vulnerability program while keeping critical systems patched. Do the alternatives actually reduce risk, or just shift the bottleneck?
The case for moving beyond CVSS
The evidence against CVSS-only approaches is clear. A Kagawa University study found that using a 7.0 severity threshold addresses only 0.2% to 0.5% of vulnerabilities that are actually exploitable in the wild.
Practitioners advocating for integrated frameworks report operational gains. Combining CVSS with the Exploit Prediction Scoring System (EPSS) and CISA's Known Exploited Vulnerabilities (KEV) catalogue reduces urgent prioritization workloads by about 95%, from roughly 16,000 to 850 vulnerabilities, while maintaining 85.6% coverage, according to the same study.
EPSS uses machine learning to predict the probability a vulnerability will be exploited in the next 30 days. KEV lists vulnerabilities CISA has confirmed are being actively exploited. Together, they answer the question CVSS can't: not how severe is this flaw in theory, but how likely is it to harm us right now.
Timing is crucial. Vulnerability exploitation surpassed stolen credentials as the leading breach vector in over 31,000 incidents reviewed in Verizon's Data Breach Investigations Report. CrowdStrike's 2026 Annual Threat Report noted that AI-enabled adversaries increased attacks by 89% year-over-year in 2025. Attackers are getting faster, and defenders need better triage.
Without CPE data, vulnerability scanners relying solely on NVD-derived enrichment can't match a CVE to a product. NIST acknowledged that its new priority criteria "may not catch every potentially high-impact CVE". If you're still waiting for NIST to tell you what to patch, you're managing a backlog that will never clear.
The case for keeping CVSS as your baseline
The counterargument is practical: CVSS is embedded in your tools, policies, and audit documentation. Your scanner outputs CVSS scores. Your SLA with engineering defines remediation windows by CVSS severity. Your board reports use CVSS thresholds to measure program maturity.
Switching to EPSS and KEV doesn't eliminate that infrastructure. It adds to it. Now you're asking security engineers to cross-reference three scoring systems before deciding whether to patch. You're explaining to auditors why you didn't remediate a 9.8 CVSS vulnerability that had a low EPSS score, and hoping they understand probabilistic risk models.
EPSS is a prediction, not a guarantee. A low EPSS score today doesn't mean the vulnerability won't be weaponized tomorrow. KEV only includes vulnerabilities CISA has confirmed are exploited, which means you're always reactive. By the time a CVE hits KEV, attackers have already moved.
The operational burden is real. The Cloud Security Alliance found that 77% of enterprise organizations still require more than a week to deploy a critical patch. The problem isn't scoring, it's execution. Adding more data sources doesn't speed up change windows or reduce the backlog. It just gives teams more information they can't act on.
For organizations with limited security staff, CVSS provides a defensible baseline. If you patch everything above 7.0 within your SLA, you can demonstrate due diligence. If you start layering in EPSS and KEV, you need to document why you prioritized one vulnerability over another, and that documentation becomes audit evidence. Not every compliance manager has the bandwidth to maintain that.
Where practitioners actually land
Most teams aren't choosing one approach or the other. They're layering.
CVSS remains the default severity filter because it's what scanners report and what policies reference. But teams are adding KEV monitoring as a fast-track override: if it's on the KEV list, it jumps the queue regardless of CVSS score. EPSS gets used selectively, typically for medium-severity vulnerabilities where the team needs to decide whether to patch now or defer.
The shift isn't technical, it's operational. Teams are moving from "patch everything above X score" to "patch based on context". That context includes whether the vulnerable system is internet-facing, whether it handles sensitive data, whether compensating controls exist, and whether the vulnerability has proof-of-concept exploit code.
ISO/IEC 27001 supports this layered approach directly. Control A.8.8 (Management of Technical Vulnerabilities) requires organizations to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. It doesn't mandate a specific scoring system. Control A.5.7 (Threat Intelligence) requires the collection and analysis of threat data, which is exactly what EPSS and KEV provide.
Read together with A.5.30 (ICT Readiness for Business Continuity), the standard frames vulnerability management as one input into operational resilience rather than a standalone scanner output. Certification gives compliance managers a defensible audit trail when regulators ask how you prioritized CVEs without full NVD enrichment.
Our take
CVSS isn't going away, and you shouldn't try to remove it. But relying on CVSS alone was never defensible, and the NVD pullback just made that reality harder to ignore.
Start with KEV. It's a short list, it's updated frequently, and it represents confirmed active exploitation. If a vulnerability is on KEV and you have the affected software, patch it. This doesn't require new tooling or policy changes, just a weekly check and a fast-track process.
Add EPSS for triage, not replacement. Use it to decide which medium-severity vulnerabilities deserve immediate attention and which can wait for the next maintenance window. Don't use it to ignore high-CVSS vulnerabilities, use it to prioritize within severity bands.
Document your decision framework in your ISMS. Map it to A.8.8 and A.5.7. Explain how you combine scoring systems, threat intelligence, and asset context to prioritize remediation. That documentation becomes your audit evidence and your operational playbook.
Organizations that struggle with this transition treat vulnerability management as a compliance checkbox. Those that succeed treat it as a resilience capability, where scoring is one input among many and the goal is reducing blast radius, not clearing a scanner queue.
NIST's policy shift forces that evolution. It's time to use multiple intelligence sources and think more holistically about exploitability, positioning vulnerability management as an integral part of a broader resilience approach.
