In IT, "patch quickly" is often the starting point. In OT it is more nuanced: a patch that is rolled out in the office within a few days can take months to arrive in a substation — and that is not by definition careless.
Why patching is slower in OT
- Availability requirements. Many OT systems may only be restarted during planned maintenance windows, sometimes only a few times a year.
- Validation requirements. A patch can affect the interaction with other systems; vendors and asset owners often want to test this first in a representative environment before it is applied in production.
- Vendor certification. Some patches require explicit approval from the system vendor before they may be applied to a certified configuration.
- Physical access. Not every device can be updated remotely; sometimes a technician on site is needed.
What this means for prioritisation
Because patching cannot always happen immediately, prioritisation is essential. Relevant questions are: is the vulnerability included in the CISA KEV catalogue (evidence of actual exploitation)? Is the affected system reachable from the internet? Is an interim mitigation available, such as extra network segmentation or disabling a vulnerable function?
Practical approach
- Link patch status to the asset inventory. Know per system which version is running and which patches are available.
- Use mitigations as a bridge. When a patch cannot yet be applied, implement temporary measures such as extra segmentation, stricter firewall rules or increased monitoring.
- Test in a representative environment before a patch is rolled out in production, preferably with the involvement of the system vendor.
- Plan patch windows in advance instead of reacting ad hoc to every new vulnerability.
- Document deliberately postponed patches, including the reason and the compensating measures — this is valuable evidence towards supervisors and auditors.
Practical example
For a critical vulnerability in an RTU model without an immediately available patch, a grid operator decides to temporarily set up additional access restrictions on the conduit to the substation LAN and to tighten monitoring on that segment, pending a firmware update announced by the vendor.
Common mistake
Waiting with any action until a patch is available, without taking mitigating measures in the meantime. Between publication of a vulnerability and availability of a patch there can be weeks to months — a period in which the risk should not be left unmanaged.