Vulnerability Management in OT: Why Traditional Patching Does Not Work

Patching in OT: The Operational Reality

In IT security, patch management is an established process: patches are released, tested in a staging environment, and deployed within timelines set by company policy. It is a cycle that repeats every month, every week for critical patches, and in some organizations almost continuously.

In OT, this model does not work. Not because of laziness or lack of awareness — because of the nature of industrial environments.

A production manager knows that updating a PLC's firmware requires stopping the line. Stopping the line has a measurable hourly cost. If the next maintenance window is three months away, the patch waits three months. If that system runs continuous 24/7 production, the maintenance window might be biannual or annual.

This is not a problem solvable with more awareness campaigns or stricter policies. It is a structural constraint of industrial environments that any effective VM program must accept and manage, not ignore.

Why IT Patching Cycles Do Not Transfer to OT

The reasons standard patching does not apply to OT are varied and often cumulative:

Operating system incompatibility: many SCADA and HMI systems run on Windows XP, Windows Server 2003, or even older OS versions. Microsoft no longer releases patches for these systems. Even if there were a will to patch, there is nothing to apply.

Validation and certification: in sectors such as pharma, nuclear, and aerospace, OT systems are validated and/or certified. Any modification — including installing a patch — can invalidate the certification and require a full re-validation that is expensive and time-consuming. The security benefit of the patch must be weighed against the cost and risk of re-validation.

Vendor-only updates: many industrial automation systems can only be updated with direct vendor support. The vendor must qualify the patch for the specific software version, the customer must coordinate an intervention, and certified personnel must perform the update. The process takes weeks.

Regression testing requirements: an update that works without problems in IT can have unexpected behaviors in control systems where millisecond latency is critical. Regression testing in OT production environments requires dedicated time and resources.

Systems out of vendor support: it is not uncommon to find OT systems with software components for which the vendor no longer exists, was acquired, or simply discontinued support. No patches are available because nobody produces them.

Prioritizing Vulnerabilities: CVSS Is Not Enough — OT Context Is Required

The standard tool for vulnerability prioritization in IT is CVSS (Common Vulnerability Scoring System): a score from 0 to 10 indicating the theoretical severity of a vulnerability. A vulnerability with CVSS 9.8 gets patched before one with CVSS 5.

In OT, CVSS alone is insufficient. Consider this: a CVSS 9.8 vulnerability on a SCADA system completely isolated from the network, accessible only physically, in a plant with 24/7 security, carries far lower real risk than a CVSS 6.0 vulnerability on an HMI with an active remote access connection.

Real risk in OT is the combination of:

• Theoretical vulnerability severity (CVSS)
• Actual system exposure (is it reachable from the network? Does it have remote access? Is it exposed to the internet?)
• Operational importance of the system (what does it control? What is the impact of downtime?)
• Existence of compensating controls (is it in an isolated zone? Is it monitored?)
• Real exploitability in the specific environment (are there public exploits? Would an attacker need to already be on the OT network?)

This OT-specific context must be added to any prioritization framework. Tools such as CVSS-OT or ICS-specific risk scoring methodologies (such as those from CISA and ICS-CERT) incorporate these dimensions.

Compensating Controls: Defense in Depth as an Alternative

When patching is not applicable, the VM program must respond with compensating controls — measures that reduce the risk of the vulnerability without eliminating it.

The most effective compensating controls for unpatchable OT vulnerabilities:

Network isolation: move the vulnerable system to a separate network zone, with access limited to only those systems with an operational need to communicate with it. If the vulnerability requires network access to be exploited, restricting network access reduces risk.

Traffic whitelisting: instead of allowing all traffic toward a vulnerable system and blocking only malicious traffic, invert the logic — block everything and allow only the specific necessary traffic. Function code whitelisting for industrial protocols.

Specific monitoring: configure detection rules specific to the known attack patterns associated with the vulnerability. If a public exploit exists, its traffic signatures are known and detectable.

Virtual patching: some industrial intrusion prevention systems (IPS) can block traffic attempting to exploit specific vulnerabilities, even without the vulnerable system being updated. It is a "virtual patch" that acts on the network rather than on the system.

Exposure limitation: remove or disable unnecessary access vectors to the vulnerable system — unused network ports, unnecessary services, inactive accounts.

A Sustainable VM Program for Industrial Environments

An effective OT vulnerability management program has different characteristics from its IT counterpart:

Continuous inventory as foundation: you cannot manage what you do not know. OT VM always begins with a complete, updated asset inventory including software and firmware versions.

Contextualized scoring: every vulnerability must be scored in the context of the specific environment, not with the universal CVSS.

Three action categories: for each identified vulnerability, one of three: apply patch (with a realistic timeline), implement compensating control (documented and planned), accept residual risk (with formal approval and periodic review).

Integration with the maintenance cycle: OT VM must coordinate with scheduled maintenance windows. Vulnerabilities identified as priority are planned for available windows, not passively awaited.

Periodic review of accepted risk: vulnerabilities for which residual risk was accepted must be periodically reassessed. Context changes — new public exploits, new network connections, changed exposure can alter the risk profile of a vulnerability previously considered low-impact.

VM in OT is not the pursuit of perfection — a 100% patched OT environment does not exist. It is the systematic management of residual risk in an environment where technical perfection is structurally unachievable.

The MON5 Angle

Prioritizing vulnerabilities with CVSS alone, as discussed, does not work in industrial environments. MON5's ANALYZE phase addresses the problem by combining three dimensions: continuous asset inventory with software and firmware versions, CVE correlation with EPSS score, and above all the real exposure of each system in the plant network.

The result is a manageable priority list, aligned with available maintenance windows instead of an unreachable patching ideal. The path is modular and begins with a snapshot of the current state: request an OT assessment to build the foundation of your vulnerability management program.