CISA’s Known Exploited Vulnerabilities catalog was built for a world of servers, endpoints, and patch management systems that can push an update and roll back if something breaks. Federal Binding Operational Directive timelines attached to KEV entries — often 15 days for actively exploited flaws, 21 days in adjacent guidance for less severe but still catalog-listed items — assume you can take the asset offline, patch it, test it, and bring it back before lunch. That assumption has never held for a PLC running a validated process, and it holds even less now that CISA is publishing ICS advisories at a steady clip and flagging a growing share of them as KEV.
The mismatch isn’t a paperwork problem. It’s structural. A programmable controller running a filling line, a batch reactor, or a stamping press isn’t a general-purpose computer you patch on Patch Tuesday. It’s a component of a validated system, sometimes literally validated in the FDA or pharmaceutical sense, sometimes validated in the plainer sense that engineering signed off on a configuration that took months to tune and nobody wants to touch it uninvited. Firmware updates on PLCs, HMIs, and industrial switches routinely require a maintenance window, a vendor field service engineer, a regression test of the whole cell, and — in regulated industries — a documented revalidation. None of that happens in 15 days, and pretending it can is how plants end up either lying on a compliance attestation or blowing a shutdown schedule to chase a patch for a vulnerability that isn’t even reachable from the internet.
So the real question for plant IT and OT security leads isn’t “how do we patch faster.” It’s “how do we build a documented, risk-based process that gets us to an equivalent security outcome on a timeline the plant can actually hit — and that survives an audit or an insurance underwriter’s questions.” That’s a solvable problem. It just requires treating compensating controls as a first-class, documented control state, not an excuse.
Start by separating “vulnerable” from “exposed”
The KEV catalog tells you a CVE is being actively exploited somewhere, by someone, against some population of devices. It says nothing about whether your specific PLC is reachable by the exploit path. This is the single most useful fact plants underuse. A vulnerability in a Modbus TCP stack that requires network access to the device is a very different risk on a flat, unsegmented plant network than it is on a controller sitting behind a properly configured industrial DMZ with no route from the corporate side and no direct internet path.
Before you argue about patch timing, do the exposure assessment: what’s the actual reachability of the affected asset, from what zones, over what protocols, and is there an existing detection or prevention control already sitting in that path. This is standard ISA-95/ISA-62443 zone-and-conduit thinking, and if you’ve already built your network architecture around it — Purdue-model segmentation, a demilitarized zone between the enterprise and control networks, conduits with explicit allow-lists rather than implicit trust — you already have most of the raw material for a compensating-control justification. If you haven’t built it that way, this exercise usually turns out to be the more urgent finding.
The three compensating controls that actually hold up
Auditors and underwriters have seen a lot of hand-waving around “we have compensating controls.” The ones that hold up share a trait: they’re specific, they’re monitored, and they produce evidence.
- Network segmentation with enforced conduits. Not “the OT network is on a different VLAN” — a documented architecture showing the affected zone, the firewall or layer-3 ACL enforcing the boundary, the specific rules that would have to be bypassed to reach the vulnerable service, and evidence the rule set hasn’t drifted (a config diff or periodic audit).
- Virtual patching via an inline IPS or industrial protocol-aware firewall. If you can write or deploy a signature that blocks the specific exploit pattern or protocol function code associated with the CVE, you’re not just hoping the segmentation holds — you’re actively shielding the vulnerable function. This is the closest thing to an equivalent-outcome argument: you haven’t patched the code, but you’ve removed the attacker’s practical path to the vulnerable function.
- DMZ isolation and jump-host access control. If engineering or vendor remote access to the affected system is mediated through a hardened jump host with session recording and MFA, that materially reduces the credential-theft and lateral-movement path that a lot of ICS exploitation chains actually depend on, even when the underlying CVE is unpatched.
None of these is a substitute for eventually patching. All of them are legitimate ways to say, credibly, “the residual risk of this unpatched vulnerability is materially reduced and being actively monitored,” which is what both an auditor and an underwriter are actually trying to assess.
Build the risk-based cadence before the next KEV entry hits your fleet
The plants that handle this well don’t scramble per-CVE. They have a standing tiering model, decided in advance, that maps vulnerability severity and exposure to a response tier with a defined timeline and a defined set of acceptable compensating controls per tier. Something like: internet-reachable, KEV-listed, no compensating control in place — emergency change, expedited even if it means a planned brief outage. KEV-listed but network-isolated with an enforced conduit and IPS signature deployed — scheduled into the next maintenance window, typically weeks, not days, with the compensating control status documented and reviewed. Non-KEV, low-severity, isolated — folded into the normal periodic patch cycle.
Write this down as policy, get plant management and the security team to sign it, and revisit it on a fixed schedule rather than reinventing it every advisory. That document is what you hand an auditor instead of an apology. It’s also close to exactly what a cyber-insurance underwriter wants to see during renewal: not proof that you patch on federal timelines, which they know is unrealistic for OT, but proof that you have a governed process that maps exposure to action and that compensating controls are actual technical controls with evidence behind them, not a shrug.
What to actually put in front of an underwriter
Underwriters increasingly ask pointed questions about ICS/OT patch management as part of renewal, and “we can’t patch, the line’s running” is the answer that gets your premium reviewed unfavorably or your coverage sublimited. The answer that works is a short packet: the tiering policy, the network architecture diagram showing zones and conduits, the IPS/firewall rule evidence for any virtual patch in place, and a log showing you tracked the specific KEV entry, assessed exposure, applied a compensating control, and scheduled remediation. That’s a materially different conversation than an unpatched CVE with no documentation at all, and it’s the difference between “this shop has a program” and “this shop got lucky.”
CISA isn’t going to slow the advisory cadence, and KEV listings aren’t going away. The plants that come out ahead aren’t the ones that figure out how to patch a validated line in fifteen days — most genuinely can’t. They’re the ones that can prove, on demand, that their risk was reduced to an equivalent level through controls that were already built in, not improvised after the advisory dropped.
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.
