How To Priortize Patches

The uncomfortable math of patching

A scanner reports thousands of vulnerabilities, but a team can realistically remediate only a few dozen per cycle. Sorting that queue by CVSS score, the way most organizations still do, means spending limited capacity on vulnerabilities that will never be attacked, while ones being actively exploited sit hidden behind a wall of theoretical criticals.

The fix is not working harder through the backlog, it is re-sorting it. Research from FIRST.org puts the share of disclosed CVEs ever exploited in the wild in the single-digit percentage range, and a striking share of those exploited carry only medium CVSS scores. Severity and risk are different things, and three complementary signals let you measure the difference: CVSS, EPSS, and CISA's KEV catalog.

The three signals, and the question each answers

CVSS: "How bad could this be?"

The Common Vulnerability Scoring System assigns each vulnerability a 0.0 to 10.0 severity score based on intrinsic characteristics: attack vector, complexity, privileges required, and impact on confidentiality, integrity, and availability. Version 3.1 remains the most widely used in practice, with v4.0 (released 2023) still gaining adoption.

• What it is good for: A standardized, universal severity language; auditors expect it, compliance frameworks reference it, and it is a reasonable first filter
• Where it misleads: CVSS describes worst-case theoretical severity, with zero knowledge of whether anyone is exploiting the flaw or whether your environment is even reachable. Sorting a patch queue purely by CVSS treats a never-weaponized 9.8 as more urgent than a 6.5 that is powering active ransomware campaigns, the exact inversion of real risk

EPSS: "How likely is this to be exploited soon?"

The Exploit Prediction Scoring System, maintained by FIRST.org, is a machine-learning model that outputs the probability (0 to 1) that a CVE will be exploited in the wild within the next 30 days. It is trained on real exploitation telemetry, including exploit databases, malware activity, and honeypot data, and it is rescored daily. The current model, EPSS v4, went live in March 2025 and can score CVEs still sitting in the NVD analysis backlog without an official CVSS score.

Two numbers appear for every CVE: the score (raw probability, so 0.92 means a 92% likelihood) and the percentile (how that CVE ranks against all others). Most CVEs score under 0.01, which is precisely the point, since EPSS separates the tiny population of genuinely dangerous vulnerabilities from the mass of theoretical ones.

• Where it misleads: EPSS predicts from observed signals, so it can lag brand-new exploitation by a day or two, and it may underrate vulnerabilities used quietly in targeted campaigns that do not generate public telemetry. It also knows nothing about your firewalls, segmentation, or which assets matter to you

The three-tier prioritization framework

A decision flow a two-person team can run weekly, using only free data feeds. KEV publishes CSV and JSON continuously, and EPSS scores are available through a free daily API.

Tier 1: KEV match, patch on an emergency clock (SLA 24-72h)

Cross-reference every scanner finding against the KEV catalog. Any match on an asset you actually run goes straight to the front of the queue with an emergency SLA: 24 to 72 hours for internet-facing or business-critical assets, and inside your normal critical window for everything else. No committee, no debate, confirmed exploitation ends the conversation about whether it is urgent.

One refinement at scale: with more than 1,100 KEV entries, "it is in KEV" can itself become a backlog. Rank within Tier 1 by exposure, internet-facing beats internal, and a product you do not run requires no action at all.

Tier 2: High EPSS, patch out of cycle (SLA ~7 days)

For findings not in KEV, check EPSS. Above a threshold you choose, and 0.5 (a 50% exploitation probability) is a common starting line that you tighten or loosen to your capacity, the vulnerability gets an out-of-cycle SLA of roughly 7 days if the asset is exposed, or your next scheduled window if it is isolated. This tier is your early-warning system: EPSS frequently flags weaponization days before official scoring catches up, as happened with several high-profile CVEs where EPSS spiked past 90% while NVD analysis was still pending.

Tier 3: Everything else, patch on schedule (Normal cadence)

The remaining majority, with low EPSS and no KEV listing, flows into your normal patch cadence, ordered by a simple composite: CVSS severity weighted by asset criticality and exposure. A CVSS 7 on an internet-facing server outranks a CVSS 9 on an air-gapped lab machine. This is also where the standard SLAs from your patch policy apply.

The output of this flow is what makes it defensible: a short Tier 1 and Tier 2 list your team can genuinely clear within SLA, plus a documented rationale for why everything else waits. When an auditor, or an incident post-mortem, asks why patch X shipped before patch Y, "KEV listing plus internet exposure" is an answer. "It had a higher CVSS" increasingly is not.

A worked example

Suppose this week's scan surfaces three findings:

• A: CVSS 9.8 critical in a database engine, EPSS 0.02, not in KEV. The server is internal, reachable only from managed endpoints.
• B: CVSS 6.5 medium in a VPN appliance, listed in KEV two days ago. The appliance is, by definition, internet-facing.
• C: CVSS 8.1 high in a web framework, EPSS 0.87 and climbing, not yet in KEV, runs on a public-facing application.

Sorted by CVSS: A (9.8) ranks ahead of C (8.1), and B (6.5) waits, the actively exploited flaw sits last.

Sorted by risk using this framework: B is Tier 1 (24-72h), C is Tier 2 (this week), and A is Tier 3 (next cycle).

Same three patches, same team, radically different exposure outcome. History says the B-type findings, medium severity but actively exploited and exposed, are how breaches actually start.

Making it run without a human in the loop

The framework above is simple to describe and tedious to operate. KEV updates multiple times a week, EPSS rescoring is daily, asset inventory changes constantly, and every change can reshuffle the queue. Run manually, the process decays, the cross-reference happens weekly, then monthly, then whenever someone remembers.

This is exactly the judgment layer that modern patch management platforms are automating. Rather than a human exporting scanner results and running lookups against a KEV spreadsheet, the platform ingests exploit intelligence continuously, correlates it with each endpoint's exposure and criticality, re-sorts the deployment queue in real time, and pushes Tier 1 findings straight into an emergency deployment ring. The prioritization logic stays yours, including the thresholds, SLAs, and risk tolerances, but the recalculation happens at machine speed, every day, without depending on anyone's calendar.

Prioritization only pays off if deployment keeps up. A perfectly sorted queue feeding a monthly manual patch window still leaves Tier 1 findings exposed for weeks. Pair risk-based sorting with ring-based automated deployment so the urgency signal translates into installed patches within the SLA.