When KEV, EPSS, and CVSS Disagree on What to Patch

2 days ago
7 min read

By Yonatan Hoorizadeh CISSP, CISM, CRISC, AAISM

Published By: Purple Shield Security

Published: September 1, 2026 | Last updated: September 1, 2026

When the three scoring systems conflict, patch confirmed exploitation first. A vulnerability listed in CISA's Known Exploited Vulnerabilities catalog outranks a high EPSS probability, which outranks a high CVSS severity score. Then adjust for whether the asset is internet-facing, business-critical, or already covered by a compensating control.

What do KEV, EPSS, and CVSS actually measure?

They measure three different things, which is why they routinely disagree about the same flaw. CVSS, the Common Vulnerability Scoring System, rates how much damage a vulnerability could do if someone exploited it. EPSS, the Exploit Prediction Scoring System maintained by FIRST, estimates the probability that a vulnerability will be exploited in the next 30 days. The CISA Known Exploited Vulnerabilities catalog, known as KEV, is binary: attackers are using it in the wild, or they are not.

The disagreement is structural, not a defect. A vulnerability can be technically devastating and sit untouched for years because no attacker has found a practical way to reach it. Another can carry a mediocre severity score and be the exact thing a ransomware crew is spraying against internet-facing appliances this month.

Volume makes the problem sharper. According to CVETodo's CVE statistics tracker, 49,474 CVEs were published in 2026 through late August, an average of 221 per day, and only 0.6 percent of them carry an EPSS exploit probability of 10 percent or higher. The same tracker puts the CISA KEV catalog at 1,667 total entries, with 267 added over the previous 12 months. Confirmed exploitation is a very small slice of the total, which is exactly what makes it useful as a filter.

Which score wins when they conflict?

Confirmed exploitation wins. In a Help Net Security interview published August 31, 2026, Dr. Joye Purser, Global Field CISO at Cohesity, gave the decision logic she would hand an analyst: "active exploitation first, then exploit likelihood, then technical severity," with adjustments for asset exposure, business criticality, and compensating controls.

Her follow-on point is the one worth pinning to a wall. A lower-severity vulnerability sitting in an exposed identity system can pose a more immediate risk than a critical vulnerability on an isolated asset. The score describes the flaw. It does not describe your network.

CISA has encoded roughly the same hierarchy for the federal government. Binding Operational Directive 26-04, titled "Prioritizing Security Updates Based on Risk," sets vulnerability management requirements for Federal Civilian Executive Branch agencies and is built around the KEV catalog rather than raw severity scores. Private companies are not bound by BOD 26-04, but it is a defensible benchmark to borrow when you need a reference point that is not just your own opinion.

Two stories from this week make the ranking concrete. SecurityWeek reported on September 1, 2026 that CISA added two PaperCut vulnerabilities, CVE-2026-82078 and CVE-2026-81578, to the KEV catalog after exploitation escalated into hands-on intrusions. The same day, SecurityWeek reported that exploitation of the JFrog Artifactory authentication bypass CVE-2026-82329 began just days after public disclosure. Neither of those required a scoring debate.

Why the scoring debate is not your real bottleneck

Most mid-market companies do not lose this game on prioritization. They lose it on authority. The tiebreaker logic takes an afternoon to write down. Getting someone to interrupt a release schedule at 4pm on a Friday takes a decision the company has usually never made.

Purser framed the core requirement as organizational rather than technical. An actively exploited internet-facing vulnerability has to be treated as an operations event with an owner and a pre-approved emergency path, not as another line item in the monthly patch queue.

Here is how it actually breaks. The scanner flags a KEV entry on Tuesday. The IT lead reads it and knows it matters. The application owner says the patch will break a customer integration. Nobody in that conversation has the standing to say the integration goes offline for six hours tonight. So the ticket slides into the next sprint, and the one after that, and the CVE ages quietly while the catalog entry stays open.

That is not a tooling gap. It is an unassigned decision. It is also the most common finding I run into when a company brings in outside security leadership after an incident, and it is invisible on every dashboard the company owns.

What is a realistic patch window for an internet-facing system?

For a critical, internet-exposed vulnerability with confirmed exploitation, 24 to 72 hours is the target Purser called reasonable, while noting that many mid-sized organizations will struggle to hit it consistently. The distance between that target and everyday reality is where most vulnerability management programs actually live.

Hitting the window costs something specific. Security and IT need standing authority to interrupt normal release schedules. Engineering time has to be pulled for emergency testing and deployment. The business has to accept that a system may be degraded or offline for a defined period. Those are business decisions, and pretending otherwise is how patch commitments get written into policy and then quietly ignored.

When a patch is unavailable or unsafe to deploy immediately, compensating controls carry the load. Restricting access to the affected service, disabling the vulnerable feature, or isolating the system buys real time. The part companies skip is treating that as a documented decision with a named owner and an expiry date, rather than a permanent workaround nobody revisits.

How should a company under 250 people run this without a security team?

Borrow the hierarchy, shrink the process, and name one person who can make the call. A 200-person firm does not need a vulnerability management platform to get this right. It needs an accurate asset list, a KEV feed, a defined patch window for internet-facing systems, and a decision owner with pre-approved authority to break the schedule.

A workable decision rule, sorted by exposure:

On KEV and internet-facing: emergency change tonight or tomorrow. Not a sprint item.
On KEV but internal only: scheduled within seven days, with access restricted in the meantime.
High EPSS, not on KEV, internet-facing: next scheduled window, with a check for public exploit code.
High CVSS, low EPSS, not on KEV, internal: normal patch cycle. Stop running these as fire drills.

That last line carries more weight than it looks. Teams that treat every CVSS 9.8 as an emergency exhaust themselves within a quarter, and then miss the KEV entry that actually mattered.

The gap this exposes is a leadership gap, not a staffing one. This is where a vCISO, or virtual Chief Information Security Officer, earns the engagement: not by patching, but by writing the rule, naming the owner, setting the window, and standing behind the decision when a patch breaks something the sales team cares about. In Purple Shield Security engagements, a fractional CISO usually has the prioritization policy and the emergency change authority settled inside the first 30 days, well ahead of any tool purchase.

What to do this week

Three things, in order, none of which require a purchase order.

First, find out whether anyone at your company is watching the CISA KEV catalog. Not a scanner, a person or an alert routed to a person. CISA publishes additions publicly and the feed is free. If the honest answer is nobody, that is your finding for the week.

Second, write down the decision owner. One name. The person who can authorize an emergency change to a production system without convening a meeting. If that name defaults to your CEO, the process will fail the first time it is tested under pressure.

Third, inventory what is genuinely internet-facing. Most companies are wrong about this, usually because of a cloud service, a vendor appliance, or a remote access tool that never made it onto the list. A 24 to 72 hour window only means something if you know what it applies to, which is why a current asset inventory is the first deliverable in any serious risk assessment.

Frequently asked questions

Is a CISA KEV listing more urgent than a CVSS 9.8 score?

In almost every case, yes. A KEV listing confirms that attackers are exploiting the flaw right now, while CVSS only describes how damaging exploitation would be if it happened. A KEV entry on an internet-facing system should trigger an emergency change within 24 to 72 hours. An unexploited CVSS 9.8 on an isolated internal system generally belongs in the normal patch cycle.

What patch deadline should we actually write into policy?

For critical, internet-exposed vulnerabilities with confirmed exploitation, 24 to 72 hours is the benchmark Dr. Joye Purser of Cohesity cited in her August 2026 Help Net Security interview. Write that number into your policy only if you also write down who has authority to interrupt a release schedule to meet it. Without that second sentence, the deadline is decorative.

Does BOD 26-04 apply to private companies?

No. Binding Operational Directive 26-04 applies to Federal Civilian Executive Branch agencies, not to private businesses. It is still worth borrowing as a benchmark. Pointing to a recognized federal standard tends to shorten the argument with auditors, insurers, and acquisition diligence teams about whether your patch policy is reasonable.

We are 60 people with no security staff. Where do we start?

Start with the asset inventory and the decision owner, not with a tool. Know which systems are reachable from the internet, subscribe to the free CISA KEV feed, and name one person who can authorize an emergency patch. A fractional CISO can put that structure in place in weeks. A scanner without a decision owner only produces a longer list nobody is empowered to act on.

Vulnerability prioritization looks like a technical problem and behaves like a governance one. If your team can recite the tiebreaker rule but cannot name the person who invokes it, that is the gap worth closing before the next KEV entry lands on something you own. Purple Shield Security works with mid-market and regulated companies to put that structure in place through vCISO and fractional CISO engagements, and through risk assessments that start with what is actually exposed rather than what the scanner happened to find. If you want a second set of eyes on how your team would handle an actively exploited flaw this week, that is a conversation worth having.