Use KEV membership as the top tier trigger, because it records vulnerabilities seen exploited. Use EPSS to order the rest, since it estimates the probability of exploitation in the next 30 days. Neither knows your environment, so combine them with exposure and reachability before setting an SLA.
What each signal says
KEV. CISA describes its Known Exploited Vulnerabilities catalog as an authoritative source of vulnerabilities exploited in the wild and says organisations should use it as an input to prioritisation. Entries carry a date added and a due date, among other fields.
EPSS. FIRST describes EPSS as the probability that a published CVE will be exploited in the wild over the next 30 days, as a score between 0 and 1 with a percentile, published daily. It is a model estimate, not a certainty.
Neither one is a severity score. They answer a different question from CVSS: how likely, rather than how bad.
A simple tier design
Here is a pattern you can adapt. The thresholds are examples for you to choose, not recommendations from a standard.
- Tier 0. In KEV, and the affected component is present on an internet facing service. Fix or mitigate first, in hours to days.
- Tier 1. In KEV elsewhere, or very high EPSS on an exposed asset.
- Tier 2. Elevated EPSS or high severity with a reachable code path.
- Tier 3. Everything else, handled in normal maintenance.
Write the thresholds into policy so that people can predict the SLA of a finding before it appears.
Where these signals fall short
- New vulnerabilities may not be in KEV or have a stable EPSS score for a while. A lag exists between disclosure and exploitation data.
- Both are global. They do not know whether your product ever calls the vulnerable function.
- EPSS inputs depend on exploitation data from partners, so coverage reflects what those sources observe.
- A low score is not a clearance. Targeted attacks do not always show up in broad data.
Add the local view
Take the global signal and apply two local questions: is the asset exposed, and is the vulnerable code reachable? A KEV entry in a package that your build never loads at runtime still deserves a look, but it may not be an emergency. See how reachability cuts the noise.
Click through it at your own pace, or open it full screen.
Measure the tiers
Report time to fix per tier and the count overdue per tier. Review the tier rules each quarter by checking how many Tier 3 items later turned out to be exploited. If many did, tighten the rules.
Safeguard offers reachability analysis and policy gates, which can be used to apply tiers like these at pull request time.
Quick check
Should EPSS replace CVSS?
No. They measure different things. Use severity for impact and EPSS for likelihood, then add your own exposure data.
How often should tiers be recalculated?
EPSS is published daily, so a daily or weekly refresh of tiers is reasonable.
Sources
Last reviewed: 19 October 2026.
