Patching a system that cannot be taken down

Business IT patches on a monthly cycle. Control systems often cannot: the vendor has validated a specific version, the plant runs continuously, a restart requires a production decision, and an untested patch carries a real risk of breaking a system that is currently working.

The result on many sites is that patching does not happen at all, and the gap between the installed state and the current state grows for years.

The position is a decision, not an accident

Not patching is a legitimate risk management position where the compensating controls are adequate and the decision is explicit.

Proactive work practices reduce the number of issues that become urgent during operation or handover. Further details are available in this overview.

Security decisions should also be checked against NIST guidance on operational technology security.

What is not legitimate is not patching by default, without knowing what is unpatched, what the exposure is, or what compensating controls are actually in place. That is the common situation and the distinction matters when something happens.

Know what you are running

Patch management requires an inventory: every server, workstation, operating system version, control software version, firmware revision on field devices and network equipment.

Most sites cannot produce this. Building it is the prerequisite for everything else, because a vulnerability advisory cannot be assessed without knowing whether the affected version is installed.

Vendor validation

Control system vendors test operating system patches against their products and publish which are approved. That validation lags the patch release, typically by weeks.

Applying an unvalidated patch risks the vendor declining to support the resulting configuration, which is a genuine constraint rather than an excuse. The practical approach is to follow the vendor's approved list, and to press the vendor on their validation timeliness where it is poor.

Risk-based prioritisation

Not every patch matters equally. A vulnerability that requires local administrative access on a machine inside a segmented control network is a different proposition from one that is remotely exploitable across the network boundary.

The assessment that matters is exposure in your architecture, not the published severity score. A high-severity vulnerability in a service that is disabled and unreachable may be a lower priority than a moderate one in an exposed component.

Testing before deployment

Patches should be applied to a test environment before production, and the absence of a test environment is the most common reason sites do not patch.

A modest offline system — even a single workstation and controller — pays for itself here, and is also useful for configuration testing, training and recovery testing. Where the capital case is difficult, virtualised test environments are often achievable at low cost.

Windows and scheduling

Patching requires a maintenance window, which requires production agreement. That is a scheduling problem rather than a technical one and it responds to being planned.

Aligning control system patching with existing planned outages — turnarounds, unit shutdowns, scheduled maintenance — removes the need for a dedicated window. It also means the interval between patching cycles is set by the outage schedule, which should be an explicit input to the risk assessment.

Compensating controls where patching is impossible

Some systems genuinely cannot be patched: an operating system past end of life on hardware that cannot run a newer one, running software that has no upgrade path.

The position is managed by reducing exposure: tighter segmentation around the affected system, removal of unnecessary services and connections, strict control of removable media, enhanced monitoring at its boundary, and application allowlisting where the platform supports it.

These are compensations rather than fixes, and the underlying obsolescence remains an issue with a timeline. Recording that explicitly, with a date by which the system must be replaced, is what stops the compensating controls becoming a permanent answer.

Documenting the decisions

Every patch cycle produces decisions: applied, deferred with a reason, or not applicable. Recording them takes little effort and produces the record that demonstrates the position was managed.

The value of that record is most apparent after an incident, when the question is whether the exposure was known and considered.

Firmware and field devices

Patch discussions concentrate on servers and workstations. Field devices, network equipment, drives and intelligent instruments also carry firmware with its own vulnerabilities and its own update process.

These are harder: updating firmware on a device in service may require taking the associated equipment offline, and the update process itself carries a risk of leaving the device unusable.

The realistic approach is an inventory, a risk assessment concentrated on network-connected devices, and updates aligned with planned outages when the equipment is already unavailable.

Monitoring advisories

Knowing that a patch matters requires knowing that a vulnerability exists. Vendor security bulletins, national coordination centre advisories and sector information sharing arrangements all publish them.

Someone has to receive and assess them. Where nobody is assigned, advisories arrive at a generic address and are read by nobody, and the first indication of a problem is an incident.

The unpatchable system with a date

Where a system cannot be patched, the compensating controls buy time rather than resolving the position. Recording an explicit end date — the year by which the system must be replaced or isolated further — converts an indefinite acceptance into a plan.

Without a date, compensating controls become the permanent answer and the underlying exposure persists for the remaining life of the plant.

Patching and the change process

A patch is a change to the system and belongs in the change record, with the same testing, approval and documentation as any other modification.

Treating patching as routine maintenance outside the change process produces a system whose software state is not reflected in its configuration record, which undermines every later assessment of what is installed.

It also means the patch cannot be reliably backed out, because there is no record of what state the system was in beforehand.

Antivirus and endpoint software

Endpoint protection on control system workstations carries its own considerations: signature updates need a distribution path that does not require internet access from the control network, and scanning can affect real-time performance.

Vendor guidance normally specifies which products are validated, which directories should be excluded from scanning, and how updates should be distributed.

Deploying corporate standard endpoint software onto control systems without reference to that guidance is a recurring cause of performance problems that are then attributed to the control system.