Patch Management in OT: When You Cannot Simply Update

The Dilemma: Patch or Leave It Running?

Every second Tuesday of the month, Microsoft releases its security updates. In the IT world, they are installed on most systems within days, often automatically. In the OT world, however, the same patch can wait months, sometimes years. And sometimes it is never installed.

This is not a sign of negligence. It is the consequence of fundamental differences between IT and OT environments that affect every patching process.

A Windows patch on a SCADA server can destabilize the SCADA software if the vendor has not explicitly approved the patch. A firmware update on a PLC (SPS) can make the control program incompatible and stop the entire production line. A reboot, which is a given in IT, can mean a production shutdown of several hours in OT because the plant must be restarted and recalibrated after the reboot.

The result: Many mid-market companies do not patch their OT systems at all. They know this is a risk, but they see no practical alternative. This article shows that there is one.

Why Classic IT Patch Management Fails in OT

Before you build an OT patch process, you must understand why the IT approach does not work:

Vendor Approvals

In IT, you install a Microsoft patch directly from Microsoft. In OT, there is an intermediate layer: The machine manufacturer or SCADA vendor must approve the patch for their software environment. This approval can take weeks or months because the vendor must first test the patch with their software.

Example: Microsoft releases a critical security update for Windows Server. The SCADA vendor tests the update with their software and approves it four weeks later. During those four weeks, your SCADA server is vulnerable, and there is nothing you can do except deploy compensating controls.

No Staging Environment

In IT, you test patches in a staging environment before rolling them out to production. In OT, this staging environment usually does not exist. A complete replica of a production facility with all controllers, sensors, and actuators is prohibitively expensive. You must therefore install the patch directly on the production system, and the risk of a problem is correspondingly higher.

Reboot Sensitivity

Many patches require a reboot. In IT, this is a brief process. In OT, rebooting the SCADA server can mean operators lose their overview of the production process for 15 to 30 minutes. Rebooting a PLC can trigger a complete restart process that can take hours.

Legacy Systems

Some OT systems run on operating systems for which no patches are available. A comparison with patch management in IT makes the difference clear. Windows XP, Windows 7, Windows Server 2008: All of these are still actively in use in the OT world because the control software running on them does not work on newer operating systems. For these systems, classic patching is simply impossible.

Protocols Without Security Features

Industrial protocols like Modbus or Profinet offer no authentication or encryption. There are no "patches" for these protocols because security was not part of the protocol design. Vulnerabilities at the protocol level can only be addressed through compensating controls.

The Risk-Based Approach

Instead of installing all patches as quickly as possible (as is common in IT), in OT you evaluate each patch individually. The goal: Install the right patches at the right time and implement effective alternative measures for everything else.

Step 1: Assess the Vulnerability

When a new patch or vulnerability is published, you assess it based on the following criteria:

CVSS Score: The Common Vulnerability Scoring System score provides a standardized severity rating. From CVSS 7.0 (High) onward, you should take action. From CVSS 9.0 (Critical), the risk is high enough that you should consider short-term measures.

Exploitability: Are publicly available exploits already out there? Is the vulnerability being actively exploited? A theoretical vulnerability without a known exploit has lower priority than one for which Metasploit modules exist.

Exposure: Is the affected system reachable from the internet? From the office network? Or only from the segmented OT network? The more isolated the system, the lower the effective risk.

Relevance: Does the vulnerability affect a function that is actually active on your system? A patch for a service that you do not use and that is disabled has no priority.

Step 2: Assess the Patch Impact

In parallel with the vulnerability, you assess the impact of the patch:

Reboot required? If yes, you need a maintenance window. If no, the patch may be installable during live operations (but even then, only after vendor approval).

Vendor approval available? Without approval from the SCADA or PLC vendor, you should not install the patch. Check the vendor's website or contact their support.

Production criticality of the system: A patch on a non-critical monitoring system is less risky than a patch on the central SCADA server that controls the entire production.

Step 3: Make the Decision

Based on the assessment, there are four possible decisions:

Patch immediately (next maintenance window): High vulnerability criticality, high exposure, vendor approval available. Example: Critical remote code execution on the SCADA server that is reachable from the office network. The vendor has approved the patch.

Patch as planned (next regular patch cycle): Medium criticality or low exposure. Example: Medium vulnerability on an HMI panel that is only reachable from the OT network. Can be patched during the next planned shutdown.

Compensating controls instead of patching: The patch is not available (legacy operating system), not approved (vendor has not yet tested), or the risk of patching is higher than the risk of the vulnerability. Alternative protective measures are implemented instead.

Accept the risk: The vulnerability is non-critical, the system is well-isolated, and exposure is minimal. The risk is documented and accepted. This decision must be made consciously and documented as part of the risk assessment in the ISMS — not simply forgotten.

Step 4: Document

Every decision is documented. For each patch or vulnerability:

• Which system is affected?
• How was the vulnerability assessed?
• What decision was made?
• Who made the decision?
• When will the patch be installed (if planned)?
• What compensating controls were implemented (if patch is not possible)?
• When will the decision be reviewed?

This documentation is important not only for the ISMS but also for audits. In ISMS Lite, firmware versions, open vulnerabilities, and the associated compensating controls can be captured and tracked per OT asset. An auditor will not demand that every OT system is always up to date. But they will demand that you have a traceable process and can justify every decision.

Compensating Controls: When Patching Is Not Possible

Compensating controls are alternative security measures that reduce the risk of an unpatched vulnerability to an acceptable level. In the OT world, they are not the exception but the rule.

Network Segmentation

The most effective compensating control is network segmentation: If a system cannot be patched, isolate it as much as possible. A SCADA server with Windows 7 that sits in a segmented OT network and is only reachable via a jump server has a significantly lower risk than the same server in the office network.

Specific measures: Tighten firewall rules, allow only the minimally necessary connections, block direct access from the office network, place the server in its own VLAN with dedicated firewall rules.

Application Whitelisting

If you cannot install patches, ensure that only authorized software runs on the system. AppLocker (Windows) or comparable tools only allow execution of programs that are on a whitelist. Even if an attacker exploits a vulnerability, they cannot execute their own code because the whitelist prevents it.

Increased Monitoring

Set up targeted monitoring for unpatched systems. Monitor network traffic to and from these systems with particular attention. Configure alerts for unusual communication patterns: new connections, unknown protocols, access outside normal working hours.

Access Restriction

Restrict access to unpatched systems to the absolute minimum. Remove all user accounts that are not needed. Disable all network services that are not needed. If a system has a vulnerable component that is not used, disable it.

Physical Isolation

For extremely critical or extremely vulnerable systems: Disconnect them physically from the network. A PLC running firmware from 2010 that controls safety-relevant functions may have no business being on the network. It can be programmed via a direct serial connection to the engineering workstation without requiring network access.

Using Maintenance Windows Effectively

Planned production shutdowns (company holidays, weekend maintenance, shift changes) are the opportunity to install patches. For this to run smoothly, you need a clear process:

Preparation (2-4 weeks in advance)

• Review the patch backlog: Which patches are pending?
• Obtain vendor approvals
• Determine the sequence: Which system is patched first?
• Create a rollback plan: What happens if the patch causes a problem? How do you restore the previous state?
• Create and verify backups of all affected systems
• Plan personnel: Who patches, who monitors, who is responsible for rollback?
• Create a schedule: When does it start, when must it be finished?

Execution

• Verify the backup immediately before patching
• Install the patch
• Perform functional testing: Is the SCADA software still running correctly? Does the server communicate with the PLCs? Are all alarms active?
• Release the system or perform rollback

Follow-up

• Update documentation: Firmware version, patch date, person who performed the work
• Increase monitoring in the days following the patching
• Report and evaluate any anomalies

The Regulatory Framework for OT Patch Management

NIS2

NIS2 requires in Article 21 a risk management that explicitly includes "vulnerability handling and vulnerability disclosure." This means: You must have a demonstrable process for identifying, assessing, and treating vulnerabilities in your systems. Whether you install a patch or deploy compensating controls is secondary. What matters is that you make a conscious, documented decision.

EU Machinery Regulation 2023/1230

The Machinery Regulation requires from 2027 that machines with digital elements must be secure throughout their entire lifecycle. For machine manufacturers, this means: They must provide security updates. For machine operators, it means: They must apply these updates or justify why they do not.

The regulation thus complements the Cyber Resilience Act, which also requires security updates throughout the entire product lifecycle. For SMEs, this creates a clear expectation: OT systems must be maintained, and "we don't patch because that's how it has always been" is no longer an acceptable position.

IEC 62443

The IEC 62443 standard provides detailed requirements for patch management in OT environments. In particular, IEC 62443-2-3 (Patch Management in the IACS Environment) describes a structured process that can serve as guidance.

A Realistic OT Patch Process

Here is a process that is practical for mid-market companies:

Monthly: Vulnerability review. Check the publications of relevant vendors (Siemens ProductCERT, Rockwell Security Advisories, Schneider Electric Security Notifications, etc.) and the ICS-CERT advisories. Assess each relevant vulnerability according to the scheme described above.

Quarterly: Patch cycle. Install the approved and assessed patches during the next planned maintenance window. Update the compensating controls for non-patchable systems.

Annually: Strategic review. Which systems are at end of life? Where are legacy operating systems running that can no longer be patched? Is there an investment need for modernization?

Immediately (for critical vulnerabilities): When a critically rated vulnerability with active exploitation is published that affects your systems: Immediate assessment, immediate compensating controls (even if the patch can only be installed in the next maintenance window), and if necessary an unscheduled maintenance window.

Information Sources for OT Vulnerabilities

An OT patch process only works if you are informed about new vulnerabilities. In the IT world, there are established channels for this (Microsoft Patch Tuesday, CVE databases, vulnerability scanners). In the OT world, information sources are more dispersed, but they exist:

Vendor-Specific Advisories

The major OT manufacturers publish their own security advisories:

Subscribe to the advisories of all manufacturers whose products you have in use. Most offer email notifications or RSS feeds.

ICS-CERT and CISA

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) regularly publishes ICS Advisories for vulnerabilities in industrial control systems. These advisories are vendor-agnostic and often the fastest source for new OT vulnerabilities. In Europe, ENISA publishes supplementary information, and the BSI issues its own alerts for critical OT vulnerabilities.

CVE Databases and Vulnerability Scanners

Specialized OT vulnerability databases such as Dragos WorldView Threat Intelligence or the Claroty xDome Vulnerability Database provide detailed information about OT-specific vulnerabilities, including exploitability assessments and available patches or workarounds.

Passive OT monitoring (as described in an earlier section) can also automatically map known CVEs to the devices and firmware versions identified in your network. This does not completely replace manual review but significantly reduces the effort.

End-of-Life Systems: The Greatest Challenge

It becomes particularly difficult with systems that have reached end of life. When the manufacturer no longer provides security updates, there are exactly three options:

Option 1: Replacement. The system is replaced with a current one. This is the technically cleanest solution but often the most expensive. Replacing a machine controller can cost several hundred thousand euros and requires weeks or months of planning and commissioning.

Option 2: Virtual patching. Instead of patching the system itself, protection is shifted to the network level. A firewall or IPS in front of the system filters network traffic and blocks known attack patterns. This works well for network-based attacks but does not protect against local attacks (USB, physical access).

Option 3: Maximum isolation. The system is isolated from the network as much as possible. Only the absolutely necessary connections remain, and these are routed through a dedicated firewall with minimal rules. Additionally: Application whitelisting on the system, physical access controls, and increased monitoring.

For each end-of-life system, your ISMS should contain a documented decision on which option was chosen and why. This decision must be reviewed regularly (at least annually): Has the threat landscape changed? Are there new attack vectors? Has replacement become economically viable?

Common Mistakes to Avoid

All or nothing. The most common mistake: Because patching in OT is so complex, it is not done at all. An imperfect process is better than no process. Even if you only install the most critical patches on the most exposed systems, it is an enormous improvement over the status quo.

No documentation. You install patches but do not document what you did. During the next audit or the next incident, the information is missing. Document every patching activity and every decision not to install a patch.

Forgetting compensating controls. You decide not to install a patch but do not implement any compensating controls. The vulnerability remains open and unprotected. Every decision against a patch must be accompanied by at least one compensating control.

Neglecting vendor coordination. You install a patch without vendor approval, and the SCADA software crashes. Or you wait for an approval that never comes because you never asked. Establish a regular communication channel with your key OT vendors.

No rollback planning. You install a patch, and the system behaves differently than expected afterward. Without a rollback plan, you face the choice: Live with the problem or manually reverse the patch (with the risk of making the situation worse). A current backup and a documented rollback process are mandatory.

Further Reading

• OT Security in SMEs: Why Production Control Belongs in Your ISMS
• Securing SCADA and PLC Systems: Practical Measures Without Production Downtime
• Purdue Model Explained: Network Zones in Manufacturing
• Risk Assessment for OT Systems: Different Priorities Than in IT
• EU Machinery Regulation 2023/1230: Cybersecurity Requirements from 2027