Why CVSS Is Not a Patching Strategy

Here’s a scenario I see regularly. A scanner flags a CVE rated 9.8 on a development server that sits behind a VPN, has no internet exposure, and runs a test workload nobody depends on. The same scan flags a 7.2 on a public-facing Exchange server that processes customer email for 400 users. The 9.8 goes to the top of the remediation queue. The 7.2 waits.

That’s CVSS working exactly as designed. It’s also why CVSS alone is a poor foundation for patch prioritization.

What CVSS actually measures

The Common Vulnerability Scoring System assigns a severity rating between 0 and 10 based on the technical characteristics of a vulnerability – attack vector, complexity, privilege requirements, and potential impact on confidentiality, integrity, and availability. It’s maintained by FIRST, with CVSS v4.0 current since November 2023.

CVSS is valuable because it standardizes severity language across the industry. The mistake is treating standardized severity as environment-specific priority. Even FIRST and the NVD are clear that CVSS should be one input into decision-making, not the decision itself. In practice, the score is already in the scanner output, and a number feels more actionable than uncertainty.

Where it breaks down

Research and field experience show the same thing: CVSS severity correlates imperfectly with real-world exploitation. Some lower-scored vulnerabilities are exploited quickly. Some high-scored vulnerabilities are not. That mismatch is not a flaw in CVSS so much as a reminder that severity is not the same thing as operational priority.

CVSS treats impact categories generically. It doesn’t know whether availability matters more than confidentiality in your environment, whether the affected asset is exposed, or whether the system sits behind multiple compensating controls.

To see how this plays out concretely: in January 2026, Microsoft patched 113 CVEs. Among them was CVE-2026-20805, which carried a CVSS score of just 5.5 – but was being actively exploited in the wild. The same release also included higher-scored CVEs that Microsoft assessed as less likely to be exploited. If you triaged purely by score, you’d have spent your time on the wrong problems.

EPSS helps – but it’s not enough either

The Exploit Prediction Scoring System is a useful complement because it estimates near-term exploitation likelihood rather than just technical severity. Developed under FIRST, EPSS uses machine learning to predict the probability that a CVE will be exploited in the wild within the next 30 days. That helps teams distinguish between vulnerabilities that are theoretically serious and those that are more likely to be used against them.

Research from the EPSS project found that when organizations prioritize remediation based on CVSS 7.0 and above, only about 2.3% of those CVEs were actually observed in exploitation attempts during the measurement period. That’s a staggering amount of effort directed at vulnerabilities nobody is actively exploiting.

But EPSS is still a universal model. It doesn’t know your asset inventory, your exposure profile, your maintenance windows, or your compensating controls. A high-EPSS CVE may be irrelevant if you don’t run the affected software. A low-EPSS CVE may still matter urgently if it affects a critical exposed asset in your environment.

Neither score, on its own, is a patching strategy.

What contextual prioritization actually requires

Effective patch prioritization needs to account for factors that no universal scoring system can provide.

Asset criticality. A vulnerability on a domain controller is fundamentally different from the same vulnerability on a test workstation. Your patching priority has to reflect a deliberate asset tier list – not one that evolved organically through years of IT turnover and tribal knowledge. If you can’t answer the question “what are our most critical assets?” without opening a spreadsheet someone last updated six months ago, your prioritization model is already broken.

Exposure level. An internet-facing server has a different risk profile from an air-gapped internal system. Both might carry the same CVE. Only one of them is likely to be targeted before your next maintenance window. This is where the attack surface work we described in Your Attack Surface Is Bigger Than You Think connects directly to patch prioritization – you can’t assess exposure if you don’t know what’s exposed.

Deployment safety. This is the variable most scoring systems miss entirely. A patch may address a serious vulnerability, but if it’s causing blue screens, rollback failures, or application breakage across similar environments this week, deploying it blindly is not a risk-reducing decision. It’s a trade-off between security risk and operational risk. Mature patching programs need both sides of that equation. That intelligence doesn’t come from vulnerability scanning; it comes from deployment telemetry, administrator community signals, and canary testing.

Compensating controls. If you have a WAF in front of the affected web server, network segmentation limiting lateral movement, or endpoint detection that would catch the exploitation technique, those controls change the effective risk even if they don’t change the CVSS score. Prioritization without compensating-control awareness treats every environment as if it’s running naked on the internet.

The volume problem makes this urgent

This isn’t abstract. Microsoft alone ships a substantial volume of vulnerabilities and fixes every month, and some months include multiple exploited zero-days. Add third-party applications, firmware, and cloud configuration change, and many mid-market teams are forced to make more remediation decisions than they can review manually.

No team can patch everything immediately. The ones that try end up in a reactive cycle of emergency changes, missed context, and the occasional production outage caused by an untested patch. The teams that succeed have a system: automated risk scoring that accounts for their environment, not just the vulnerability, and is applied consistently every time new data comes in.

What this looks like in practice

This is the operational gap a patching program has to solve if it wants to scale. Patch Veracity addresses it by combining severity, exploitation signals, deployment telemetry, and early canary feedback into a single decisioning model.

Patches that score above our high-confidence threshold can be auto-approved and routed to the next maintenance window. Patches with known issues get flagged for review with specific context about why they need attention – not just a number, but actual deployment outcome data. The high-confidence decisions get automated. The edge cases get human attention. That’s how you scale a patching program without scaling the team.

CVSS is useful metadata. EPSS is useful metadata. Neither replaces judgment, environment context, or deployment intelligence.

In a real patching program, the question is not how severe a vulnerability is in theory. It’s how much risk it creates in your environment, and what the safest path to reduction looks like now. A number between 0 and 10 cannot answer that by itself.

---

Related reading: Patch Tuesday Is a Starting Gun, Not a Finish Line | Agentless Patch Management: Why We Chose Native Microsoft Integration

Want to see what risk-based triage looks like in a Microsoft environment like yours? Book a 30-minute walkthrough and we’ll show you how Patch Veracity prioritizes for your asset inventory, exposure profile, and deployment constraints – not just a severity score.