Patching industrial control systems is hard, but no update regime is worse
How to bring operations engineers and security teams to a shared testing and maintenance scheme - without illusions and without paralysis.
Conversations about updates in industrial systems almost always reach the same deadlock. The security team says: "This vulnerability is critical, we need to patch it." The operations engineers say: "We are not applying a patch to a running line, that is a shutdown risk." Both are right. And both are standing still.
I have seen this situation in many variations. It does not resolve itself. It either resolves through deliberate joint work, or it gets frozen until the next incident.
Why industrial control systems are a special case
Industrial control systems were designed around different priorities than corporate IT. The primary goal is continuity and predictability. The case that ICS security can no longer be treated as someone else's problem was made compellingly by the Stuxnet episode - segmentation was the first hard lesson; patching is the next one. Stopping a production line for four hours to apply a software update is not an abstract risk - it is a concrete and measurable loss.
On top of that:
- ICS vendors often release updates infrequently and with delay;
- testing a patch on a live system is practically impossible without a separate test environment;
- vendor warranties may be voided by unauthorized changes;
- many systems run on operating systems that have already reached end of support.
None of this is a reason to do nothing. It is the context in which the work has to happen.
What happens when there is no update regime
The absence of an update regime is not a neutral position. It is accumulating debt:
- vulnerabilities in components go unaddressed for years;
- nobody knows exactly which software versions are actually installed;
- when an incident happens, it is unclear whether a known vulnerability was involved;
- a regulator or insurer asks uncomfortable questions about the system's condition.
The risk of a patch-induced outage is real. The risk of no patches is also real - it is just less visible and less urgent until something specific happens.
How to build a working regime
A practical approach that works is not built on "patch everything immediately" but on a managed process:
Inventory and prioritization. First, you need to know what is actually installed. Which versions, which components, which of them have known high-severity vulnerabilities. Without this, any discussion is abstract.
Test environment. For critical systems - a separate environment, as close to production as possible, where a patch can be verified before being applied. Yes, it costs money. It is still cheaper than an unplanned shutdown.
Maintenance windows. Updates are scheduled during planned shutdowns - which usually already exist. This means security needs to know the maintenance schedule, and operations needs to include software updates in the maintenance plan.
Compensating controls. For vulnerabilities that cannot be patched right now - isolation, monitoring, restricting network access. This is not a substitute for a patch, but it reduces the risk until the next maintenance window.
Where the line sits between security and operations
The main point of conflict is who makes the decision. Security says "must do", operations says "cannot do". This is not a debate about technical details - it is a debate about priorities, and it cannot be resolved technically.
The solution is a shared document with criteria: which vulnerabilities require immediate action regardless of circumstances, and which can wait for the next scheduled window. That document needs to be signed off by both sides and, ideally, by management.
Without it, the same pause will repeat every single time.
A few questions to assess the current state
- Do you know the exact software versions on every ICS node right now?
- Do you have a test environment for at least the critical components?
- Are software updates included in the planned maintenance schedule?
- Is there an agreed list of vulnerability classes that require immediate response?
- When was the last time the post-update recovery procedure was tested?
If more than two answers are "I don't know" or "no" - an update regime effectively does not exist. And the first step is not a patch. It is a conversation between security and operations with the goal of building that regime together.