In IT, patching is routine: find the vulnerability, apply the update, move on. In OT, that cycle collides with reality. Production cannot stop on demand, changes carry safety risk, vendor support constrains what can be altered, and some systems are simply too old to patch at all.
Effective OT patch management accepts these constraints rather than fighting them. It prioritizes by risk, leans on compensating controls when patching is not possible, and treats reduced reachability as a primary mitigation in its own right.
01Key takeaways
- 01
OT patching is constrained by uptime, safety, vendor support and the age of equipment.
- 02
A risk-based approach prioritizes the patches that matter most rather than chasing every update.
- 03
When patching is not feasible, compensating controls and virtual patching manage the risk by other means.
- 04
Reducing reachability is often the most powerful mitigation, because an unreachable flaw is much harder to exploit.
- 05
Patch delivery itself should be staged, validated and controlled rather than continuous and open.
02Why OT patching is uniquely hard
The obstacles to patching OT are structural, not a matter of will. They flow from what OT is for: running a physical process reliably and safely over a long lifetime.
- Downtime to apply patches can be costly or operationally unacceptable.
- Changes to a running process carry safety and stability risk.
- Vendor certification may tie a system to a specific, unchangeable configuration.
- Some equipment is end-of-life and receives no patches at all.
- Testing a patch without disrupting production can be difficult.
In OT, the question is rarely "why isn't this patched?" It is "how do we manage the risk until, or unless, it can be?"
03Risk-based prioritization
Because patching everything quickly is impossible, OT patch management has to be selective. The goal is to spend scarce maintenance windows on the vulnerabilities that genuinely matter in context.
A vulnerability's score in isolation is less important than its real exposure: whether the affected system is reachable, what an attacker could do, and what the consequence would be. A severe flaw on an unreachable device may matter less than a moderate one on an exposed, critical system.
- Assess reachability and exposure, not just severity scores.
- Weigh the consequence to safety, availability and the process.
- Prioritize internet-facing and boundary systems over deeply isolated ones.
- Align patching with planned maintenance windows to avoid extra downtime.
04Compensating controls and virtual patching
When a system cannot be patched, the risk does not disappear, but it can be managed by controls that reduce the chance of exploitation. This is where compensating controls and virtual patching come in.
- Compensating controls
- Other measures, such as segmentation, access restriction and monitoring, that reduce the risk of an unpatched flaw without modifying the system.
- Virtual patching
- Network-level protections that block exploitation of a known vulnerability, buying time until a real patch is possible or indefinitely where it is not.
These do not fix the underlying flaw, but they can make it impractical to exploit, which for OT is often the realistic goal.
05Reducing reachability as the primary mitigation
The most powerful compensating control is to reduce how reachable a vulnerable system is. An unpatched vulnerability on a system an attacker cannot reach is far less dangerous than the same flaw on an exposed one.
This reframes patch management around exposure. For systems that cannot be patched and do not need continuous connectivity, an AIRGAPNET controlled connectivity pattern can keep them disconnected by default and reachable only for approved windows, shrinking the time an unpatched flaw can be exploited to almost nothing.
Patching reduces the number of vulnerabilities; reducing reachability reduces the opportunity to exploit the ones that remain. In OT, the second lever is often the more dependable.
06Staged and validated patch delivery
When patches are applied, how they arrive matters. Pulling updates directly from an external source into production turns the patch process itself into a risk, as supply chain attacks have shown.
- Stage patches in an isolated environment and validate them before deployment.
- Verify integrity and authenticity so a tampered update is caught.
- Bring patches in through a controlled, time-bound path rather than a standing connection.
- Apply in maintenance windows with a tested rollback plan.
- Coordinate with vendors on supported, certified updates.
07Closing thought
OT patch management is not a weaker version of IT patching; it is a different discipline shaped by the reality that you often cannot patch on demand, and sometimes not at all. Pretending otherwise leads to frustration and unmanaged risk.
Prioritize by real exposure, lean on compensating controls, and above all reduce reachability so that the vulnerabilities you cannot patch are also the ones an attacker cannot reach. Manage the exposure, not just the patch level.
FAQFrequently asked questions
Why is patching OT systems so difficult?
OT patching is constrained by production uptime, the safety and stability risk of changing a running process, vendor certification that ties systems to specific configurations, and equipment that is too old to receive patches. Testing without disrupting production is also hard.
What is a risk-based approach to OT patch management?
It prioritizes patches by real exposure and consequence rather than severity scores alone, focusing scarce maintenance windows on reachable, critical and internet-facing systems, and aligning patching with planned downtime.
What is virtual patching in OT?
Virtual patching uses network-level protections to block exploitation of a known vulnerability without modifying the affected system. It buys time until a real patch is possible, or serves as an ongoing control where patching is not feasible.
How does reducing reachability help with unpatched systems?
An unpatched vulnerability on a system an attacker cannot reach is far less dangerous. Keeping systems that cannot be patched disconnected by default and reachable only for approved windows shrinks the opportunity to exploit the flaw to almost nothing.
How should OT patches be delivered safely?
Stage patches in isolation and validate their integrity and authenticity, bring them in through a controlled time-bound path rather than a standing connection, apply them in maintenance windows with a rollback plan, and coordinate with vendors on certified updates.
SRCSources of record
Manage the exposure, not just the patch level
Make the flaws you cannot patch the ones attackers cannot reach.
For systems that cannot be patched and do not need to be always connected, keep them disconnected by default and reachable only for approved windows.