Treat any KEV entry on an exposed system as actively exploited and fix it. But the urgency signal is strongest for recent additions. FIRST says recent exploitation is a strong indicator of near term exploitation, and that this signal degrades over time unless other evidence of ongoing activity appears.
What each source says
CISA's guidance is simple: review and monitor the KEV catalog and prioritize remediation of listed vulnerabilities. Federal civilian agencies must remediate within set timeframes under a binding directive, and CISA strongly recommends that other organizations, including private companies, do the same although they are not bound by it.
FIRST adds nuance in its Using EPSS page. It says KEV confirmation means exploitation occurred at some point. A recent addition is reasonable grounds to treat a vulnerability as high priority regardless of its EPSS score. But without other evidence of ongoing exploitation, a vulnerability added years ago reverts toward the probability its current features would predict. FIRST also notes KEV may record an isolated incident rather than sustained, widespread activity.
Two ideas, not a contradiction
CISA says act on listed entries. FIRST says the forecasting value of the listing decays. These fit together. The listing never becomes false: the CVE was exploited. What changes is how much it tells you about next month. For your decision, the practical test is whether your system is exposed and vulnerable, not how old the entry is.
A handling table
| Entry age | Component present and reachable | Suggested handling |
|---|---|---|
| Added recently | Yes | Emergency path, fix or mitigate now |
| Added recently | No | Record the check and watch for scope changes |
| Added long ago | Yes | Still fix, since it is a known exploited flaw, but check EPSS and reports of current activity to set order |
| Added long ago | No | Close with evidence |
A long ago entry that you are still carrying is also a sign. Old exploited flaws sitting in a live system suggest a patching process gap. Ask why it is still there.
Check the dates in your own data
The KEV data file includes a date added for each entry. Use it. Sort your KEV matches by date added, and split them into recent and older. Then compare to your own ticket age. Entries that are both old and unfixed in your estate deserve a root cause review, not just a ticket.
- Export your findings that match KEV.
- Add the date added field from the catalog file.
- Add the current EPSS probability and percentile.
- Flag the ones with an old date added and a low EPSS score. Those are candidates for sequencing after the recent ones, not for dismissal.
- Flag exposed internet facing items regardless of age. Those go first.
Do not use decay as an excuse
The decay point is about ordering within a queue of listed items. It is not a reason to leave a listed vulnerability open. An attacker who finds an unpatched, exposed, known exploited flaw does not care when it was listed. Keep a time limit for every KEV match, and write down who accepted any exception. See can you accept risk on a known exploited vulnerability.
Safeguard's policies and gates can hold a pull request or release when a dependency has a known exploited flaw, and reachability analysis helps show whether the code is used. 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.
Watch how a finding changes state over time, then think about where aged exploited entries would sit in your own queue.
Quick check
Can I deprioritize a KEV entry because it is old?
Only for ordering, and only with a check. FIRST says the forecasting signal fades, but CISA recommends prioritizing all listed items. If the system is exposed, fix it.
Do private companies have to follow KEV deadlines?
CISA says federal civilian agencies are bound by its directive and that other organizations are not bound, but it strongly recommends they prioritize KEV vulnerabilities too.
Sources
Last reviewed: 19 October 2026.
