Blog / Security education
CVE, CVSS, EPSS and KEV: how to prioritize vulnerabilities
CVE names a flaw, CVSS rates severity, EPSS predicts exploitation, CISA KEV confirms it. How to prioritize vulnerabilities by combining all four signals.
How to prioritize vulnerabilities is the hardest ordinary problem in security, and most teams still get it backwards. A scanner returns thousands of findings, each stamped with a severity rating, and the queue gets worked from the top down. The trouble is that severity is only one of four signals that decide what to fix first, and on its own it is the weakest of them. CVE, CVSS, EPSS and CISA KEV each answer a different question. Used together, they turn an endless list into a short, defensible plan. Used alone, severity buries the handful of flaws that will actually be used against you under thousands that never will. This guide explains what each signal is, what it is not, and how to combine them into a model you can run every week.
Four signals, four different questions
Prioritization goes wrong when one signal is asked to do the job of four. A CVE identifies a flaw. CVSS rates how bad it could be. EPSS estimates how likely it is to be exploited. KEV confirms whether it already has been. None of these is a substitute for another, and the order you apply them in is most of the decision.
| Signal | What it is | What it tells you | Key limitation | Maintainer / source |
|---|---|---|---|---|
| CVE | A unique identifier for one publicly disclosed vulnerability | That a specific flaw exists and has a name everyone can reference | A label, not a ranking; it says nothing about severity or risk | CVE Program (MITRE), enriched by NVD (NIST) |
| CVSS | A scoring system for a flaw's technical severity | How damaging the flaw could be, in the abstract worst case | Measures severity, not risk; scores cluster in the high bands | FIRST |
| EPSS | A data-driven estimate of exploitation likelihood | The probability a flaw is exploited in the wild in the next 30 days | A global estimate; it does not know your environment | FIRST |
| KEV | A catalog of flaws with confirmed active exploitation | That a flaw is being used in real attacks right now | Lists only what is already seen; absence is not safety | CISA |
CVE: the identifier, not a priority
A CVE, short for Common Vulnerabilities and Exposures, is a unique name for a single publicly disclosed vulnerability. The CVE Program, run by MITRE and sponsored by CISA, assigns these identifiers through a network of CVE Numbering Authorities, so that a flaw in one vendor's product can be referenced without ambiguity by everyone else. CVE-2026-97229 points to one specific weakness and nothing else.
That is the whole purpose, and the whole limit. A CVE ID carries no severity, no likelihood, and no judgment about your environment. It is a primary key, not a priority. The National Vulnerability Database, maintained by NIST, builds on the CVE list and enriches each record with added analysis: a CVSS severity score, affected-product data, and references. The identifier tells you a flaw exists. Everything about what to do with it comes from the signals layered on top.
CVSS: severity, not risk
The Common Vulnerability Scoring System, maintained by FIRST, turns a vulnerability's technical characteristics into a number from 0.0 to 10.0 and a label from Low to Critical. It is the most familiar signal, and the most misused. The current release is version 4.0, though version 3.1 remains in wide use across tooling and databases.
CVSS is built from several metric groups, and most teams only ever see the first. The Base metrics describe the intrinsic traits of the flaw, the ones that stay constant over time and across environments, and they produce the score you usually see. The Temporal metrics, renamed Threat in version 4.0, account for the current state of exploitation, such as whether working exploit code exists. The Environmental metrics let you re-score the flaw for your own deployment. The Base score is a starting point that FIRST intends you to adjust. In practice, almost nobody does.
That gap is where prioritization breaks. FIRST is explicit about it. A section of the CVSS specification is titled "CVSS Measures Severity, not Risk", and it warns that the Base Score is often used where a fuller risk assessment, one that weighs exposure and threat, is more appropriate. Severity is a ceiling on how bad a flaw could be in the worst case. Risk is the chance it harms you in particular. The two are not the same number.
There is a second problem, specific to scale. Scores cluster high. Under CVSS v3 scoring, the High and Critical bands together account for a large share of all rated CVEs, by some analyses close to half. When half the catalog is labeled an emergency, the label has stopped sorting anything.
EPSS: the probability of exploitation
The Exploit Prediction Scoring System, also maintained by FIRST, answers the question CVSS does not: how likely is this flaw to be exploited? EPSS is a data-driven model that produces, for each published CVE, a probability from 0 to 1 that it will be exploited in the wild in the next 30 days. The scores are recalculated and published daily, so a flaw's EPSS value rises and falls as real-world signals change.
This is a different axis from severity, and the distinction sits at the heart of any CVSS vs EPSS vs KEV comparison. A flaw can be a CVSS 9.8 and still carry a low EPSS probability, because severe and likely are not the same thing. Most vulnerabilities, in fact, are never exploited at all. The research behind EPSS, and large studies of real environments, have consistently found that only a small fraction of published CVEs are ever used in an attack. EPSS exists to point you at that fraction before it is confirmed.
What EPSS is not: a statement about your environment. It is a global estimate of exploitation activity, not a measure of whether a given asset is reachable or valuable to you. It narrows the field from everything down to the small set worth close attention. It does not make the final call.
CISA KEV: confirmed exploitation
Where EPSS estimates, the CISA Known Exploited Vulnerabilities catalog confirms. KEV is a list of vulnerabilities that CISA has evidence are being actively exploited in the real world. An entry is not a prediction or a severity judgment. It is a statement of fact: this flaw is being used in attacks right now. CISA adds a CVE only when it has reliable evidence of active exploitation, the flaw has an assigned CVE ID, and there is a clear remediation action.
For US federal civilian agencies, KEV carries legal weight. In June 2026, CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," which supersedes the earlier BOD 22-01 and requires agencies to remediate KEV-listed flaws within set timelines. Those timelines are now risk-based rather than fixed. The directive draws on the Stakeholder-Specific Vulnerability Categorization (SSVC) method and sets deadlines from four factors: whether the asset is internet-reachable, whether the flaw is in KEV, whether exploitation can be automated, and the technical impact. The most dangerous cases carry a remediation window of a few days.
The directive binds the government, but the signal is for everyone. CISA urges every organization to treat the catalog as a priority queue. If a flaw is in KEV and you run the affected software, it moves to the front of the line, whatever its CVSS score says.
How to prioritize vulnerabilities: a working model
Once each signal is doing its own job, the method for how to prioritize vulnerabilities stops being a sort by severity and becomes a short sequence. You move from the most certain signal to the most specific one, narrowing at every step.
- Start with confirmed exploitation. Anything in the CISA KEV catalog that you actually run goes to the top. This is not a forecast. It is happening.
- Weight the rest by likelihood. For flaws not yet in KEV, use EPSS to separate the small set with a real probability of exploitation from the large majority that will almost certainly stay theoretical.
- Filter by your exposure. For the flaws that survive the first two steps, ask the questions only you can answer. Is the affected asset reachable, from the internet or from a foothold an attacker could plausibly get? Is it exploitable in your configuration, or do compensating controls block it? This is the difference between a theoretical weakness and a real one.
- Rank by asset value. Among reachable, exploitable, likely-or-confirmed flaws, fix the ones on the systems that would hurt most to lose.
Severity still has a place in this model, but a smaller one than the queue gives it. CVSS tells you how bad the worst case is, which matters once a flaw has already passed the exploitation and exposure filters. It is a tiebreaker near the end, not the sort key at the start. This is the core of vulnerability prioritization, and the exposure half of it, reachability and asset value, is what exposure management is built to answer.
Severity tells you how bad a flaw could be. Exploitation tells you which flaws are being used. When the two disagree, exploitation wins.
Why severity alone fails at scale
The case against severity-only triage used to be a matter of taste. In 2026 it is arithmetic. On a single day in October 2026, Microsoft's Patch Tuesday fixed more than 1,400 vulnerabilities, the largest monthly release on record, with 1,411 flaws in one batch from one vendor. Across the whole ecosystem, 2026 is a record year for disclosure. More than 40,000 CVEs were published in 2024, and by public CVE trackers the 2026 total passed 80,000 before the end of October, roughly double that figure.
Now apply a severity-only queue to that. If close to half of those CVEs are rated High or Critical, a severity sort hands you tens of thousands of equally urgent emergencies and no way to choose among them. The one flaw already being exploited, the one that should set your week, sits in the pile with thousands that never will be. At this volume, sorting by CVSS is not triage. It is a way to stay busy while the signal that matters goes unread. The recent run of actively exploited zero-days in edge devices makes the point. The flaws that cause real damage are rarely the ones a severity sort would surface first.
A worked example
Two findings land in your queue on the same morning.
The first is CVE-A, a CVSS 9.8 remote code execution flaw in a library used by an internal reporting tool. The score screams emergency. But the tool runs on a segmented network with no inbound path from the internet, the flaw's EPSS probability is near zero, and it is not in KEV. Severe in the abstract, it is close to unreachable in practice.
The second is CVE-B, a CVSS 7.5 flaw in an internet-facing VPN appliance. Lower severity, but it was added to the CISA KEV catalog last week, its EPSS probability is high, and the appliance is the front door to your network. A severity queue would work CVE-A first and leave CVE-B for later. The model inverts that: CVE-B is confirmed-exploited, reachable, and high-value, so it goes first, while CVE-A can wait for the normal cycle.
This is not hypothetical scoring. The GitLab flaw CISA added to KEV was both a CVSS 10.0 and a confirmed KEV entry, which made it an easy call. The hard calls are the ordinary weeks, when a dozen critical-rated CVEs compete for the same hours and only one or two are ever weaponized. The signals are how you tell them apart.
Where Threatless fits
Threatless is an AI-native security company, and the model above is the thinking behind Threatless CTEM. The public signals, the identifier, the severity score, the likelihood, and confirmed exploitation, are open to everyone. The work is combining them with what only you know about your own exposure, so prioritization becomes one defensible decision instead of four disconnected scores run by four different teams.
Frequently asked questions
Is a CVSS 10.0 always the top priority?
No. A CVSS 10.0 means the flaw has the highest possible technical severity, not that it is the most likely to be used against you. A 10.0 on an asset nothing can reach, with no evidence of exploitation, is a lower priority than a 7.5 that is in the CISA KEV catalog and sits on an internet-facing system. Severity is one input. Reachability and real exploitation decide the order.
What is the difference between EPSS and CVSS?
CVSS measures severity: how damaging a flaw would be in the worst case, scored once for everyone. EPSS measures likelihood: the probability, from 0 to 1, that the flaw will be exploited in the wild in the next 30 days, recalculated daily. A flaw can score high on one and low on the other. In a CVSS vs EPSS vs KEV comparison, CVSS is the impact axis, EPSS is the probability axis, and KEV is the confirmation that probability became fact.
Does CISA KEV apply to private companies?
The remediation deadlines in Binding Operational Directive 26-04 bind only US federal civilian agencies. The catalog itself is public and useful to everyone. CISA explicitly recommends that all organizations use KEV as a prioritization input. A flaw being actively exploited does not care whether you are a government agency, so the signal is worth the same to a private company.
Where do I start if all I have today is CVSS?
Add the two signals that are free and public. Cross-reference your critical and high findings against the CISA KEV catalog first, and patch anything that matches and that you run. Then pull EPSS scores to separate the likely from the merely severe. You can do both without new tooling, and together they will reorder your queue more than any amount of working down the CVSS list ever could.
The short version
CVE names the flaw. CVSS rates how bad it could be. EPSS estimates how likely it is to be used. KEV confirms it already is. No single one of them tells you what to fix first, and leaning on severity alone, the most common habit, is the one guaranteed to bury the few flaws that matter under the thousands that do not. Start from confirmed exploitation, weight by likelihood, filter by your own exposure, and let severity break the ties. That is how to prioritize vulnerabilities when the list is longer than the week.