I watched a compliance officer lose her mind last month when she discovered that 43 vulnerabilities on CISA’s KEV catalog affecting her agency’s infrastructure had zero available patches. The products were end-of-life. The vendors had moved on. But the binding operational directive still said “remediate within 15 days.”
This is the KEV catalog’s dirty secret: mandated timelines meet immovable reality, and nobody’s decision tree accounts for it.
THE CHECKLIST TRAP
CISA’s Known Exploited Vulnerabilities catalog now lists over 1,000 CVEs with strict patching deadlines. Federal agencies must comply with BOD 22-01. State and local governments are following suit. Cyber insurance providers are writing KEV compliance into policies. Auditors are checking boxes.
The problem? At least 15-20% of KEV entries affect products that are end-of-life, have no patch available, or require hardware replacement to remediate. I’ve seen Windows Server 2008 vulnerabilities, discontinued firewall models, and legacy SCADA systems all sitting in the catalog with the same “fix this now” mandate.
Compliance frameworks love the KEV catalog because it’s authoritative and updated. But they’re treating it like a simple true/false test. Either you patched it or you didn’t. Reality doesn’t work that way.
When the checkbox doesn’t have a viable option, you need a decision framework. Not excuses. A structured way to assess actual risk and document defensible choices.
THE DECISION TREE NOBODY TEACHES
Here’s what I tell my students: when you hit a KEV entry with no patch, you’re not stuck. You’re at a decision point that separates tool operators from actual analysts.
Start with the Diamond Model. Map all four points before you write a single exception memo.
Adversary: Who actually exploits this vulnerability in the wild? CISA adds CVEs to KEV when they have evidence of active exploitation, but “evidence” ranges from widespread ransomware campaigns to a single APT group hitting three targets in 2019. Check the original intelligence. Was this MOVEit—where Clop hit thousands of organizations—or something far more targeted?
Capability: What does the exploit require? Is it unauthenticated remote code execution from the internet, or does it need existing network access and elevated privileges? A KEV-listed vulnerability in an end-of-life VPN appliance exposed to the internet is a different universe than one affecting an internal application server behind three network segments.
Infrastructure: Where are threat actors staging these attacks from? Are they using commodity tools and public exploits, or custom frameworks? This tells you how quickly the capability spreads. SolarWinds taught us that sophisticated infrastructure means patient adversaries with specific targets. Most KEV entries aren’t SolarWinds-level.
Victim: Who’s getting hit with this exploit? If you’re a state healthcare agency and the vulnerability is being used against defense contractors by Chinese APT groups, your risk calculation changes. Not to zero—adversaries pivot—but it’s not the same as being in the primary target set.
Once you’ve mapped the Diamond Model, you can build compensating controls that address the actual attack path, not the theoretical checkbox.
COMPENSATING CONTROLS THAT ACTUALLY COMPENSATE
This is where most organizations fail. They treat compensating controls like a hall pass. “We can’t patch it, so we’ll just do more logging.”
Wrong.
Map your compensating controls to the Kill Chain phases that the vulnerability enables. If the KEV entry is an initial access vulnerability—like the Fortinet SSL-VPN issues that hit in 2021—your controls need to block reconnaissance and weaponization or detect exploitation immediately.
Network segmentation that prevents lateral movement. Application allowlisting that stops execution. EDR that catches post-exploitation behaviors mapped to MITRE ATT&CK techniques. Write down the specific ATT&CK IDs you’re addressing. T1190 (Exploit Public-Facing Application), T1133 (External Remote Services), whatever matches your scenario.
Then test them. Not in theory. Actually test whether your compensating controls would catch the exploitation technique. Red team it if you can. Tabletop it if you can’t.
I have a decision framework template at jrobertsonsecurity.gumroad.com that walks through this entire process with real KEV examples and Kill Chain mapping. My students use it to document risk acceptance decisions that actually hold up under audit.
THE CAPITAL ONE LESSON
Remember the Capital One breach? The vulnerability wasn’t exotic—it was a misconfigured web application firewall that allowed SSRF attacks. CVE-2019-5021 wasn’t on anyone’s critical list at the time because it required specific conditions.
Capital One had some compensating controls. They had logging. They had monitoring. But the controls didn’t map to the actual attack chain that the vulnerability enabled. When Paige Thompson exploited the SSRF to access metadata credentials, nothing stopped her from pivoting to S3 buckets.
The controls looked good on paper. They didn’t compensate for the actual capability the vulnerability provided to the adversary.
Now apply that lesson to KEV entries with no patches. If you’re writing an exception based on compensating controls, are they blocking the specific techniques that the vulnerability enables? Or are they just compliance theater?
DOCUMENTATION THAT SURVIVES SCRUTINY
When you can’t patch a KEV-listed vulnerability, your documentation needs to show structured thinking, not excuses.
Include the Diamond Model assessment. Show which threat actors use this exploit and against what victim profile. Include the MITRE ATT&CK techniques the vulnerability enables. Map your compensating controls to specific Kill Chain phases. Document detection rules with actual alert logic.
Set a review date. Not “we’ll revisit this eventually.” A specific date tied to either a product replacement timeline or a threat intelligence trigger. If a new exploit tool drops publicly, if your organization’s threat profile changes, if the vulnerability starts hitting your sector—you reassess.
This documentation shows auditors and leadership that you’re managing risk, not ignoring mandates. I’ve seen this approach survive everything from insurance audits to federal assessments.
THE QUESTION YOU NEED TO ANSWER
The KEV catalog will keep growing. More compliance frameworks will reference it. More vulnerabilities will land on your asset inventory with no available patch and a ticking clock.
So here’s what you need to figure out: when a mandate meets an impossibility in your environment, can you articulate the actual risk using a structured framework, or are you just hoping the auditor doesn’t ask hard questions?
Because the auditors are starting to ask.