When a KEV entry's required action is to stop using an end-of-life product, treat it as a replacement project with a deadline, not a patch ticket. Isolate the product from untrusted networks now, plan removal, and document each step, because CISA says no vendor update may exist for it.
Why KEV can tell you to remove something
CISA's criteria for adding a vulnerability to the Known Exploited Vulnerabilities catalog include a clear remediation action. CISA gives examples: a vendor provided update, or removing an end of life product. Each entry lists a required action and a due date, so you will see the wording on the catalog itself.
That means a KEV entry can land on software where patching is impossible by design. The action is still clear, and the catalog still expects you to act.
A four step decision path
- Confirm exposure. Is the product present and reachable? Check your inventory and SBOMs by product and version. Look at network placement: internet facing, internal, or isolated.
- Reduce exposure today. If the product must stay for a while, cut the paths an attacker would use. Remove public access, put it behind an access gateway, restrict the source addresses, and turn off unneeded features.
- Plan replacement. Choose a supported alternative or retire the function. Set an owner and a date.
- Record the decision. Keep a short note: what you found, what you did, what remains, and who approved the interim state.
Interim controls are not a fix
Isolation lowers risk. It does not remove the vulnerability. If the product is already compromised, isolation after the fact does not help. The KEV entry tells you that exploitation is happening in the wild, so consider whether the system might already be affected.
Check the entry's other fields. It notes whether the vulnerability is known to be used in ransomware campaigns and whether forensic triage is required under BOD 26-04. If triage is marked required, preserve logs and images before you rebuild.
What to tell stakeholders
Keep the message short and concrete:
| Question | Answer to give |
|---|---|
| What is the risk? | A known exploited flaw with no vendor fix |
| What did we do already? | Isolated or restricted access on this date |
| What is the plan? | Replace or retire by this date |
| What do we need? | Budget, a decision owner, a maintenance window |
If the deadline cannot be met, say so early and record the compensating controls. Hiding a missed date is worse than reporting it.
If you cannot retire it
Some products stay for contractual or operational reasons. In that case write a time limited exception with an expiry date, a named owner and the controls in place. Review it on the date, not when someone remembers. For handling exceptions, see vulnerability exception for end-of-life software with no patch.
For reading KEV entries in general, see what three conditions put a CVE in KEV.
Safeguard's asset discovery and SBOM scanning help you find where an end-of-life product is installed, and its policies can flag it at a gate. The free scan is at gold.safeguard.sh/scan.
Quick check
Does every KEV entry have a patch?
No. CISA says the remediation can be a vendor update or removing an end of life product.
Is isolating the product enough?
It reduces exposure but is not a fix. Plan removal, and consider whether the system may already be affected.
Sources
Last reviewed: 19 October 2026.
