Patch Tuesday doesn’t exist on the plant floor

In the office, patching has a rhythm. Updates arrive on a schedule, machines restart overnight, and a good IT team is measured by how few days pass between a fix being published and a fix being installed. The plant floor does not work that way, and the reasons are good ones.

Why the plant floor patches differently

Three reasons recur. The first is that a controller change can stop a process. PLC firmware is tested by the vendor against a particular HMI, a particular engineering tool and a particular set of function blocks, and a version step can change timing, drop a connection or leave a program that no longer loads. The vendor validates its own fix before releasing it, and the plant validates again before applying it, on a test rig if it has one and on the line itself if it does not.

The second is that a medical device is certified as supplied. The computer inside a scanner, an analyser or an infusion pump is part of the regulated device, and the manufacturer, not the hospital, decides which operating system and which updates it runs. A hospital that installs an unapproved patch on a modality can lose its certification and its service contract at once.

The third is that a validated system needs change control. In a pharmaceutical plant, or on any site that runs under GMP or a similar regime, a change to a qualified system means a documented request, testing, approval and a record, all before the next batch. That is right for the product, and it means a patch is a project.

So patching happens in maintenance windows: planned shutdowns when the line is down anyway, a few times a year at most, and only for the patches the vendor has validated. The gap between a fix existing and a fix being applied is measured in months, sometimes years. The question is not how to close that gap. It is what protects the equipment across it.

On the plant floor the question is not how fast you patch. It is what stands in for the patch in the years between.

Compensating controls

A compensating control is protection put around a system that cannot be changed, rather than inside it. ISA/IEC 62443-3-3 uses the term compensating countermeasure for the same idea: when a component cannot meet a requirement on its own, something else in its zone meets it on its behalf. NIST SP 800-82 Rev. 3 takes the same line in its treatment of patch management, that where a patch cannot be applied, other mitigations have to carry the risk in the meantime.

Five kinds do most of the work. Segmentation puts the unpatched system in a zone of its own, with a conduit that permits only the traffic it needs, so a problem elsewhere on the network cannot reach it. Allow-listing at the boundary means the firewall between that zone and the rest of the plant passes a named list of sources, destinations and protocols and drops everything else, which turns an exposed service on an old controller into one that only its HMI can reach. Brokered remote access means the vendor who services the device connects through a jump host the plant controls, opened on request, time-boxed and logged, instead of a VPN box with a standing tunnel. Monitoring means a passive capture at the zone boundary, so the plant can see what talks to the device and notice when something new does. Physical controls are the locked cabinet, the disabled USB port, the engineering port that needs a key, and the rule that a service laptop is checked before it is plugged in.

None of these touches the controller or the scanner. That is their point. They fit around the certification, the validation and the vendor’s warranty, because they change the network and not the device.

ISA/IEC 62443-3-3 · system security requirements and compensating countermeasures

The computer inside the scanner

Healthcare is the sharpest version of this. A private hospital runs two plants: the building plant, meaning chillers, air handling, medical gas and generators, and the clinical plant, meaning imaging, laboratory analysers, monitoring and infusion. Both carry the same patching constraint. The scanner’s console runs whatever operating system it shipped with until the manufacturer says otherwise, and the air handling unit’s controller runs the firmware it was commissioned with.

The usual pattern is that these share a network with the hospital’s office systems, because the hospital grew faster than its network was redesigned. On a flat network the oldest device sets the level of risk for all of them, and a workstation that reads email is one hop from a modality that cannot be patched. The answer is not to patch the modality, which the hospital cannot do. It is to put the imaging network in a zone of its own, with DICOM and HL7 allowed across the boundary and nothing else. The device stays as the manufacturer supplied it, and the hospital’s own systems stop being its neighbours.

Active scanning is a particular risk here. A scanner that stalls during a port scan is a patient waiting, and an infusion pump that drops off the network is worse. Listening shows what the devices talk to, which vendors reach them and which paths cross into the office, without sending a packet to any of them. That is why the method is passive first, and on a clinical network it is passive full stop unless the hospital asks for more in writing.

The BMS that keeps a theatre at pressure

Buildings carry the same constraint in a quieter form. A building management system controls the air handling that keeps an operating theatre at positive pressure, the chiller plant that keeps a Gulf building habitable, the lifts, the access control and the smoke control. Its controllers run for years without a restart, and the protocols they speak, BACnet, Modbus and KNX, have no authentication of their own, so being on the network is being in control.

A BMS controller is rarely patched, because a firmware update means taking a plant room offline and the building cannot spare it, and because the contractor who installed it is often the only one who knows how. The compensating controls are the same ones: a BMS zone separated from the tenants and the office, the contractor’s monitoring gateway brokered rather than standing, a locked plant room, and a capture at the head end so the facilities team knows which systems share a network and which gateways reach outside. We describe this in more detail on the buildings and facilities page.

Hospital and building meet in the theatre. The BMS that holds the pressure sits on the same cable as the clinical floor more often than anyone would design it, and neither side of that cable will be patched this month.

What this means for the plan

A plant’s patch programme should have two columns. One lists what can be patched, when the next maintenance window falls, and which vendor validations are pending. The other lists what cannot be patched, for how long, and which compensating controls stand in for the patch. On most sites the second column is the longer one, and it is the one a plant manager should be able to show.

Sample

NIST SP 800-82 Rev. 3 · patch management for operational technology

Range’s part is the first step: the list of what is on the network, what each system talks to, which paths reach it from outside, and which of those a patch would never have closed anyway. It comes from listening rather than touching, which is why it can be done on a validated system without a change request and on a scanner without a service call. After that the plan is the plant’s own, and the compensating controls are what stand between a device that cannot change and a network that does.

Sources · NIST SP 800-82 Rev. 3 (patch management in OT); IEC TR 62443-2-3 (patch management in the IACS environment); ISA/IEC 62443-3-3 (compensating countermeasures).