CVSS vs EPSS vs KEV: Prioritizing Vulnerability Fixes

A vulnerability is a weakness in software that an attacker can use, and when there are many, someone must choose which to fix first. CVSS vs EPSS vs KEV is the comparison this article makes, because these three aids to the choice are often confused. CVSS (the Common Vulnerability Scoring System) says how severe a vulnerability is on technical grounds, EPSS (the Exploit Prediction Scoring System) estimates the probability that it will be exploited in the next 30 days, and KEV (the Known Exploited Vulnerabilities catalog) lists vulnerabilities that CISA has reliable evidence of being exploited in the wild. They answer three different questions, so they work best together.

The three side by side

Each one measures a different thing:

• CVSS: a score from 0 to 10 for severity, calculated from the technical characteristics of the vulnerability. The question it answers: how bad would it be if it were exploited? Maintained by FIRST (the global Forum of Incident Response and Security Teams). The current version is 4.0
• EPSS: a probability from 0 to 1 (0% to 100%) that exploitation will be observed in the next 30 days, updated daily. The question it answers: how likely is this to be attacked soon? Overseen by a special interest group at FIRST, with scores calculated by Empirical Security
• KEV: a list, not a score. A vulnerability on the list has reliable evidence of having been exploited. The question it answers: has it already been used in attacks? Maintained by CISA

CVSS: it measures severity, not risk

CVSS is an open framework for describing the characteristics and severity of vulnerabilities. Version 4.0 was released on 1 November 2023 and is the current version on FIRST's website as of October 2026. It has four metric groups:

• Base: characteristics of the vulnerability that stay constant over time and across organizations, assuming the reasonable worst-case impact
• Threat: an adjustment for the real situation, such as whether public proof-of-concept exploit code exists or attacks have been reported
• Environmental: an adjustment to the user's own systems, such as the importance of the system and the controls already in place
• Supplemental: extra information about the vulnerability, such as safety impact, which does not change the final score

The name of a score shows which groups were used: CVSS-B is Base only, CVSS-BT is Base plus Threat, CVSS-BE is Base plus Environmental, and CVSS-BTE uses all three. The specification says T or E belongs in the name only when those metrics were actually used. The EPSS FAQ notes that when people talk about a CVSS score they usually mean the Base score.

The specification offers an optional label scale:

• None: 0.0
• Low: 0.1 to 3.9
• Medium: 4.0 to 6.9
• High: 7.0 to 8.9
• Critical: 9.0 to 10.0

These labels describe severity only. They are not deadlines and not the risk to any particular system. The Base score assumes a reasonable worst-case impact across environments, so it does not know whether your system is reachable from the internet or whether anyone is attacking that vulnerability. FIRST's specification advises adding Threat and Environmental values that match your own systems to the Base score. The CVSS v4.0 FAQ says Base scores are not risk and should not be used alone to prioritize patching (a patch is the update a vendor releases to fix the vulnerability).

EPSS: the probability of exploitation

EPSS (Exploit Prediction Scoring System) is a data-driven model that estimates the probability that a publicly disclosed vulnerability (one with a CVE ID, its unique public identifier) will be exploited in the wild within the next 30 days. It gives every CVE a score from 0 to 1 and is updated daily. The scores are published free as a CSV file (a plain-text table) and through an API, with no registration.

EPSS gives two numbers. The probability is an absolute figure: among many vulnerabilities scored near 0.05, about 5 in 100 are expected to show exploitation activity within 30 days. The percentile is a relative ranking: a vulnerability at the 90th percentile scores higher than 90% of all scored vulnerabilities.

Most vulnerabilities are never exploited, so EPSS scores cluster near zero. The EPSS FAQ says that in a 30-day window exploitation is observed for roughly 2.5 to 3% of published CVEs, and that KEV lists roughly 0.5% of published CVEs. A 5% score therefore sounds low but is above the base rate, and the FAQ places it in the top 10% of all vulnerabilities. These figures are approximations as stated in the FAQ as of October 2026, and they can change.

EPSS has limits you need to know:

• Not a risk score: EPSS gives only the likelihood of attack; it does not assess impact, does not know what systems the organization runs, and does not count the controls already in place
• It is based on attacks that data partners observe: it counts attempts detected through malware data from user machines, honeypots (decoy systems that attract attackers), intrusion detection systems (IDS/IPS) and threat intelligence, not confirmed successful compromises, and attacks that nobody observes are not counted
• It is a 30-day forecast: recalculated every day, so the score of the same CVE can change
• Do not multiply it by a CVSS score: FIRST says the product has no interpretable meaning
• There is no universal threshold: FIRST says 0.10 is commonly cited but carries no special authority; choose a threshold from the remediation capacity you have and the risk you can accept

KEV: confirmed exploitation

KEV is a list of vulnerabilities that are being exploited, created and maintained by CISA. CISA adds a vulnerability only when three conditions are met together: it has a CVE ID, there is reliable evidence of active exploitation in the wild, and there is a clear remediation action, such as a vendor update.

The list is published as CSV and JSON files that anyone can download free. The JSON file CISA published on 21 October 2026 holds 1,754 entries. Each entry has the date added, a due date, the required action, and a field showing whether it is known to have been used in ransomware (malware that demands payment) campaigns. The figure of 1,754 is as of that day and grows as entries are added, and the due dates are set for US federal agencies.

The directive behind the list has changed. BOD 22-01 (a Binding Operational Directive, a compulsory direction to US federal agencies), which created KEV, was revoked on 10 June 2026 and replaced by BOD 26-04. BOD 26-04 keeps the KEV criteria and requires federal agencies to fix by deadlines tied to several factors. CISA strongly recommends that every organization, even though it is not bound by the directive, review the KEV catalog regularly and use it as one input to its own vulnerability prioritization framework.

KEV has limits too:

• A record of the past, not a forecast: it says an attack has happened, not how much more attacking to expect
• Evidence of exploitation somewhere, not in your network: you must check whether your own systems have the vulnerability; some entries also carry a requirement to look for signs of compromise (forensic triage)
• Not complete: an entry needs a CVE ID and a clear fix. CISA aims to add entries within 24 hours but sometimes takes longer, and vulnerabilities without a CVE ID, such as configuration problems, still have to be tracked by you
• Its meaning fades with time: FIRST says recent exploitation is a strong signal, but a vulnerability added to KEV years ago, with no evidence of continuing attacks, reverts toward the probability its characteristics would predict

Using the three together

There is no single formula that suits every organization. FIRST gives a general rule of thumb: when a vulnerability is on KEV, treat it as actively exploited and prioritize it, regardless of its EPSS score. For all the others, which is most of them, use EPSS. FIRST stresses that a low EPSS score on a KEV vulnerability is not a contradiction, because KEV is a record of the past and EPSS is a forecast.

Then look at your own context. FIRST suggests three checks: is the vulnerability actually present in your systems (presence), can an attacker reach it, for example from the internet or only after logging in (reachability), and how much would it matter if the system were attacked (consequence). If any one of them does not hold, urgency falls, however high the EPSS score is. The Environmental metrics of CVSS are designed to adjust a score to the user's environment in the same spirit.

An example order of decisions (an illustration, not a standard; adjust it to your own capacity):

• First: a vulnerability that is on KEV and present in your systems is treated as actively exploited, and you act at once, following the guidance on that entry, including looking for signs of compromise where it is required
• Next: a vulnerability that is not on KEV but is reachable from the internet or sits on an important system, with an EPSS probability that is high against a threshold your organization sets itself
• Then: the remaining vulnerabilities with a high CVSS severity, scheduled in the routine patch cycle, using severity as the tie-breaker when other factors are equal
• Last: vulnerabilities that are low on every measure, fixed in the routine cycle and rechecked from time to time, because EPSS and KEV change every day

Consider a hypothetical case (all the numbers are made up and are not real CVEs). Vulnerability X has a CVSS-B of 9.8 and an EPSS of 0.01, is not on KEV, and sits on an internal test server. Vulnerability Y has a CVSS-B of 7.5, is on KEV, and sits on a VPN gateway (the entry point for secure remote connections) exposed to the internet. Following the order above, Y is fixed first, even though X has the higher CVSS score, because Y is already being exploited and an attacker can reach it directly, whatever Y's EPSS is. X goes into the routine cycle and is rechecked when its EPSS or KEV status changes. For looking after VPN gateways, see ZTNA vs VPN: Which Should You Choose?.

CISA's SSVC (Stakeholder-Specific Vulnerability Categorization) is another way to do this systematically, using a decision tree built on five inputs: exploitation status, technical impact, automatability, mission prevalence, and public well-being impact. Its outcomes range from Track (monitor and remediate on standard timelines) to Act (remediate as soon as possible, with leadership involved). BOD 26-04 uses four factors: public exposure, KEV status, automatable exploitation, and technical impact.

The numbers in this article, such as 0.05, 0.10, 9.8, 7.5 and 0.01, are examples, not thresholds to copy. FIRST says there is no universal EPSS threshold; choose one that your team can sustain and that matches the risk you can accept. The example order above therefore contains no numeric cutoffs.

The companion article A Vulnerability Management Program That Works covers the whole program, from the asset inventory and response plans to measurement. For getting patches installed on time, see Patch Management Best Practice: Fast, Without Outages.

Common mistakes

• Treating a Critical CVSS rating as meaning it is under attack: the score gives technical severity and does not say anyone is attacking
• Fixing in CVSS order alone: FIRST says Base scores are not risk
• Multiplying EPSS by CVSS to get one combined score: FIRST calls this a misuse of statistics; the product has no interpretable meaning
• Reading a low EPSS score as safe: the EPSS FAQ points out that a 5% score across many vulnerabilities means about 1 in 20 is expected to see exploitation
• Reading absence from KEV as meaning no one attacks it: KEV covers only vulnerabilities for which CISA has evidence and a clear fix
• Adopting KEV due dates as your own deadline without deciding: those dates are set for US federal agencies, and the directive behind them changed on 10 June 2026

Start today

• Check what kind of score your scanner shows: whether it is CVSS-B (Base only) or includes Threat and Environmental metrics, and which version
• Download the KEV catalog and compare it with your own vulnerability list: fix the matches first
• Add the EPSS score as another column: the daily CSV file is free to download, or you can query the API
• Record context for each finding: whether it is reachable from the internet and how important the system is
• Write a one-page ranking rule: which signals are used, in what order, and which numeric cutoffs are your organization's own decision
• Review it monthly: check whether the rule produces an amount of work your team can sustain, then adjust the cutoffs; FIRST recommends a threshold you can keep up with

To see where your organization's vulnerability management stands today, try the self-assessment.

Data on which vulnerabilities are exploited is one kind of threat intelligence; see Cyber Threat Intelligence (CTI) for Beginners.

References and further reading

• FIRST CVSS v4.0 Specification Document: the four metric groups, score names and severity labels (document version 1.2)
• FIRST CVSS v4.0 FAQ: Base scores are not risk, and FIRST's view of BOD 26-04
• FIRST EPSS: overview and data access
• FIRST EPSS FAQ: probability versus percentile, limits, and thresholds
• FIRST EPSS: Using EPSS: combining it with KEV, and the presence, reachability and consequence checks
• FIRST EPSS: How It Works: the data used and what counts as exploitation
• CISA Known Exploited Vulnerabilities Catalog: the KEV list, its criteria, and CSV and JSON downloads
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk: the directive that replaced BOD 22-01 in June 2026
• CISA SSVC: the decision tree built on five inputs