KEV and EPSS: a practical way to prioritise vulnerabilities in OT and device fleets

A CVE list ranked only by CVSS severity does not tell you what to patch first. CISA's Known Exploited Vulnerabilities (KEV) catalog confirms which vulnerabilities are being exploited today. FIRST's Exploit Prediction Scoring System (EPSS) estimates, for every published CVE, the probability it will be exploited in the next 30 days. Used together, they turn a list of hundreds of CVEs in an OT fleet or a firmware SBOM into a short list of what to act on now, what to mitigate, and what can wait for the next maintenance window.

What the KEV catalog actually tells you

CISA describes the KEV catalog as the authoritative source on vulnerabilities exploited in the wild, and recommends organisations use it "as an input to their vulnerability management prioritization framework." Under Binding Operational Directive (BOD) 22-01, issued 3 November 2021, a vulnerability was added to the catalog only when it met three conditions: it has an assigned CVE ID, clear remediation guidance exists, and there is reliable evidence of active exploitation in the wild. BOD 22-01 was revoked and replaced on 10 June 2026 by BOD 26-04, which keeps the KEV inclusion criteria unchanged but replaces the old flat remediation deadline with risk-based tiers driven by asset exposure, KEV status, whether the exploit is automatable, and technical impact.

Remediation deadlines: then and now (US federal civilian agencies)

Directive	Status	Deadline logic
BOD 22-01 (3 Nov 2021 – 10 Jun 2026)	Revoked	2 weeks for CVEs assigned in 2021 or later, 6 months for older CVEs, counted from catalog addition
BOD 26-04 (from 10 Jun 2026)	Current	Deadline varies by risk tier; the shortest is 3 calendar days plus mandatory forensic triage for internet-exposed, automatable, full-control vulnerabilities (the full set of intermediate tiers is to be confirmed against the published directive text)

These directives legally bind only US federal civilian executive branch agencies. Organisations outside that scope, including most OT asset owners and device makers, cannot be bound by BOD deadlines; they use the KEV catalog the way CISA itself recommends it to everyone, as a voluntary prioritisation input.

What EPSS adds

KEV is binary and retrospective: a CVE is either confirmed exploited, or it is not yet in the catalog. Most CVEs matched against an OT asset inventory or a firmware SBOM will never appear in KEV, yet some are still far more likely to be exploited soon than others. EPSS, maintained by FIRST, closes that gap. It is "a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days," scored from 0 to 1 for every published CVE and updated daily. A percentile ranks a CVE against every other scored CVE: a vulnerability at the 90th percentile has a higher EPSS score than 90% of all scored vulnerabilities.

FIRST is explicit about how EPSS should, and should not, be combined with other scores:

• Do not multiply EPSS by CVSS. "Multiplying EPSS by a CVSS score does not compute probability × severity and is never a good idea," because the two measure different things.
• When KEV and EPSS disagree, follow KEV. A low EPSS score does not override confirmed historical exploitation already recorded in KEV.

KEV vs EPSS vs CVSS at a glance

	What it measures	Range	Updated	Maintained by
CVSS	Technical severity if exploited	0–10	At CVE publication, rarely revised	NVD / vendors
KEV	Confirmed exploitation in the wild (catalog membership)	In / not in catalog	As evidence arrives	CISA
EPSS	Predicted probability of exploitation in the next 30 days	0–1, plus percentile	Daily	FIRST

Why this matters more for OT than for IT

An office laptop fleet can usually take a patch within days. An OT fleet rarely can: a PLC or HMI patch may need a certified configuration re-test, a planned downtime window, or vendor sign-off, and some assets cannot be patched at all without replacement. With hundreds of CVEs typical in a legacy OT network scan, a team that tries to patch by CVSS score alone will burn its limited maintenance windows on vulnerabilities nobody is exploiting, while a genuinely exploited one waits its turn. CISA's Stakeholder-Specific Vulnerability Categorization (SSVC), developed with Carnegie Mellon University's Software Engineering Institute, is a decision tree built for exactly this problem: it sorts vulnerabilities into four actions, Track, Track*, Attend and Act, using decision points that explicitly include a vulnerability's exploitation status.

A workable triage order

1. Match your asset inventory or firmware SBOM against KEV. Any match is your top tier, whatever the CVSS score says.
2. Score everything else with EPSS and sort by percentile. A sudden jump in a component's EPSS score is an early warning, often before it reaches KEV.
3. Apply exploitation status as a decision point, SSVC-style, alongside exposure (internet-facing vs. isolated) and safety impact, to decide Track, Attend or Act for OT assets that cannot simply be patched this week.
4. Record the decision, not just the score. A VEX statement per component version keeps the reasoning auditable the next time the same CVE resurfaces on a different asset. See firmware SBOM and VEX.
5. Re-run regularly. KEV grows as CISA confirms new exploitation; EPSS recalculates every day. A fleet that was clean last month is not guaranteed to be clean today.

For device makers, the same KEV and EPSS match feeds the pre-release "known exploitable vulnerabilities" check the Cyber Resilience Act requires, and the 24-hour reporting duty once something in your own product is actively exploited; see the CRA checklist for device makers and CRA 24h/72h reporting.

SoftWSP matches a passive OT network snapshot or a firmware SBOM against KEV and EPSS, and turns the result into a triage list your team can act on: see OT Snapshot and device firmware security.

This guide is general information, not legal advice.