A new CVE drops. CVSS 9.8. Affects a controller family installed in a thousand substations across your region. Your IT colleagues already have patch-Tuesday templates queued up; they're asking when the OT team plans to deploy. Operations engineering looks at you like you've lost your mind.
Welcome to the OT vulnerability dilemma. The honest answer to "when will you patch?" is almost never "this Tuesday." Sometimes it's "in our next planned maintenance window, which is four months away." Sometimes it's "not until we re-validate the entire safety case." Sometimes — and this is the part that horrifies IT — the answer is "never on this generation of equipment; we'll compensate."
That's not laziness, and it's not denial. It's a different operating regime. Let me walk through why, and what to do instead.
Why OT can't patch like IT
Three reasons stack on top of each other:
Availability is the priority, not confidentiality. In IT, a patched server is a healthy server. In OT, a patched device is a device whose behavior may have changed in subtle ways. PLC firmware updates have, on multiple documented occasions, altered scan timing enough to push a control loop into oscillation. Even if the patch is functionally correct, validation is not optional. And validation costs downtime.
Lifecycles are measured in decades, not years. The substation IED was commissioned in 2008. The vendor is still under support; the patch exists. But the engineering workstation that compiles the firmware update runs Windows XP, the cabling is fiber that was certified for that specific link budget, and the change procedure requires an outage that needs to be coordinated with the regional transmission operator. The patch is a six-month project, not a Tuesday afternoon.
The blast radius is physical. If patching a finance server fails, you restore from snapshot. If patching a PLC fails mid-deployment, you can leave the controller in a bad state where it accepts no further instructions. The recovery procedure may involve someone on a ladder, a console cable, and a manual. During an outage. Operations has every right to be conservative.
The question isn't binary
The good news is that "patch" and "ignore" are not the only options. The OT vulnerability response playbook has a few more positions, and the work is figuring out which one applies to this CVE on this asset.
- Patch on the normal cadence. Some OT assets — non-critical historians, OT-network workstations, jump hosts — really should patch like IT. They sit at the IT/OT boundary and they're not in the safety-instrumented path. Treat them like IT and stop using OT as an excuse.
- Patch in the next planned maintenance window. The default for most level-2 OT assets. The window may be months away, but it's known and resourced, and the patch can be validated against a test bench in advance.
- Compensating controls. When the patch cycle is longer than the threat tolerance, you isolate. Network segmentation, ACLs that block the vulnerable protocol, NIDS rules that alert on exploitation indicators. Document the gap and the compensating control — auditors care about the latter as much as the patch.
- Replace the asset. Sometimes the vulnerable equipment is at end-of-support and the vendor has no patch. The honest answer is a replacement project; the interim answer is compensating controls until it lands.
- Accept the risk. Document the decision, who made it, with what evidence, and revisit. This is rarer than IT teams expect and more common than OT teams admit.
How to actually decide
For every OT vulnerability that lands on your desk, three questions in this order:
1. Is the asset exposed? Not "does the CVE affect this model" — does the vulnerable interface even reach an attacker? A Modbus stack vulnerability in a PLC that's behind a data diode talking only to a SCADA server on the same level is a different threat than the same PLC connected to a routable corporate network. CVSS scores assume worst-case reachability. Your environment usually isn't worst-case. Recalculate.
2. Is the asset critical? Same vulnerability, different consequence. The PLC controlling the safety shutdown for a hydrogen sulfide release has a very different criticality from the PLC running a non-essential conveyor. Tier your assets first; let the tiering drive the urgency.
3. What's the cheapest control that closes the gap? If a firewall ACL closes the attack path, that's a Tuesday afternoon job and it buys you months. If only a firmware update closes it, you're booking a maintenance window.
What to push back on
If you're the security side of this conversation, three things to watch for and push back on:
"We've always done it this way." Sometimes the existing posture is right. Sometimes it's just inertia. Ask which one this is.
"The vendor won't certify the patch yet." Sometimes true. Often a stalling tactic. Get the certification status in writing from the vendor; if it's months out, push for an interim compensating-control plan instead of just waiting.
"It's air-gapped, so it doesn't matter." The air gap is almost never as airtight as the operations team believes. Engineering laptops crossed it last week. The historian replicates upstream. The remote-access jump host has an emergency dial-up modem that nobody turned off. Verify reachability; don't take it as given.
The blunt summary
OT patching is not slower than IT patching because OT teams are slow. It's slower because the equation includes consequences that IT teams aren't used to weighting. The job is to be clear-eyed about which vulnerabilities genuinely matter on which assets, and to bring the cheapest controls that close the right gaps. "Patch now" is sometimes correct. "Patch in three months with these compensating controls in the meantime" is more often correct. "Never patch, replace the asset on this schedule" is the honest answer more often than people want to admit.
I cover OT vulnerability management, risk calculation, and compensating control design in Chapters 13 and 14 of the OT Cybersecurity Professional course. See the curriculum.