KEV vs EPSS: Decide Which Vulnerability to Fix First

01 / Field notes

Executive Summary

A patch queue sorted only by the highest severity score can bury the flaw on an exposed system beneath hundreds of irrelevant findings. A queue sorted only by exploitation probability can miss a low-probability failure with unacceptable consequences. The useful unit of work is an affected asset, its reachable attack path and the action someone can take.

CISA's Known Exploited Vulnerabilities catalog records vulnerabilities with evidence of exploitation. FIRST's EPSS estimates the probability that a published CVE will be exploited in the wild during the next 30 days. Neither identifies which of your servers is vulnerable or confirms an intrusion. [1][2]

This guide builds a small, explainable prioritization process. Its example assets and scores are fictional; they are not current threat intelligence or a universal remediation policy.

02 / Field notes

Prerequisites / Lab Setup

Start with a read-only export from your authorized asset and vulnerability inventories. Include product, installed version, environment, internet exposure, service owner and last observation time. Add the vendor advisory and a place to record whether the vulnerable component is actually enabled. Do not scan systems you do not own.

Use a worksheet with one row per asset and vulnerability combination. Keep sensitive hostnames and internal addresses out of public tickets. Fetch intelligence from the publishers' official sources and retain its retrieval date. A cached feed is usable context when labeled as stale; it must not quietly masquerade as a fresh result.

03 / Field notes

Technical Analysis

Separate the questions before combining the signals

KEV answers whether exploitation has been documented under CISA's inclusion process. EPSS supplies a forecast, not the probability that your specific server will be compromised. A percentile is a relative ranking; it is not interchangeable with a probability. A vendor advisory helps determine affected versions and available fixes. Your inventory supplies the missing local context. [1][2]

Do not multiply these values into an impressive-looking score unless you can explain what the result means. A simpler set of decision gates is easier to review: applicable, reachable, consequential, actionable. If applicability is unknown, assign an investigation rather than silently classifying the finding as harmless.

The gateway comes first because exploitation evidence and a confirmed local path align. The desktop finding is not made dangerous by its score if the version match is wrong. The export service remains important because consequences and access matter even without a high forecast. These are decisions about the fictional environment, not categories that should automatically dictate another organization's deadlines.

Turn priority into a change that can finish

Each actionable row needs a named owner, proposed treatment and verification method. “Patch soon” is incomplete. “Apply the vendor-supported fix in a maintenance window, check the installed build and confirm the exposed service still works” is a task. If a patch is unavailable, record the vendor-supported mitigation, its operational cost and the conditions under which it will be removed.

A compensating control requires evidence. Moving a service behind authentication changes reachability, but it may not address a flaw accessible to authenticated users. Disabling a feature may help only if the vulnerable code path is that feature. Document the reasoning rather than treating any configuration change as equivalent to a fix.

Keep remediation separate from incident investigation

Patching closes a known weakness; it does not erase sessions, files or accounts an intruder may already have created. If logs or vendor guidance suggest compromise, involve your incident process before evidence is overwritten. An entry in a catalog alone is not evidence that your organization was attacked.

The next improvement is better joins between asset inventories, vendor advisories and exploitation data—not a dashboard with more red counters. Automation can propose matches and flag overdue exceptions. Keep an auditable explanation of why each decision was accepted, particularly when a feed changes or an asset moves into a more exposed environment.

04 / Field notes

Mitigation / Defense

For example, a weekly report can show five confirmed exposed findings, three remediated and two time-bounded exceptions. That is more informative than claiming a 90 percent improvement after deleting stale assets. Use our cloud configuration review to investigate access paths and the recovery drill guide when a change could affect a critical service.

05 / Field notes

References

Sources checked on 28 October 2026. References [1] and [2] define the intelligence signals. The prioritization worksheet and fictional queue are OneMoreLock's editorial synthesis, not a CISA or FIRST scoring standard. Recheck the vendor advisory when acting; this article intentionally does not freeze live CVE scores into evergreen guidance.

1. CISA Known Exploited Vulnerabilities data ↗CISA · accessed 2026-10-28
2. Exploit Prediction Scoring System ↗FIRST · accessed 2026-10-28

Questions readers ask