CyphrQ
Menu

CVSS vs EPSS vs KEV: Which Vulnerabilities to Patch First

CVE, CVSS, EPSS and KEV explained in plain language, with a Log4Shell worked example and a simple order for deciding which patches come first.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

CVE is the name of a vulnerability. CVSS scores how severe it is, EPSS estimates how likely it is to be exploited soon, and KEV lists the ones already being exploited. To decide what to patch first, start with KEV, then use EPSS to rank the rest, and use CVSS plus your own context to break ties. No single score decides it for you.

What are CVE, CVSS, EPSS and KEV?

Four acronyms get mixed up constantly. They answer four different questions.

Name Question it answers Who runs it Output
CVE Which vulnerability is this? The CVE Program An identifier such as CVE-2021-44228
CVSS How severe is it technically? FIRST A score from 0.0 to 10.0
EPSS How likely is exploitation soon? FIRST A probability from 0 to 1
KEV Is it already being exploited? CISA A yes/no list

A vulnerability is a flaw in software or hardware that an attacker can abuse. A CVE record is the public entry for one flaw. The record for Log4Shell, CVE-2021-44228, was assigned by Apache and published on 10 December 2021, according to the CVE Record API. The ID only names the flaw. It says nothing about how dangerous it is.

That gap is why the other three exist.

What does CVSS tell you, and what does it not?

The CVSS v4.0 specification says the system "captures the principal technical characteristics of software, hardware and firmware vulnerabilities" and gives numerical scores "indicating the severity of a vulnerability relative to other vulnerabilities."

Read that carefully. CVSS measures severity of the flaw. It does not measure the risk to your business.

The qualitative bands in the specification are:

  • 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

Most scores you see in scanner reports and on the National Vulnerability Database (NVD, the US government's catalogue of CVE records with scores) are the Base score. The specification says Base metrics represent "the intrinsic characteristics of a vulnerability that are constant over time and across user environments." In other words, the Base score is the same for a bank's internet-facing server and for a test machine nobody can reach.

How is EPSS different from CVSS?

EPSS, the Exploit Prediction Scoring System, estimates how likely a published CVE is to be exploited in the next 30 days. FIRST describes it as "a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days."

Two differences matter:

  1. It is about likelihood, not severity. A flaw can be severe and unlikely to be attacked, or moderate and heavily attacked.
  2. It changes. FIRST says it publishes "a 0-1 probability (with ranking percentiles) every day for every CVE." A CVSS Base score rarely moves. An EPSS score can jump when attackers start paying attention.

The exploitation data comes "in part" from industry and government partners; FIRST names VulnCheck KEV, Shadow Server Foundation and LevelBlue among them.

A probability is not a verdict. An EPSS score of 0.02 means a small chance in 30 days, not zero. Across thousands of vulnerabilities, small chances still add up. That is why EPSS is for ranking, not for declaring something safe.

What is the KEV catalogue, and why does it matter most?

KEV stands for Known Exploited Vulnerabilities. CISA, the US Cybersecurity and Infrastructure Security Agency, describes its catalogue as "the authoritative source of vulnerabilities that have been exploited in the wild." It adds: "Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework."

A flaw gets onto the list only if it meets three criteria. CISA's directive BOD 22-01 states them: "a CVE ID", "clear remediation guidance" and "reliable evidence of exploitation in the wild."

That third criterion is the point. KEV is not a prediction. Someone has already used the flaw against real targets. As of 25 October 2026 (catalogue version 2026.10.23), CISA's catalogue listed 1,756 entries. Set that against the number of CVE records published every year and you can see how short the list is.

Two limits to keep in mind:

  • KEV is not complete. A flaw missing from KEV is not proven safe. It may be exploited without CISA having evidence that meets the three criteria, or it may not have a fix to point to.
  • BOD 22-01 itself has changed. The directive was binding for US federal agencies. CISA's page for it is now marked "Revoked" and says "It is superseded by BOD 26-04." I have not read BOD 26-04 itself, so I say nothing here about what it requires. The KEV catalogue remains CISA's list.

What does Log4Shell show about CVSS, EPSS and KEV?

Log4Shell is a good test because all three signals agree. Here is what each source said when I read it on 25 October 2026. The EPSS score is dated 24 October 2026 and changes daily.

Signal Value Source
CVE CVE-2021-44228, Apache Log4j2 remote code execution NVD API
CVSS v3.1 Base 10.0 Critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (NIST primary) NVD API
CVSS v4.0 No score present in NVD NVD API
KEV Added 2021-12-10, federal due date 2021-12-24 NVD API, CISA fields
EPSS 0.99999, percentile 1.0, scored on 2026-10-24 FIRST EPSS API

Read the vector as a sentence: reachable over the network (AV:N), low complexity (AC:L), no privileges (PR:N), no user interaction (UI:N), with high impact on confidentiality, integrity and availability. That is why it scores 10.0.

Notice the KEV date. The flaw was published and added to the catalogue on the same day, and the federal due date was two weeks later. That matches the "two weeks for all other vulnerabilities" timeline in BOD 22-01.

Notice also the EPSS value nearly four years later. At 0.99999, the model still treats it as almost certain to be exploited in the next 30 days. A flaw does not stop mattering because the headlines moved on.

In an easy case like this, every signal says "patch now". The useful skill is knowing what to do when they disagree.

Which should you trust when CVSS, EPSS and KEV disagree?

Use this order. It is my own rule of thumb to start with, not an industry standard.

  1. In KEV and the product is in your estate: fix first. Exploitation is confirmed. Prioritise internet-facing systems, then everything else.
  2. Not in KEV, high EPSS: next. Rank by score and watch the daily changes.
  3. Not in KEV, low EPSS, high CVSS: schedule it. Severe on paper, no sign of attack yet. Patch in the normal cycle, and recheck if EPSS rises or it appears in KEV.
  4. Low on all three: routine maintenance.

Then adjust for your own situation, which none of the three scores can see:

  • Is the affected system reachable from the internet?
  • Does it hold sensitive data, or run something critical?
  • Is there a control in front of it, such as a firewall rule or a disabled feature, that blocks the attack path?

The CVSS specification says the same in its own way. Consumers "may use CVSS information as input to an organizational vulnerability management process." Input, not the answer.

What should a small team do this week to prioritise vulnerability patching?

Here is my suggested version for a team with no dedicated vulnerability management tool. It is advice, not a sourced standard, and the deadlines in step 3 are examples.

  1. List what you run. You can't match CVEs to products you haven't inventoried.
  2. Check new CVEs for your products against KEV. The catalogue is public and has a machine-readable version.
  3. Set two patch deadlines, not ten. For example: "KEV items on internet-facing systems: as fast as you can test the patch. Everything else: your normal monthly cycle." Write the deadlines down and get management to agree.
  4. Record the reason. When you delay a KEV item, write down the compensating control and who accepted the risk.
  5. Ask your vendors where their severity numbers come from. A scanner that shows only CVSS Base scores is giving you one of the three signals.

Going deeper: for security and IT teams

Name your scores correctly. CVSS v4.0 defines four metric groups: Base, Threat, Environmental and Supplemental. The specification requires a nomenclature "wherever a numerical CVSS value is displayed or communicated": CVSS-B (Base only), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental) and CVSS-BTE (all three). A bare number such as "9.8" from a scanner does not say which of these it is, so ask. Store the label and the vector string, not just the number, so that you can tell scores apart later and recompute them.

Use the Threat group to bring exploitation data in. The Exploit Maturity metric has values Attacked (A), Proof-of-Concept (P) and Unreported (U), plus Not Defined (X). Per the specification, if Exploit Maturity is Not Defined it defaults to the worst case (A), so a score with no threat data assumes the worst case. Setting Exploit Maturity from KEV (Attacked) and from your own threat intelligence turns a Base score into a CVSS-BT score without inventing anything. Supplemental metrics add context but, per the specification, no Supplemental metric "will have any impact on the final calculated CVSS score."

Use Environmental metrics for your own context. The Environmental group "represents the characteristics of a vulnerability that are relevant and unique to a particular" environment. That is where a compensating control or a low-value asset gets reflected. The cost is effort: someone has to maintain the modified metrics per asset class, so apply them to classes of asset, not to individual findings.

Pull EPSS and KEV as data, not as a dashboard. FIRST says EPSS is free and available through CSV, an API and a GitHub repository, with scores refreshed daily. CISA's KEV catalogue publishes a JSON schema, which the page marked as updated 2 September 2026. Join both feeds to your scanner export on the CVE ID each night. Alert on three events: a CVE enters KEV, EPSS crosses your chosen threshold, or EPSS rises sharply between days. The EPSS page's "Using EPSS" section covers how to set thresholds, combine EPSS with CVSS and KEV, interpret score changes and avoid common misuses, which is worth reading before you pick your own.

Write a risk-based SLA, then test it. A workable pattern is a table keyed on KEV status, exposure and asset criticality, with a deadline in each cell. Keep the number of cells small enough that people remember it. BOD 22-01 is a useful reference for the shape: it set one deadline for older CVEs and a shorter one for the rest. Its successor, BOD 26-04, is outside the scope of this post because I have not read it. Measure your actual time-to-remediate for KEV items each month. If you can't say what it is, that is the first finding.

Limits to record in your risk register. EPSS is a model with a 30-day horizon and data from named partners. It can miss targeted attacks that never show up in that data. KEV only lists flaws with a CVE ID and remediation guidance, so a zero-day with no fix is outside it. NVD may show no CVSS v4.0 score for older entries, as it did for Log4Shell, so your tooling must cope with v3.1-only records.

Questions for vendors and auditors. Which CVSS version and metric groups do your scores use? Do you ingest KEV and EPSS, and how often? Can you show me a report sorted by KEV status? Can you evidence time-to-remediate by severity?

I have not covered decision-tree approaches such as SSVC here, because I have not read their documentation for this post.

Key takeaways

  • A CVE is only a name. CVSS rates severity, EPSS estimates the chance of exploitation in the next 30 days, and KEV lists flaws with evidence of exploitation.
  • Start with KEV for anything in your estate, rank the rest by EPSS, and use CVSS and your own context to break ties.
  • CVSS Base scores are the same for every organisation. Your exposure and controls are not.
  • Log4Shell (CVE-2021-44228) shows all three agreeing: CVSS 10.0, in KEV since 10 December 2021, EPSS 0.99999 on 24 October 2026.
  • Keep it simple: two deadlines, written down, with a note whenever you delay a KEV item.
  • Check your tools: a report showing only CVSS Base scores is missing two of the three signals.

Sources