ICS patch management is an engineering process, not an IT software update. You inventory every control asset, decide which vulnerabilities can actually reach it, test each patch against a known-good backup, deploy only inside a planned maintenance window, and record the system's state before and after. When a patch cannot be applied, you isolate the asset with compensating controls instead of leaving it exposed.
This guide walks through that process for oil and gas, energy and other regulated operators, including what to do with legacy devices and how to keep the records an auditor will ask for.
TL;DR
- Do not apply an IT scan-and-patch approach to control systems. CISA's recommended practice treats patching as a coordinated decision among IT, security and process engineering.
- Follow a repeatable cycle: inventory, identify, filter for relevance, approve, test and deploy, then baseline and document.
- Prioritize by reachability in your architecture, not by CVSS score alone, and align deployment with planned maintenance windows.
- For unsupported or unpatchable devices, use segmentation and hardening, and keep a supportability record for every asset.
- Documentation is the step most often skipped, and the one auditors check first.
Table of Contents
- Why control systems cannot be patched like office PCs
- The six-step ICS patch management cycle
- Prioritize by reachability, not by score alone
- Work inside maintenance windows
- When you cannot patch: compensating controls
- Table: what changes between IT and ICS patching
- Standards and frameworks that expect a patch program
- Choosing patch management tools
- A 90-day plan to get started
- Our perspective: patching is a governance problem first
- Build a patch program your auditors and operators both accept
- FAQ
- Sources
Why control systems cannot be patched like office PCs
A workstation that reboots at 2 a.m. costs someone a few minutes. A controller that restarts unexpectedly can interrupt a process, trip a safety system or shut down a pipeline segment. That difference drives every decision below.
The SANS Institute notes that patching in ICS and OT environments does not normally follow traditional IT patching processes, schedules or methodologies, and that common advisories and vulnerability scores give only part of the picture. Practitioners have moved away from "patch everything" cycles toward a risk-based model tied to engineering maintenance windows.
There are also practical constraints. Control Engineering lists proprietary hardware and software, thin staffing, inadequate or missing test equipment and regulatory reporting among the challenges of OT patching. Many sites have no spare controller on which to test a vendor update.
ICS, SCADA and OT: the terms in plain words
Readers often ask how these terms relate. NIST SP 800-82 Rev. 3 uses operational technology (OT) as the broad category: programmable systems and devices that interact with the physical environment. ICS sits inside OT. It covers controllers such as PLCs, RTUs and distributed control systems, plus the HMIs operators use. SCADA is the subset of ICS that monitors and controls assets spread over large distances, such as pipelines and electrical grids.
The distinction matters for patching. A SCADA network spanning hundreds of miles of pipeline has different reliability and latency constraints from a controller cabinet in one plant, and your patch approach should reflect that.
The six-step ICS patch management cycle
Control Engineering describes a six-step cycle for OT patching. Here is how each step works in practice, with the part that differs from IT highlighted.
1. Build and maintain an asset inventory
You cannot patch what you cannot see. CISA's practice recommends a current hardware inventory of all control equipment, cross-referenced to a software code library holding the most recent stable, deployed versions and configuration files for switches, routers, servers and similar devices. Record the vendor, model, firmware, operating system, network location and, critically, supportability status: is the vendor still issuing patches for this version?
2. Identify vulnerabilities
Monitor vendor advisories, CISA ICS advisories and your own scanning results. Be careful with active scanning. Tools designed for IT can crash fragile controllers, so use passive monitoring or vendor-approved methods on production networks.
3. Filter for relevance
Most advisories will not apply to you. Match each one against the inventory: do you run the affected product and version, and is the vulnerable service enabled? CISA recommends a patch review team to determine whether the ICS is actually vulnerable to the identified attacks.
4. Review and approve
This is where OT diverges most from IT. Approval should come from a cross-functional board, often called a Configuration Control Board, with IT, security, process engineers and operations leadership. CISA's guidance places the recommendation to patch or not patch with senior management, informed by that team. No patch should be approved on security grounds alone, because safety, production and business risk are all in play.
5. Test and deploy
Test on a representative system where you have one: a spare, a lab or a vendor-supported simulator. Before deploying, confirm a validated last-known-good backup and a written rollback plan. NIST's OT Backup Quick Start Guide explains why OT backups are central to response and recovery after a cyber incident. Then deploy in a scheduled maintenance window with operations staff present.
6. Baseline and document
Document the system's state before and after every patch. Control Engineering calls baselining the most tedious but essential requirement. Any drift from the approved configuration should flow into your formal change management so you stay audit-ready. Organizations that skip this step often discover the gap only when an auditor asks for evidence.
Prioritize by reachability, not by score alone
A critical CVSS rating describes a flaw in the abstract. Your risk depends on whether an attacker can reach it.
Consider a vulnerable service on a controller that sits behind a properly configured ICS DMZ, with no route from the corporate network or internet. The CISA practice describes how strong business constraints and an already-mitigated attack surface can change the answer to "patch now?" For that asset, an emergency IT-style response may be unwarranted, and rushing it can cause the very outage you were trying to prevent.
A simple triage you can apply to each relevant advisory:
- Exposure: Can the vulnerable component be reached from outside its zone? Through remote access, vendor connections or a flat network?
- Exploitability: Is exploitation known in the wild, and does it require authentication or physical access?
- Consequence: If the asset failed or were manipulated, what are the safety, environmental and production effects?
- Mitigation available: Can segmentation, port hardening or monitoring close the gap until the next window?
The answers sort each item into one of three queues: patch in the next window, mitigate and schedule, or accept and monitor with documented sign-off.
Work inside maintenance windows
SANS and the TXOne research it cites point to the same operating principle: updates should align with planned engineering maintenance windows, because the cost of an unexpected ICS outage can far exceed the risk of a temporarily unpatched system protected by compensating controls. TXOne's OT patch management playbook frames the same tension: OT prioritizes continuous operations, so patching is complex and often delayed.
Practical habits that make windows productive:
- Pre-stage everything. Download, verify and test patches before the window opens, not during it.
- Batch by outage. If a turnaround or planned shutdown is coming, bundle approved patches for the affected units into it.
- Plan for site resilience. Remote and unattended sites often depend on backup power, so confirm that generator and fuel readiness do not collide with your window. Fuel supply planning for backup generation is a useful reference for operators who run engines on site.
- Define stop criteria. Agree beforehand when the team rolls back, and who decides.
When you cannot patch: compensating controls
Some patches will never be applied. The vendor may have ended support, the fix may require an unavailable shutdown, or the update may break certified functionality.
NIST SP 800-82 and the CISA practice both point toward the same alternative: apply network-level and host-level controls that reduce the chance of exploitation. Common options include:
- Micro-segmentation to isolate the vulnerable asset into its own zone with narrow, explicit allowed flows.
- Port and service hardening, disabling unused services and protocols.
- Virtual patching, where an inline control blocks known exploit traffic before it reaches the device.
- Real-time monitoring of the asset's traffic for anomalies.
- Tighter remote access, including multifactor authentication and session recording for vendors.
Forcing an update onto an unsupported system is a common pitfall and can leave the asset unusable. Instead, keep the supportability record current so you know which devices belong in this category before an advisory lands. Document each exception with the compensating controls, the owner, the review date and the sign-off.
Table: what changes between IT and ICS patching
| Factor | Typical IT patching | ICS/OT patching |
|---|---|---|
| Priority | Confidentiality and speed | Safety, availability and process continuity |
| Scanning | Active, frequent | Passive or vendor-approved, carefully scheduled |
| Timing | Monthly cycles, automatic reboots | Planned engineering maintenance windows |
| Approval | IT change board | Cross-functional board including process engineering and operations |
| Testing | Staging group of PCs | Representative system, spare hardware or vendor lab |
| Rollback | Uninstall or restore image | Validated last-known-good backup and written rollback plan |
| If unpatched | Often urgent | Compensating controls with documented acceptance |
Standards and frameworks that expect a patch program
Several frameworks give you a structure to build against:
- ISA/IEC TR 62443-2-3 provides guidance for building a patch management program in an industrial automation and control system environment, as summarized by the Automation Engineering Body of Knowledge.
- NIST SP 800-82 is the main US guide to OT security. Revision 3 covers securing OT while addressing its performance, reliability and safety requirements, and a Revision 4 draft is now in public circulation, so check which version your auditors reference.
- CISA's recommended practice for patch management of control systems remains a practical reference for process design, though it was first published in 2008, so pair it with current guidance.
If you are also subject to sector rules, for example for electric utilities or pipelines, map your patch records to those requirements early. Ask your regulator or auditor which evidence format they expect instead of assuming.
Choosing patch management tools
No single tool suits every ICS environment, and CISA's guidance is that no single solution covers both IT and OT patching. Proprietary hardware from many vendors means you will likely combine approaches:
- OEM-specific tooling for direct patching of controllers and engineering workstations from major automation vendors.
- Passive asset discovery and monitoring for inventory and vulnerability matching without touching live devices.
- General endpoint management for Windows-based HMIs and servers, only where the vendor supports it.
When evaluating any platform, ask three questions. Does it support your specific OEM assets natively or agentlessly? Does it avoid active probing of fragile devices? Can it produce the before-and-after records your audit requires? A tool that cannot answer yes to the last one leaves your team with manual work at audit time.
A 90-day plan to get started
- Days 1 to 30: Build the inventory and supportability register. Name the members of your Configuration Control Board and agree on its decision rights.
- Days 31 to 60: Document your patch workflow: sources, relevance filter, triage criteria, test method, rollback standards and baselining templates. Identify the next three maintenance windows.
- Days 61 to 90: Run one full cycle on a low-risk system. Review what slowed you down, then expand to higher-consequence zones and put compensating controls on every asset you cannot patch.
Our perspective: patching is a governance problem first
We see the same pattern in regulated operators. The technical steps are well documented. What breaks is ownership: security finds the vulnerability, operations owns the process, and nobody has authority to decide between them. A patch policy that lives only in the IT department gets ignored at the plant, and a plant that patches informally cannot show an auditor what changed.
Our view is that the fastest improvement comes from three things. First, a named decision body that includes operations and process engineering. Second, a risk-based policy that states in advance which conditions justify an emergency patch and which justify a compensating control. Third, evidence that is produced as work happens, not reconstructed afterward.
For mid-sized oil and gas, energy and other compliance-sensitive organizations, a full-time CISO to build this is often out of reach. That is the gap a virtual CISO fills: someone who writes the policy, convenes the board, and ties your patch records to the frameworks you are measured against.
— vCISO
Build a patch program your auditors and operators both accept
CISOSafe is a Houston-based virtual CISO firm serving regulated industries, including oil and gas, energy and law firms. Our vCISO, risk assessment, policy and controls development, and audit readiness services help you define patch governance, document compensating controls and prepare evidence for SOC 2, HIPAA, PCI DSS, CMMC and similar frameworks. Our platform also supports compliance assessments across 50+ frameworks. To talk through your environment, start at cisosafe.com.
FAQ
What is the process for ICS patch management?
It is a cycle of inventory, vulnerability identification, relevance filtering, review and approval, testing and deployment, and before-and-after baselining. Every step involves process engineering and operations, not just IT. The cycle repeats as new advisories arrive.
How often should ICS patching be performed?
There is no universal interval. Mature programs review advisories continuously and deploy approved patches during planned engineering maintenance windows, which may be quarterly, annual or tied to turnarounds. Your schedule should follow risk and operational calendars, and any regulatory deadlines that apply to your sector.
Should we patch every critical vulnerability immediately?
No. A high CVSS score does not mean the flaw is reachable in your architecture. Assess exposure, exploitability and consequence, then patch in the next window, mitigate with compensating controls or document acceptance. Rushed patches can cause the outage you are trying to prevent.
What do we do about devices the vendor no longer supports?
Isolate them. Use micro-segmentation, port hardening, virtual patching and monitoring, and record the supportability status and exception sign-off. Do not force an unsupported update onto the device, as that can render it unusable.
Sources
- Recommended Practice for Patch Management of Control Systems, CISA
- Risk-Based Vulnerability Management and Patching Industrial Systems, SANS Institute
- OT Patch Management Playbook, TXOne Networks
- Six steps to effective patch management, Control Engineering
- OT Backup Quick Start Guide, NIST SP 1339
- IEC 62443-2-3 Patch Management in the IACS Environment, Automation Engineering Body of Knowledge
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- NIST SP 800-82 Rev. 4, initial public draft