In an office, patching is routine. Updates install overnight and computers restart. In operations, the same approach can halt production, interrupt a pipeline, or cause a safety event. Control systems run continuously, vendors certify specific software versions, and an unplanned reboot can have real physical consequences.
That does not mean OT systems should go unpatched forever. It means patching needs a different method, one that weighs risk honestly and uses other protections when an update has to wait.
Why OT patching is different
Several realities make industrial patching harder:
- Uptime requirements. Many systems run around the clock, and downtime is scheduled weeks in advance, if at all.
- Vendor certification. Control system vendors often validate specific operating system and application versions. An unapproved patch may void support or break functionality.
- Legacy platforms. Some systems run operating systems that no longer receive security updates.
- Safety implications. A failed update on a controller or safety-related system is not just an IT inconvenience.
- Limited testing capacity. Few operators have a duplicate system on which to test updates first.
Step 1: Know what you have
You cannot patch intelligently without an inventory. For each system, record the device or software, the version, the vendor, how it connects to the network, and who is responsible for it. Even a spreadsheet is a major improvement over memory.
Step 2: Track vulnerabilities that matter
Subscribe to your vendors' security advisories and watch CISA advisories for industrial control systems. When a notice appears, check it against your inventory. Most will not apply to you. The few that do deserve attention.
Step 3: Rate the risk, not just the severity score
A high severity score does not automatically mean high risk for your site. Ask:
- Is the vulnerable component reachable from the network, and from which networks?
- Does exploiting it require physical access, a login, or nothing at all?
- Is the system exposed to the internet or to vendor remote access?
- What is the operational impact if it is compromised or if the patch fails?
- Is there evidence the vulnerability is being actively exploited?
A flaw on an isolated system with no remote path may be low priority. The same flaw on a system reachable from the corporate network is much more urgent.
Step 4: Use compensating controls when you must wait
When a patch cannot be applied soon, reduce exposure in other ways:
- Segment the system so only necessary devices can talk to it.
- Block or restrict the vulnerable service at a firewall.
- Disable unused services and ports.
- Remove direct internet or email access from the machine.
- Restrict removable media.
- Increase monitoring on the affected system.
Document these decisions, including who accepted the residual risk and when you will revisit it.
Step 5: Plan maintenance windows
Work with operations to identify planned outages, turnarounds, or low-demand periods. Prepare in advance:
- Confirm the vendor has approved the update for your version.
- Take a verified backup of configurations and images.
- Write a step-by-step procedure with a rollback plan.
- Assign roles for operations, IT, and the vendor.
- Test on a spare or lab system where possible.
Step 6: Verify and record
After patching, confirm the system operates normally and record what changed. Update the inventory. If something went wrong, capture lessons for the next window.
Handling unsupported systems
Some systems cannot be patched at all because the platform is out of support or the vendor no longer exists. For these, isolate them as aggressively as practical, keep a tested backup image, plan replacement as part of capital budgeting, and be honest in risk registers about what they represent.
The cultural piece
Patching in OT works best when IT and operations treat it as a shared decision. IT brings vulnerability knowledge, operations brings process knowledge, and neither should decide alone.
Working with Ironfield Cyber
Ironfield Cyber helps operators build OT inventories, rank vulnerabilities by actual exposure, and design segmentation and compensating controls. If you have systems your team is afraid to touch, we can help you make a plan.