Prioritizing patches with the KEV catalog and EPSS

The patch queue of an average organization never empties. Every week, scanners add vulnerabilities rated critical or high, and the team fixes them in score order. The problem is that the CVSS score measures how severe a vulnerability is if it is exploited, not how likely it is to be. Two public, free sources correct that bias: CISA's KEV catalog and FIRST's EPSS.

What the sources say

Directive BOD 22-01, issued by CISA on November 3, 2021, created the Known Exploited Vulnerabilities (KEV) catalog. Its founding observation: less than 4% of CVEs are actively exploited, which makes targeted remediation more realistic than fixing everything. A vulnerability enters the catalog if it meets three conditions: a CVE identifier, clear remediation guidance and reliable evidence of exploitation in the wild. The directive gave US federal agencies six months for CVEs assigned before 2021 and two weeks for the others. It specified that CVSS should remain a component of vulnerability management programs, but that exploited vulnerabilities deserved priority.

On June 10, 2026, CISA replaced that directive with BOD 26-04, "Prioritizing Security Updates Based on Risk". The deadline is no longer set by the CVE's date, but by four variables: is the asset publicly exposed, is the vulnerability in KEV, is exploitation automatable, and does the attacker gain partial or total control. The directive's table runs from three days (with forensic triage) for an exposed, KEV-listed, automatable, total-control case, through six, fourteen, twenty-one, sixty or ninety days depending on the combination, to "fix on system upgrade" for non-exposed assets in the other cases. The directive relies on the SSVC approach rather than on CVSS or EPSS, and defines a "publicly exposed" asset as any resource accessible to unauthenticated or untrusted entities via public networks.

The KEV catalog holds more than a thousand vulnerabilities, published in CSV and JSON, and grows almost every week. CISA presents it as "an input to their vulnerability management prioritization framework" for any organization.

EPSS, maintained by FIRST, is a machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next thirty days. The score runs from zero to one, comes with a percentile, and is recomputed daily for all CVEs. FIRST describes it as a complement to CVSS: severity on one side, observed exploitation likelihood on the other, to focus remediation effort where attacks are most likely.

Why it matters

Sorting by CVSS means treating first the vulnerabilities that are the most severe in theory, the vast majority of which will never be exploited, while the ones that are wait their turn. KEV inverts the logic: a short list, founded on evidence, with remediation guidance for every entry. EPSS fills the space between the two: it orders the thousands of vulnerabilities that are not in KEV by their probability of exploitation.

BOD 26-04 adds the third dimension dashboards were missing: exposure. The same vulnerability on a server reachable from the internet and on an internal workstation does not call for the same deadline. That is not a nuance; it is the difference between three days and the next maintenance window.

For organizations subject to ISO 27001 (control 8.8, management of technical vulnerabilities), SOC 2 (CC7 criteria) or NIS2 (vulnerability handling and disclosure among the article 21 measures), this sorting rule is also what the auditor wants to see: a documented prioritization criterion and measured deadlines.

What we think at Sentrix

The right question is not "which score" but "which sorting rule, written, applied and measured". In order:

1. Tag exposed assets: without an inventory of what is reachable from the internet, no exposure-based rule works. BOD 26-04 in fact asks agencies to tag their publicly reachable assets.
2. Plug in the KEV feed (JSON) into the scanner, the ticketing tool or the GRC platform, with an alert on every addition. Our Watch page republishes catalog additions continuously.
3. Write a three-tier rule inspired by the BOD 26-04 table: KEV and exposed, deadline in days; KEV not exposed or high EPSS, deadline in weeks; the rest, the normal patch cycle. EPSS thresholds are for your organization to set and revisit.
4. Keep CVSS for impact, not for order: it breaks the tie between two vulnerabilities of equal urgency.
5. Measure a single indicator first: the median delay between an entry's addition to KEV and its remediation at home. That is the figure we track in the platform's CTEM module.
6. Document the exceptions: an asset that cannot be fixed within the deadline gets a dated compensating measure, not silence.

Our vulnerability and patch management service puts this rule in place and keeps it alive.

The next step

Take the list of your open vulnerabilities and cross it with the KEV CSV file. The number of common entries, and the age of the oldest, tell you in one line whether your patch order is the right one.