For years, the Known Exploited Vulnerabilities catalog was mostly an IT problem wearing an OT costume. Federal civilian agencies had to remediate on CISA’s timeline; everyone else treated KEV inclusion as a strong signal and moved at their own pace. That gap is closing. CISA has been adding a steadily growing share of ICS and SCADA CVEs to KEV, and the remediation-deadline mentality that used to live in Binding Operational Directive 22-01 is increasingly showing up in how insurers, auditors, and prime contractors talk about industrial vulnerabilities generally. If a CVE affecting your HMI or PLC firmware lands in KEV, someone in your supply chain is going to ask when it gets fixed, and they’re going to ask like it’s a Windows server.
The uncomfortable truth is that a KEV listing and a patchable fix are two different things. A lot of ICS advisories describe vulnerabilities in controllers that are end-of-life, running firmware that hasn’t been updated in years, or sitting in a process that genuinely cannot come down for a maintenance window until the next planned outage. “Patch within a specified window” is a reasonable directive for a fleet of laptops. It’s not a reasonable universal answer for a Modbus-speaking PLC that’s been running a extrusion line since before most of your security team was hired.
Why the IT playbook doesn’t transfer cleanly
KEV remediation deadlines were built around an assumption: you can test a patch, deploy it, and roll back if something breaks, all without materially interrupting the business. In IT, that’s mostly true. In OT, patching a PLC or HMI often means scheduling downtime, revalidating a control loop, re-certifying a safety function, or coordinating with an OEM who controls the firmware release cycle and isn’t on your timeline. Some of the affected devices don’t support remote patching at all — you’re talking about a technician with a laptop and a serial cable, on a unit that may not have a spare.
None of that makes the vulnerability less real. It does mean that “patch by the deadline” isn’t an achievable instruction for a meaningful slice of the ICS/SCADA CVEs now flowing into KEV. What auditors, insurers, and increasingly your own risk committee actually want isn’t necessarily a patch — it’s evidence that you understood the exposure and did something proportionate about it. That’s what a compensating control is, and it’s worth treating the documentation of one as seriously as the control itself.
What actually counts as a compensating control
The concept isn’t new — IEC 62443 and NIST 800-82 both assume from the outset that not every OT vulnerability gets remediated by patching, and both frameworks build in the idea of layered, compensating protections. The mistake plants make is treating “we have a firewall” as a complete answer. A defensible compensating control has three components: it has to actually reduce the exploitability of that specific vulnerability, it has to be verifiable rather than aspirational, and it has to be documented in a way that ties back to the specific CVE.
Network isolation, done specifically
Segmentation is the most common answer, and it’s often the right one, but “the OT network is segmented from IT” is not a compensating control statement — it’s a network diagram claim. What auditors and insurers want to see is that the specific vulnerable device sits behind a firewall or industrial DMZ that blocks the specific protocol and port the vulnerability depends on, that there’s no routable path from an untrusted zone to that device, and that the segmentation has been validated — not just designed. If your Purdue Model diagram says Level 2 devices are isolated from Level 4/5, but nobody’s run a scan to confirm there’s no forgotten VPN or vendor remote-access box bridging the zones, that diagram is a liability, not evidence.
Monitoring that’s tuned to the vulnerability, not generic
Passive OT monitoring — Dragos, Claroty, Nozomi, or an open-source equivalent feeding an OT-aware SIEM — is a legitimate compensating control, but only if it’s actually watching for the behavior that exploitation would produce. If the CVE involves unauthenticated write access to a PLC’s control logic, your monitoring justification needs to say you’re alerting on unexpected logic-download or configuration-change traffic to that device, not just “we have a SPAN port on the OT switch.” Generic network visibility is good hygiene. It is not, by itself, a documented mitigation for a specific KEV entry.
Access restriction that survives a real audit
This is where a lot of compensating-control writeups fall apart under scrutiny. Restricting access has to mean something concrete: engineering workstation access locked to named users with MFA, remote vendor access routed through a jump host with session recording and time-boxed credentials, physical access to the cabinet controlled and logged. If your “access restriction” is a shared password that’s been the same since commissioning, don’t write it down as a mitigation — an insurer’s post-incident review will find it, and a stated-but-false control is worse for you than an honestly disclosed gap.
Building the justification document
Whoever is going to read this document later — an auditor, an insurance underwriter, a federal contracting officer, your own leadership after an incident — needs five things spelled out per affected asset: the CVE and KEV listing date, why patching isn’t currently feasible (be specific: OEM hasn’t released a validated patch, device is end-of-life, patch requires a shutdown only available at the next planned outage), the compensating controls in place mapped to how each one reduces exploitability of that specific vulnerability, how those controls are verified on an ongoing basis rather than just installed once, and a target date or trigger condition for actual remediation. That last piece matters more than people think. A compensating control without a remediation horizon reads as a permanent excuse rather than an interim measure, and that’s exactly the distinction auditors are trained to probe.
The insurer angle is not optional anymore
Cyber insurance underwriters have gotten considerably more literate about OT in recent years, and KEV status is increasingly a line item on renewal questionnaires. A carrier asking whether you have unremediated KEV-listed vulnerabilities in your environment is not asking a rhetorical question — a “yes” with no documented compensating control can affect terms or trigger exclusions after an incident. The same justification document you build for an ISA/IEC 62443 audit or a customer security questionnaire is the one you want ready before renewal season, not assembled retroactively after a claim.
Don’t wait for the deadline to start the conversation
The plants that handle this well aren’t the ones with the fastest patch cycles — they’re the ones that already have an asset inventory precise enough to know, within hours of a new KEV entry, exactly which controllers and HMIs on their floor are affected. If you’re still doing that lookup manually against a spreadsheet that’s a year out of date, that’s the actual gap to close before the next advisory drops, not the patch itself.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
