BLOG

OT Patch Management: How to Patch Industrial Systems Without Stopping Production

Every IT security professional knows the rule: patch fast, patch often. Apply critical patches within 24 hours. Apply high-severity patches within 7 days. Run automated patching on nights and weekends. This rule has served IT security reasonably well, but it does not transfer to operational technology environments.

A PLC controlling a live polymerization reactor cannot be patched on a Tuesday night. A DCS managing a continuous crude distillation unit does not accept a firmware update because the security team's vulnerability scanner flagged a critical CVE. And a safety-instrumented system protecting against a hazardous chemical release cannot be rebooted during production to apply a vendor patch, regardless of CVSS score.

According to Claroty's 2024 State of CPS Security Report, the majority of OT vulnerabilities cannot be remediated through patching within standard IT timelines due to operational constraints. The average time between vulnerability disclosure and remediation in OT environments is measured in months to years, not hours to days. Building a functioning OT patch management program means accepting this reality and designing a program that manages risk within it, rather than pretending the IT model can be applied unchanged. It starts with the same foundation as any OT security program: knowing what you have.

Why OT Patching Cannot Follow the IT Playbook

Continuous Operations with No Patch Windows

Many industrial processes run continuously 24 hours a day, 365 days a year, with planned shutdowns occurring quarterly, annually, or less frequently. A refinery turnaround, during which the plant shuts down for maintenance, may last two to four weeks and occurs once every four to five years for some units. Outside of that window, the control systems managing the process cannot be taken offline for updates. For a PLC at Level 1 of the Purdue Model, "patch it now" is simply not an option in a live operating environment.

Vendor Validation Requirements

OT vendors typically require that firmware updates and software patches be tested and validated before deployment, and many require that the update be applied by or in the presence of a certified vendor engineer. A patch to an Emerson DeltaV DCS controller that has not been tested in a staging environment matching the production configuration may change control behavior in unexpected ways. Vendors who have signed support agreements will often void support terms if unauthorized patches are applied without going through the formal validation process. This is not a bureaucratic obstacle: it reflects the genuine complexity of validating that a control system behaves correctly after an update to deeply embedded code.

Legacy Platforms with No Patch Available

A substantial portion of the OT asset base in operation today runs on platforms that are no longer supported by their vendors. Windows XP and Windows 7 still power HMIs and engineering workstations in industrial facilities that were commissioned before those operating systems reached end-of-life. Legacy PLCs running firmware from the early 2000s receive no security updates because the vendor no longer supports them. When patching is not possible, compensating controls at the network and access layer become the primary available defense.

Fear of Breaking a Working System

The "if it is not broken, do not fix it" philosophy is deeply embedded in OT culture, and it is not irrational. A control system that has run reliably for 10 years provides genuine value that a software update could disrupt. OT engineers have direct experience with vendor updates that introduced bugs, changed control behavior, or required extensive recalibration after deployment. The risk of an update breaking something operational is real, and it weighs against the more abstract risk of a vulnerability being exploited.

Building a Risk-Based OT Patching Framework

The goal of OT patch management is not to achieve 100% patch currency. It is to ensure that every unpatched vulnerability has either been remediated, mitigated with compensating controls, or accepted with documented rationale. This requires a systematic process.

Step 1 — Build and Maintain a Complete OT Asset Inventory

Patch management requires knowing what versions of firmware and software are running on every device in your environment. Without a validated asset inventory, you cannot determine which devices are affected by a given vulnerability advisory. Passive network monitoring tools can assist with inventory building, but they need to be supplemented by review of engineering project files, vendor contracts, and physical device labels for assets that do not communicate on the network. OT asset visibility is the prerequisite for every downstream security activity.

Step 2 — Monitor Vulnerability Intelligence Sources

Subscribe to and actively triage vulnerability advisories from:

CISA ICS-CERT advisories (published weekly, OT-specific)
Vendor security bulletins from every OT vendor whose products are deployed in your environment
Platform-specific notification programs from Siemens ProductCERT, Rockwell Automation Security Advisories, Schneider Electric, and ABB
Industrial cybersecurity intelligence platforms that aggregate OT-specific vulnerability data

Each advisory should be triaged against your asset inventory to determine which of your devices are affected before any remediation decision is made.

Step 3 — Score Vulnerability Risk in OT Context, Not by CVSS Alone

CVSS scores measure the theoretical severity of a vulnerability in an IT context. In OT, the relevant risk factors are different. A CVSS 9.8 vulnerability in a PLC firmware version that is not reachable from any network segment outside its own isolated production zone is a lower near-term priority than a CVSS 6.0 vulnerability in an HMI that has a direct IT network connection. OT vulnerability assessment contextualizes every finding against the actual network architecture.

Risk Factor	High OT Priority	Lower OT Priority
Reachability	Accessible from the IT network, vendor remote access, or across zone boundaries	Isolated within a dedicated production zone with no external connections
Authentication requirement	Exploit requires no authentication (zero-click)	The exploit requires valid credentials or physical access
Operational consequence	Affects process control or safety function	Affects historian, reporting, or enterprise integration only
Exploit availability	Public proof-of-concept exploit available	No public exploit; theoretical vulnerability
Patch availability	Vendor patch available and tested	No patch available; compensating controls required

Step 4 — Define Compensating Controls for Unpatched Systems

For every vulnerability that cannot be patched within an acceptable window, document a compensating control: the specific technical measure that reduces the exploitability of the vulnerability until patching is possible. Common compensating controls in OT patch management include:

Network access restrictions that prevent the vulnerable device from being reached from outside its intended zone
Disabling the specific service or protocol component that contains the vulnerability, if operationally feasible
Adding monitoring rules that detect exploitation attempts targeting the specific vulnerability
Increasing the frequency of integrity checks on the affected device

Compensating controls are not a permanent substitute for patching, but they are the mechanism that makes an unpatched OT environment defensible. Documenting them is also a regulatory compliance requirement under NERC CIP for Bulk Electric System operators.

Step 5 — Schedule Patching Into Maintenance Windows

Every patch that requires a device restart or a control system shutdown needs to be scheduled into a planned maintenance window. Work with operations leadership to identify the windows available, prioritize which patches will be applied at each window based on your risk scoring, and prepare vendor validation documentation in advance. For critical patches where waiting for a scheduled turnaround represents unacceptable risk, develop a plan for an emergency maintenance window with appropriate change management approval.

Step 6 — Test Before You Deploy to Production

Every patch applied to a production OT system should be tested in a staging environment or on a spare device first. For HMIs and engineering workstations running Windows, this means applying the patch to a test system and validating that SCADA applications, historian connections, and vendor software continue to operate correctly. For PLC firmware, this means applying the update to a spare device of the same model and verifying control behavior before scheduling production deployment. OT backup and recovery snapshots taken immediately before patching provide the rollback point if something goes wrong.

What to Do When You Cannot Patch

The honest reality of OT patch management is that a significant proportion of vulnerabilities in any industrial environment cannot be patched in the near term. The risk management response is not to ignore them: it is to implement compensating controls that reduce exploitability, document the risk acceptance decision with appropriate approval, and maintain a remediation backlog that gets reviewed at every planned maintenance window.

The OT patching service covers the full lifecycle: from initial advisory triage through risk scoring, compensating control implementation, scheduled remediation, and post-patch verification. For environments with a significant legacy platform debt, this structured approach is the difference between a managed risk posture and an unmanaged one.

IEC 62443 Requirements for Patch Management

IEC 62443-2-3 specifically covers patch management for industrial automation and control systems. It defines requirements for: maintaining an inventory of installed software versions, monitoring vendor patch releases, assessing patch applicability and operational impact, testing patches before deployment, and documenting the rationale for any patching decision, including deferral. This standard provides the framework that OT security programs use to formalize the ad hoc patching processes that most industrial operators currently rely on.

Frequently Asked Questions

How often should we review OT vulnerability advisories?

CISA ICS-CERT publishes advisories on a weekly cycle, typically on Tuesdays. Your advisory triage process should run on the same cycle. Each advisory should be matched against your OT asset inventory within 48 hours of publication to determine which, if any, of your assets are affected. Advisories affecting assets with known network exposure should be escalated for immediate risk assessment.

What is the difference between OT patch management and OT vulnerability management?

OT patch management is the subset of OT vulnerability management that specifically concerns applying vendor-released software and firmware updates. OT vulnerability management is the broader program that covers the full vulnerability lifecycle: discovery, assessment, prioritization, remediation (which may include patching, compensating controls, or risk acceptance), and ongoing tracking. Many vulnerabilities in OT environments are managed without patching, through compensating controls and documented risk acceptance, because patches are not available or cannot be applied within operational constraints.

Can we use automated patch management tools in OT environments?

Standard IT automated patch management platforms such as WSUS, SCCM, and Ansible can be used for IT-like assets in the OT environment, specifically engineering workstations and historian servers running standard Windows or Linux operating systems with network connectivity. They cannot be used for PLC firmware, DCS controller updates, or any control device that requires vendor-specific tooling and validation processes. Attempts to push automated patches to PLC or DCS assets without vendor involvement risk interrupting control functions.

NERC CIP requires patch management for our control systems. What does compliance look like?

NERC CIP-007 specifically covers security management control,s including patching for Bulk Electric System cyber assets. CIP-007-6 requires identifying and assessing security patches within 35 days of vendor release, installing security patches within defined timelines, or documenting the reason for not installing a patch and any mitigation in place. The documentation requirement is what most operators initially underestimate: every unpatched vulnerability needs a documented rationale and compensating control, not just an acknowledgment that the patch exists.

Ready to assess your OT security posture?

We work with industrial operators to build practical, risk-based OT security programs that account for operational constraints. Book a free consultation to discuss your environment and where to start.

Book Your Free Consultation at aristacyber.io