EPSS in Practice: A Real Vulnerability Prioritization Workflow

Key Takeaways

• An EPSS score is a daily probability, between 0 and 1, that a specific CVE gets exploited in the next 30 days.
• CVSS measures how bad a flaw could be. EPSS measures how likely someone is to actually use it. They answer different questions, and you need both.
• Most published CVEs are never exploited. Chasing every “critical” label wastes patch cycles that should go toward the small set attackers are actually working with.
• A working prioritization model layers CVSS, EPSS, and CISA’s KEV catalog, then adds your own asset context on top.
• AI can pull these signals together fast. Scope, approvals, and the final call still belong to your team.

Your scanner just flagged 4,000 vulnerabilities as critical. Your team can patch maybe 60 this sprint. Somewhere in that math, “critical” stopped meaning anything useful, and that’s exactly the gap EPSS was built to close.

The EPSS Score, Explained

EPSS stands for Exploit Prediction Scoring System. It’s a daily-updated, machine learning model maintained by FIRST, the same group behind CVSS. So what is EPSS score in vulnerability management? Instead of asking how severe a vulnerability could be, it asks a narrower question: what’s the probability this exact CVE gets exploited somewhere in the wild in the next 30 days?

Every scored CVE gets a number between 0 and 1. A score of 0.62 means a 62% chance of exploitation in that window. FIRST also publishes a percentile, which shows how a CVE ranks against every other scored vulnerability that day.

The model pulls from a mix of signals, including:

• Whether public exploit code or a proof of concept already exists
• Mentions across security research, forums, and social channels
• How old the vulnerability is and how it was disclosed
• Patterns from past exploitation across thousands of similar CVEs

None of that touches your environment. EPSS doesn’t know if the CVE sits on an internet-facing server or an isolated dev box. It’s a global signal, not a personalized one, and that distinction matters once you start building it into a workflow.

CVSS Measures Impact. EPSS Measures Likelihood.

Any EPSS vs CVSS for vulnerability prioritization comparison starts with the same fact: they were never built to do the same job.

CVSS scores impact. It looks at things like attack complexity, privileges required, and what an attacker could do if the exploit worked, then hands back a severity number from 0 to 10. That number doesn’t move much over time, and it says nothing about whether anyone is actually trying to exploit the flaw.

EPSS scores likelihood. It changes daily as new exploit activity, chatter, and tooling show up. A CVSS 9.8 vulnerability can sit at an EPSS score near zero for months if nobody’s bothered to weaponize it. Meanwhile, a CVSS 6.5 bug with a public exploit kit circulating can spike past 0.80 within days of disclosure. If you’re wondering what is the difference between CVSS and EPSS in vulnerability scoring, that’s really the whole answer: one measures theoretical damage, the other measures real-world probability.

Here’s the pattern that trips teams up most: research from FIRST and multiple vulnerability management studies puts the share of published CVEs that are ever exploited at somewhere in the low single digits. Most “critical” findings, by CVSS alone, will never be touched by an attacker. Patch every one of them in order and you’ll burn your team’s hours on the wrong 95%.

That’s not an argument for dropping CVSS. It’s a reason to stop treating it as the whole picture. And it answers how does the lack of EPSS adoption hurt vulnerability risk accuracy: without a likelihood signal, patch queues get ordered by theoretical severity instead of real attacker behavior, and the CVEs attackers are already circling can sit behind ones that were never going anywhere.

Turning Two Scores Into One Workflow

Add CISA’s KEV catalog into the mix and you’ve got a working model. That’s how to combine CVSS and EPSS for better vulnerability prioritization, and how to build vulnerability risk scoring with CVSS and EPSS combined: three data points, used together:

1. CVSS answers: how bad is this if it goes off?
2. EPSS answers: how likely is someone to try it in the next 30 days?
3. CISA’s KEV catalog answers: has this already been used against real targets?

A simple, transparent starting model looks like this: anything on KEV jumps to the top of the queue automatically, no debate needed. Below that, weight CVSS and EPSS together, then multiply by an exposure factor for asset criticality and internet-facing status. A vulnerability with a mid-range CVSS score but an EPSS above 0.7 on a customer-facing login system should outrank a CVSS 9 sitting on an air-gapped test box.

Setting Remediation Tiers

In practice, how to use EPSS scores to prioritize vulnerability remediation comes down to tiers rather than a raw decimal:

• Immediate action: On KEV, or EPSS above roughly 0.5, on an exposed or high-value asset
• This sprint: EPSS between 0.1 and 0.5 with a fix available and reachable exposure
• Track and batch: EPSS below 0.1, no KEV listing, patched on the normal cycle
• Monitor only: Low EPSS, low exposure, revisit if the score moves

EPSS scores shift daily, so a vulnerability that sat quiet for weeks can jump tiers overnight once a public exploit drops. A static, quarterly review misses that. The scoring needs to run against your live vulnerability backlog, not a spreadsheet from three weeks ago.

What to Look for in a Tool

Before you commit to a platform, here’s how to evaluate vulnerability management tools by EPSS support rather than taking “EPSS integrated” at face value:

• Does it pull EPSS scores daily, or on some slower refresh cycle?
• Can you build tiered rules that combine EPSS, CVSS, KEV status, and asset criticality in one policy, not three separate dashboards?
• Does it re-score and re-rank open findings automatically as EPSS updates, or does someone have to re-run a report?
• Can you trace, after the fact, exactly why a given CVE landed in a given tier, for audit purposes?

That last point matters more than it sounds. When a regulator or a board asks why one CVE got patched in 24 hours and another sat for a month, “the score told us to” isn’t an answer. The reasoning has to be visible.

Where This Fits Into a Governed, AI-Driven Vulnerability Program

Scoring models solve half the problem. Someone, or something, still has to act on the tier a vulnerability lands in, and that’s where most vulnerability management programs quietly stall out. Analysts spend hours cross-referencing scores, chasing asset owners, and writing up evidence, work that has nothing to do with judgment and everything to do with volume.

This is the piece Secure.com’s Cloud Security AI Teammate is built to carry. It applies exactly this kind of layered logic, CVSS, EPSS, KEV status, and exposure, against your live cloud and infrastructure posture, then flags what needs a human decision and executes the remediation steps your team has already approved. Configuration fixes, drift correction, ticket creation, evidence collection for the audit trail, it happens inside the scope and permissions your team sets. Nothing runs outside that boundary.

That’s the “governed” part. The teammate doesn’t decide policy. It applies the policy your team already agreed on, consistently, at a pace no analyst roster can match on their own, and hands back the hours that used to go into manual score-chasing.

If you want the broader model behind how findings get ranked in the first place, we covered the mechanics in Exposure Prioritization in Practice. And if your patch SLAs keep slipping despite a scoring model on paper, that usually traces back to the same root cause we broke down in Vulnerability Remediation SLAs.

FAQs

The Bottom Line

CVSS tells you what could go wrong. EPSS tells you what’s actually likely to. Neither one, alone, gets you a defensible patch queue. Layer them with KEV and real exposure data, and the 4,000-item backlog turns into a short list your team can actually work through, with a paper trail that holds up when someone asks why.