CISA adds a vulnerability to the Known Exploited Vulnerabilities catalog because it has evidence of active exploitation, not because a fix is ready to install. In a meaningful share of KEV entries, the “Required Action” field points to a patch that does not exist yet, or to a vendor that has already told customers no patch is coming. If your asset inventory just matched a new KEV entry against an end-of-life appliance or a product still waiting on its vendor, the real question is not whether to act. It is what to do while there is nothing to install.
Why Confirmed-Exploited Bugs Sometimes Ship Without a Fix
A KEV listing only requires two things: a CVE identifier and reliable evidence that someone is exploiting it in the wild. Neither condition depends on a vendor having shipped a remedy. That gap between “confirmed exploited” and “fixable today” shows up for a few recurring reasons.
End-of-life products
Vendors routinely stop issuing security updates for a model line well before every unit is decommissioned. When an exploited flaw surfaces in a SOHO router, an old VPN concentrator, or a firewall management interface that already reached end of support, the vendor advisory is often a single sentence: upgrade to a current model, no fix will be issued for this version. CISA still lists the CVE because exploitation is real, even though the vendor has closed the ticket on their end.
Vendor disputes over scope
Some CVEs carry a disputed or contested status because the vendor argues the behavior is by design, requires prior authenticated access that lowers real-world risk, or falls outside their supported configuration. CISA’s inclusion criteria do not wait for that disagreement to resolve. If exploitation evidence exists, the CVE goes into the catalog regardless of what the vendor’s own severity rating says, which means the “official” position and the “protect your assets” position can openly conflict for weeks.
Incomplete or bypassed patches
Edge appliances such as VPN gateways and firewall management planes have a well-documented history of shipping an initial fix that closes the reported exploit path but leaves a closely related one open. A second round of exploitation targeting the same underlying defect then triggers a new advisory, sometimes under a new CVE, while the product line is technically still “patched” against the first one. Teams that patched on day one and moved on are the ones most likely to miss this.
Read CISA’s “Discontinue Use” Guidance Literally
The KEV catalog’s required action field frequently reads: apply mitigations per vendor instructions, or discontinue use of the product if mitigations are unavailable. Under Binding Operational Directive 22-01, federal civilian agencies treat that instruction as an actual decision tree with a due date attached, not as a soft suggestion buried in boilerplate. Commercial organizations that only skim the headline CVE and skip the required action text miss the part that actually tells them what to do next.
Take the second clause seriously before you dismiss it as unrealistic. “Discontinue use” does not have to mean ripping out a production system this afternoon. It means the mitigation path has a ceiling: if you cannot apply a vendor-approved mitigation and cannot compensate for the exposure through other controls, continued use of that specific product, in that specific role, is the risk you are accepting, and it should be named as exactly that in your records rather than left implicit.
The Mitigation Ladder: Five Rungs Before You Can Patch
When a patch is not available, work down a fixed sequence instead of improvising one control per asset. Each rung reduces exposure further than the one above it, and each has a cost that goes up as you descend.
- Disable the vulnerable feature. If the flaw lives in a specific service, plugin, or management protocol, turn off that component while leaving the core function running. Disabling an SSL-VPN portal, an SNMP write community, or a legacy management protocol like Telnet often removes the exploitable surface without removing the device from service.
- Restrict the interface. Where the feature cannot be disabled, put an access control list in front of it. Limit the admin interface to a named set of management IPs, force access through a jump host, or require a client certificate. An internet-facing management plane with a KEV entry gets an ACL within one business day; that is not a discussion item.
- Segment the asset. Move the device into an isolated VLAN, restrict east-west traffic to only what the device’s function requires, and block outbound connections except to the vendor’s update infrastructure. Segmentation buys time by containing what a successful exploit can reach next.
- Monitor what you cannot close. Increase log verbosity on the asset, forward logs to a system you actually review, and add detection specifically tuned to this CVE rather than relying on generic alerting.
- Retire the asset. When mitigation and monitoring both come up short, replacement is the honest answer. Set a retirement date rather than leaving the decision open-ended, and treat that date as a commitment the same way you would a patch deadline.
Set a decision rule up front: if an internet-facing asset with a KEV entry cannot reach at least rung two within 48 hours, escalate to the asset owner’s leadership rather than letting the ticket sit in a queue.
Detection as a Stopgap: What to Hunt For
Mitigation reduces the odds of exploitation; it does not prove exploitation isn’t already happening. While the ladder above is being worked, point detection specifically at this CVE rather than trusting your general alerting stack to catch it incidentally.
- Web server, proxy, and WAF logs for the exact URI patterns, parameter names, or request methods described in the vendor or CISA advisory for this specific CVE.
- Outbound connections from the vulnerable host to IP ranges or domains it has no legitimate reason to contact, especially newly registered infrastructure.
- New local admin accounts, modified scheduled tasks or cron entries, and unexpected service installations on the affected host since the KEV date.
- Configuration file changes outside your normal change window, particularly on firewall, VPN, and network appliance configs.
- Authentication log spikes, especially a burst of failures followed by a success, on the account tied to the exposed interface.
- Any published IOC or Suricata/Snort signature tied to this CVE from the vendor advisory, CISA, or a threat intel feed you already subscribe to.
If the affected device has no logging or EDR capability of its own, which is common on embedded network appliances, shift detection to the network layer: NetFlow anomalies, DNS query patterns from that subnet, and a mirrored port feeding an IDS are your fallback when the device itself cannot tell you anything.
Documenting a Temporary Risk Acceptance That Survives an Audit
A verbal agreement to “keep an eye on it” does not hold up in an incident review, and a one-line entry in a spreadsheet does not hold up in an ISO 27001 or SOC 2 audit. Build the acceptance record with the fields an auditor and an incident responder will both ask for.
| Field | What it needs to contain |
|---|---|
| Asset and CVE reference | Specific CI or asset ID, CVE number, KEV addition date |
| Reason no patch was applied | Vendor EOL notice, disputed status, or patch not yet released, stated plainly |
| Compensating controls | Exact controls applied, with implementation date and who verified them |
| Residual risk rating | A stated level, not left blank, tied to your existing risk matrix |
| Named owner and approver | An actual person and role, not a team name or ticket queue |
| Review or expiration date | A hard date the acceptance must be revisited, never indefinite |
| Control mapping | The specific clause it relates to, for example ISO 27001 Annex A 8.8 or PCI DSS Requirement 11.3 |
Where that mapping needs to stay current across several frameworks at once, for example the same acceptance touching ISO 27001, PCI DSS, and a KVKK or GDPR data-handling clause, a compliance mapping layer that ties findings to controls automatically saves you from re-deriving the same cross-reference by hand at every audit cycle. What auditors actually check is not whether the record exists, but whether it was reviewed on the schedule it committed to.
Tracking the CVE So the Mitigation Gets Replaced the Moment a Patch Lands
A mitigation that outlives its patch is a mitigation nobody is watching. Set up an explicit tracking mechanism rather than relying on someone remembering to check the vendor’s page.
Subscribe directly to the vendor’s security advisory feed for the affected product line, and poll CISA’s KEV catalog on a schedule, it is published as a machine-readable JSON feed specifically so this can be automated rather than checked by hand. Assign a named owner to the tracked CVE with a stated SLA, for example patch applied within five business days of general availability for any internet-facing asset carrying a KEV entry. When the patch lands, do not close the ticket on installation alone. Re-scan and re-validate the specific finding, since a patch that installs cleanly is not the same thing as a patch that actually closed the exploited path.
This is also where the mitigation record earns its keep across the whole lifecycle. A finding that stays open with a linked mitigation, rather than one marked resolved the moment a workaround ships, is what lets a vulnerability lifecycle process catch the handoff automatically. Platforms that ingest the KEV feed on a schedule, such as SITEY, can flag the moment a vendor publishes a fix for a CVE tied to an open mitigation record and route it straight back to the patch management owner instead of waiting for a human to notice the advisory. The mitigation was never meant to be permanent; the tracking is what keeps it from becoming permanent by accident.
Segmentation and access restriction decisions made under the mitigation ladder are also worth revisiting once the patch is applied. A device that was isolated into its own VLAN during the mitigation window does not automatically need to stay there forever, but it should not silently drift back to its old exposure either. Reviewing exposure through a network reachability view before and after the patch closes that loop instead of leaving it to whoever remembers the original change ticket.
None of this replaces the patch. It buys the time between “confirmed exploited” and “actually fixed” without pretending that time doesn’t carry risk. Platforms that automate this phase, such as SITEY, treat a compensating control as a temporary state with a recheck date attached, not as a closed finding, which is the same discipline this whole process depends on whether or not any tooling is involved.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.