Where the Myth Comes From
Patching in the OT/ICS space has always been tricky. Many of the systems still in use today were designed 10, 20, even 30 years ago before cybersecurity was a consideration and before remote access became commonplace. Updates often meant downtime, requalification, and risk of unexpected side effects.
Engineers were (and still are) rightly cautious about anything that could impact system stability and because many of these environments operated in isolation, unpatched systems didn’t seem like a problem.
But things have changed. The idea that “we’re air-gapped, so we’re safe” doesn’t hold up anymore. Connections to enterprise networks, third-party vendors, cloud services, and remote access tools have all eroded that assumption.
Now, unpatched systems aren’t just old, they’re exposed.
The Reality: Patching is About Risk Management, Not Perfection
Let’s be clear: patching in OT/ICS environments isn’t easy, and it’s rarely as straightforward as in IT. You can’t just push updates overnight and reboot a PLC mid-process. But that doesn’t mean patching isn’t necessary.
Modern threat actors (ransomware groups, state-sponsored attackers, and even disgruntled insiders) routinely exploit unpatched vulnerabilities to gain access, move laterally, and disrupt operations. The infamous BlackEnergy1 and Industroyer2 attacks both exploited known software and firmware flaws. So have countless ransomware incidents that shut down everything from steel plants to pipelines.
Unpatched systems are low-hanging fruit for attackers. And they’re usually the first stop on the way to something far more damaging.
Why Organizations Avoid Patching and What It Costs
We’ve seen all the usual reasons OT teams hesitate to patch:
But here’s what often doesn’t get considered:
The cost of not patching can be far greater than the cost of doing it.
When industrial organizations have a cybersecurity incident, it can take weeks of recovery, manual operation, and forensic triage to get back online. For example, when Norsk Hydro was the victim of a ransomware attack it affected production and led to at least $70 million in costs. A patch management program doesn’t just reduce the chances of compromise, it dramatically lowers the blast radius if (or when) one happens.
But there’s another, often overlooked, reason to have a patching strategy as part of your normal operations. Eventually, there could be a “MUST-PATCH-NOW” incident that does happen. This might be from regulatory (maybe your sector gets new regulations after someone else has a high-profile incident). This might be from a security incident in one division or plant leading to necessary changes and updates across your other plants, or any other scenario you might think of.
When that happens, it is relatively easy to respond if you already have a patch and update strategy. But if you haven’t done any patching since things were first deployed, figuring out how to even start to respond is difficult. If your systems are multiple versions behind, then you may not even be able to apply that must-patch update. Figuring out the multi-step upgrade path during a high-pressure incident increases the degree of difficulty.
The Right Way to Approach Patching in OT
You don’t need to patch everything instantly. In fact, you shouldn’t. But you do need a structured, risk-based process. One that fits OT’s unique constraints but still drives progress.
1. Start With Visibility
Before you can patch anything, you need to know:
- What assets you have
- What versions they’re running
- What vulnerabilities they carry
If you don’t have this inventory, start there. Passive asset discovery tools and vulnerability mapping (from ICS-aware vendors) can help. But don’t ignore the tribal knowledge of your operators and maintenance teams as they often know more than any scan will tell you.
2. Prioritize Based on Risk
Not all patches are equal. Focus first on:
- Internet-facing systems
- Remote access tools
- Devices in shared or flat networks
- Anything used for remote vendor access
Those can be followed by systems supporting safety-critical functions or core process control.
3. Build Patch Windows into Maintenance Schedules
Don’t wait for a crisis. Align patching activities with your existing maintenance windows or planned outages. Bundle firmware updates with preventive maintenance work. And where immediate patching isn’t feasible, use compensating controls: segmentation, access restrictions, and monitoring.
4. Test First, Patch Second
You don’t need a full lab replica, but you do need a safe way to test. Even a virtualized environment or bench-top setup can catch issues before they cause a plant-wide disruption. And when you do patch, ensure rollback procedures are in place. Patching without a backup plan isn’t resilience, it’s roulette.
5. Document, Communicate, Repeat
Track what’s been patched, what hasn’t, and why. Make that data visible not just to compliance teams, but to operational leadership. When patching is part of a visible, well-governed process, it gains legitimacy. It becomes part of safety and reliability, not a side project from “cyber.”
Final Thoughts: Patching Isn’t the Enemy of Uptime, Neglect Is
If you still believe patching is too risky for your OT systems, consider this:
Most attackers don’t need zero-days. They need unpatched systems and you’re giving them exactly what they want.
The myth that “we can’t patch OT” is no longer an excuse. It’s a liability. Smart, structured patch management is part of operational excellence. It’s part of resilience. And it’s how you stay in control even when threat actors are at the door.
Let’s Move Past the Myth
Cybersecurity in OT isn’t about perfection, it’s about progress. At Enaxy, we help critical infrastructure organizations develop patch strategies that respect operational realities and reduce real-world risk.
Need help getting started? Reach out to info@enaxy.com. Let’s build a patching process that works for your environment without sacrificing safety, reliability, or uptime.
2 https://www.securityweek.com/industroyer-ics-malware-linked-ukraine-power-grid-attack/