Add three local checks to the EPSS score: presence, reachability and consequence. FIRST says a high score on a vulnerability you do not have does not matter, and that a present flaw is only exploitable if an attacker can meet the conditions. Where all three are strong, remediation does the most good.
Why the score alone is not enough
EPSS reflects exploitation probability across the global observed population. FIRST says that is both a strength and a limit: it draws on a huge number of events, but it does not know what is in your environment, whether an attacker could reach it, or whether it is already under attack.
Check 1: presence
Is the vulnerable component actually in your estate? Cross-reference scores against the CVEs found in your own systems before acting. That means a current inventory: an SBOM for each application, container image contents, and a list of hosts and services. A score for a product you do not run is not your problem. A product you forgot you run is.
Check 2: reachability
FIRST says a present vulnerability is only exploitable if the conditions exist and are achievable by an attacker. Network exposure, authentication requirements and compensating controls all matter. For libraries, ask whether your code calls the vulnerable function. For services, ask who can send a request to it.
Check 3: consequence
Exploitation on critical infrastructure, on a system with sensitive data or on a well connected asset carries different weight from the same flaw on a low value, isolated system. This is your business context, and no public score has it.
A decision table
| EPSS | Present | Reachable | Consequence | Suggested action |
|---|---|---|---|---|
| High | Yes | Yes | High | Emergency path |
| High | Yes | Yes | Low | Fix in the next cycle |
| High | Yes | No | Any | Fix on schedule, record why it is unreachable |
| High | No | n/a | n/a | Close with evidence |
| Low | Yes | Yes | High | Fix on schedule, watch for signal changes |
| Low | Yes | No | Any | Normal schedule |
KEV is the override. FIRST says when a vulnerability appears on KEV, treat it as actively exploited and prioritize accordingly regardless of EPSS.
Make the checks cheap
- Keep the inventory current, so presence is a lookup, not a hunt.
- Tag internet facing assets, so reachability starts with a filter.
- Tag assets by data sensitivity, so consequence is a field.
- Automate the join of EPSS and KEV against those tags, and review the top of the list daily.
The first month is manual and slow. After that, most findings resolve in seconds from tags, and people spend time on the few that need judgement.
What to record
Write the three answers next to the score in the ticket. Months later a reviewer sees why you fixed or deferred, without re-doing the work. This also builds the evidence for the risk register, as covered in citing EPSS in a risk register.
Safeguard's asset discovery, SBOM and dependency scanning cover presence, and reachability analysis covers the second check, with policies to enforce what you decide. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability is applied, and see which findings would stay on your emergency path.
Quick check
Can a high EPSS score be ignored?
Yes, if the component is not present or cannot be reached. FIRST says one missing check reduces urgency regardless of the score. Record the evidence.
Does a low EPSS score override KEV?
No. FIRST says to treat a KEV listed vulnerability as actively exploited regardless of its EPSS score.
Sources
Last reviewed: 19 October 2026.
