Patch management in OT environments
In IT, patching is routine. Security publishes an advisory, the team tests the patch in staging and rolls it out to production the same week. In OT, that logic falls apart. A PLC running a packaging line has been on the same firmware since 2012. The manufacturer dropped support three years ago. And the plant can't stop to check whether a patch breaks something.
This isn't negligence. It's the reality of operating systems built to last 15 or 20 years in environments where an unplanned shutdown costs tens of thousands of euros per hour.
The root problem
OT systems weren't designed for frequent updates. A DCS in a chemical plant may run Windows XP Embedded because that was the version the vendor certified at installation. Changing the operating system means recertifying the entire solution, a process that can cost more than the equipment itself.
On top of that, many industrial devices use proprietary protocols. Updating the firmware on a Siemens S7-300 PLC requires specific tools, physical access in many cases, and a maintenance window coordinated with operations. You can't just run an Ansible playbook.
According to ICS-CERT data, the average time to patch a vulnerability in OT environments exceeds 120 days. In IT, the same metric sits around 30.
NotPetya: the lesson nobody should forget
In June 2017, NotPetya malware spread by exploiting EternalBlue, an SMBv1 vulnerability in Windows that Microsoft had patched two months earlier. OT networks at Maersk, Merck, Mondelez and dozens of industrial companies were paralyzed. Maersk lost around $300 million. Merck exceeded $800 million in losses.
The patch existed. The problem was that nobody applied it to industrial systems because "those machines don't get touched." NotPetya proved that ignoring patching in OT doesn't reduce risk. It amplifies it.
What the standards say
IEC 62443-2-3 dedicates an entire document to patch management in industrial automation systems. Its approach is pragmatic: it acknowledges that patching isn't always possible and defines a structured process for deciding what to do in each case.
The workflow it proposes:
- ▹Monitor vulnerabilities published by vendors and organizations like CISA/ICS-CERT
- ▹Assess the impact of each vulnerability on the specific assets in the facility
- ▹If a vendor patch exists, test it in a replica environment before applying it in production
- ▹If no patch exists or it can't be applied, implement compensating controls: firewall rules, disabling unnecessary services, enhanced monitoring
- ▹Document each decision and review it periodically
NERC CIP-007 requires North American electric utilities to evaluate security patches within 35 days of publication. It doesn't mandate installing all of them, but it does require documented justification for any patch not applied.
Compensating controls: when patching isn't an option
Many OT vulnerabilities never get patched. The equipment is 15 years old, the manufacturer no longer exists, or the cost of downtime outweighs the residual risk. Compensating controls are the alternative:
- ▹Isolate the vulnerable device in its own network segment with restrictive firewall rules
- ▹Disable services and ports not required for operation
- ▹Deploy anomaly detection on network traffic to and from that device
- ▹Restrict access to authorized personnel with session logging
These controls don't eliminate the vulnerability, but they shrink the attack surface to a manageable level.
Ongoing coordination, not a one-off project
OT patch management requires constant coordination between security, operations and maintenance teams. An up-to-date asset inventory, direct relationships with vendors, and maintenance windows agreed with production.
Organizations that treat OT patching as something they'll "get to eventually" end up learning the lesson the most expensive way.
Want to assess your industrial patch management process? Contact us for a no-obligation review.