IT patch management and OT patch management share a name and almost nothing else. Apply your IT patch cadence to an industrial control system and you risk unplanned downtime, warranty voidance, and potentially unsafe operating states. Apply no patch cadence to an ICS and you accumulate critical vulnerabilities in systems that control physical processes. Finding the workable path between these failures is what OT patch management actually requires.
This guide is for practitioners managing vulnerability remediation across OT environments — plant engineers, OT security leads, and IT/OT convergence teams who’ve inherited responsibility for patching systems that weren’t designed to be patched.
Why Standard IT Patch Practices Don’t Transfer
In IT, a critical vulnerability typically triggers a patch within days. Test, deploy, reboot. The downtime window is measured in minutes. In OT, the equivalent calculation is entirely different.
Availability is the primary constraint. A pharmaceutical manufacturing line, a water treatment facility, or an electricity substation may run continuously. Planned downtime might occur once per year during scheduled maintenance shutdowns. Patching a PLC mid-production cycle can interrupt the physical process it controls — and the consequences aren’t a degraded user experience, they’re potentially a safety event or product loss.
Vendor qualification requirements. Many OT vendors — Rockwell, Schneider, Siemens, Honeywell — require patches to be applied through their own qualification process before operators apply them. Applying an unqualified patch to a PLC can void support agreements and potentially certification for safety-rated systems. The vendor’s qualified patch for a given vulnerability may lag months behind the vulnerability disclosure.
Long asset lifecycles. ICS components routinely remain in service for 15-20 years. A PLC installed in 2010 may run an operating system that received end-of-life notice years ago. Its vendor may no longer provide patches. The control system vendor who built the HMI for that PLC may no longer exist.
Testing requirements. Patches to control logic, HMI software, or historian systems require functional testing in a representative environment before deployment. In many facilities, a representative test environment doesn’t exist — the production system is the only instance.
A Realistic OT Patch Process
A workable process has four components: visibility, risk prioritisation, compensating controls, and a scheduled remediation path aligned to operational windows.
Visibility: You Cannot Patch What You Cannot See
Asset inventory is the prerequisite to everything else. Many OT environments have poor visibility into what hardware and software versions are running. Before building a patch process, build an asset inventory that captures:
- All ICS components: PLCs, HMIs, RTUs, DCS controllers, safety system components
- Firmware and software versions for each
- Network connections to each asset
- Vendor support status (supported, extended support, end-of-life)
- Last known patch date
This inventory doesn’t need to be built through active scanning — active scanning of live OT networks carries real risk of disrupting sensitive components. Passive network monitoring tools (Claroty, Nozomi Networks, Dragos Platform) can enumerate assets from network traffic without generating traffic themselves. Engineering workstation software often has device catalogs that can be exported. Maintenance records may have version data.
The inventory tells you two things: where vulnerabilities exist and where no vendor patch is possible. Both require a response, but different ones.
Risk Prioritisation: Not Every Vulnerability Warrants Emergency Response
OT vulnerabilities warrant different response priorities than IT vulnerabilities. The key factors:
Exploitability from the current network position. A critical vulnerability in a PLC that’s air-gapped and reachable only via a dedicated engineering workstation on an isolated network segment is substantially less urgent than the same vulnerability in a PLC accessible from the corporate IT network. Assess your network topology against the vulnerability’s required attack path.
CISA KEV status. If a vulnerability appears in CISA’s Known Exploited Vulnerabilities catalog, it’s being actively exploited in the wild. That changes the calculus. For OT vulnerabilities, cross-reference the CISA ICS advisories for confirmation the exploit applies to your specific hardware and firmware version.
Potential physical impact. Vulnerabilities in safety systems or in logic that directly controls physical processes with public safety consequences warrant higher priority than vulnerabilities in historian software or reporting tools. This is an OT-specific risk layer that IT vulnerability scoring doesn’t capture.
Patch availability and qualification status. If the vendor has a qualified patch and the required downtime is limited, the remediation path is clear. If no patch exists, or if the patch isn’t yet vendor-qualified, you’re in compensating control territory regardless of severity.
Compensating Controls: The Primary OT Risk Reduction Tool
For vulnerabilities where patching isn’t immediately possible — which is most vulnerabilities in most OT environments — compensating controls carry the risk reduction burden.
Network segmentation. The highest-impact compensating control is removing internet exposure and limiting network connectivity to what’s operationally required. PLCs should not be reachable from the corporate IT network or the internet. If they currently are, correcting this takes priority over patching. CISA’s advisory on Iranian actors exploiting PLCs (AA26-097a) confirmed that nearly all the compromised devices in the campaign were directly internet-accessible — a configuration that had no operational justification.
Remove unnecessary services and open ports. Many ICS components run services that aren’t needed for their operational role — web interfaces, FTP servers, unused protocols. Disabling these reduces the attack surface without requiring a vendor patch cycle.
Credential hygiene. Default and shared credentials on OT components are an immediate remediation — no downtime required, no vendor qualification, no maintenance window. Change default passwords on every HMI, PLC programming interface, and historian. This addresses one of the primary attack vectors in documented ICS intrusions.
Monitoring. If you can’t patch a vulnerability, you can monitor for exploitation. OT-specific network monitoring can detect anomalous traffic, unexpected connections to PLCs, or ladder logic modification attempts. Detecting an intrusion early is the compensating control when prevention isn’t achievable.
Application allowlisting on engineering workstations. Engineering workstations that can write to PLCs are high-value targets. Allowlisting on these systems prevents execution of malicious software that arrives via phishing or removable media.
Scheduled Remediation: Aligning Patches to Operational Windows
Identify your scheduled maintenance windows in advance and plan patches into them. In facilities with annual shutdowns, this may mean accepting 11 months of compensating control before a patch deploys. That’s uncomfortable but realistic, provided the compensating controls are genuinely in place.
Build a patch queue that tracks:
- Vulnerability identifier (CVE)
- Affected asset(s)
- Vendor patch status and qualification date
- Target remediation window
- Current compensating controls
- Risk acceptance sign-off if the window is beyond 6 months
For end-of-life systems where no vendor patch will ever exist, the remediation path is replacement rather than patching. Document these assets explicitly and build a capital planning case for their replacement. An EoL PLC running a critical process without available patches is a risk that should appear in board-level risk registers, not just operational maintenance logs.
Vendor Coordination
For assets still under vendor support, establish a direct relationship with the vendor’s OT security team or customer support channel for vulnerability notifications. Most major ICS vendors (Rockwell, Schneider, Siemens, Emerson, Honeywell) have product security incident response teams (PSIRTs) that publish advisories and qualified patches.
Subscribe to:
- CISA ICS-CERT advisories (us-cert.cisa.gov/ics)
- Vendor security advisories for every product in your environment
- Sector-specific ISACs (E-ISAC for energy, WaterISAC for water/wastewater)
When a critical advisory comes out, contact your vendor to confirm which firmware versions are affected, when a qualified patch will be available, and what compensating controls they recommend in the interim.