The OT Patch Gap: Why Vulnerabilities Linger Long After a Fix Ships
On 13 August 2026, CISA published a single day’s batch of ICS advisories. In it: a hydropower control platform, a SCADA system, building-automation controllers, a PLC programming tool, and several engineering design packages. None of it was exotic. No elaborate memory-corruption chain, no zero-day drama. Mostly credential hygiene — passwords stored in a recoverable format, hard-coded credentials, missing authentication on a critical function — plus one deserialization flaw in a SCADA HMI.
And tucked inside one advisory was a detail that quietly captures the whole problem with OT vulnerability management: the version of the ANDRITZ HIPASE-250 control platform that fixes its four vulnerabilities shipped in December 2024. The advisory telling operators to apply it arrived in August 2026.
Twenty months between “fixed” and “known.” That is a clear-eyed measure of the structural problem OT operators actually live with — not a vendor failing, but a property of the environment itself.
What is the “patch gap” in OT?
In IT, a patch gap is usually measured in days. A vendor releases a fix; patch management rolls it out over a weekend; the window of exposure closes.
In OT, the gap is measured in months — sometimes years — and it runs in both directions.
The first direction is disclosure latency. The HIPASE-250 case shows how long a fix can sit in release notes before the ecosystem learns it exists. The fixing version shipped in December 2024; the public advisory landed in August 2026. A plant that installed V8.00.00 because it wanted new features was protected without ever knowing why. A plant that stayed on V7.x because its control system runs around the clock was exposed the entire time — and only now finds out.
The second direction is remediation latency, and it is the harsher one. Even once an advisory lands, patching a running OT device is not a Tuesday-afternoon task. A hydropower control platform regulates the operation of a generating unit — its turbine controllers, its excitation, its protection and synchronization. You do not patch it, reboot it, and hope the plant comes back. You plan the change against a maintenance window, coordinate with operations, revalidate the control loop, and accept that any misstep means lost generation or a transient. The same is true of a SCADA server, a substation relay, a building controller, a PLC on a production line.
Put the two directions together and you get a permanent structural gap: the device is running, the vulnerability is known, and the fix is days, weeks, or months away. Inside that gap, the device is defended by exactly one thing — whether anything is watching how it behaves.
Why are so many ICS advisories about credentials, not code?
The August 13 batch is worth reading closely, because the vulnerability types tell you where OT risk actually concentrates.
The ANDRITZ advisory lists three weakness classes across its four CVEs: passwords stored in a recoverable format, missing authentication for a critical function, and hard-coded credentials. Read that again. No buffer overflow. No use-after-free. The flaws that earned a CVSS base score of 8.1 on an energy-sector device were, in essence, that the device could not reliably tell who was talking to it.
The AVEVA Enterprise SCADA advisory is a deserialization flaw — but note the preconditions. It requires an authenticated operator holding a specific privilege level (“DNA Authority - Operator”). The attacker is not breaking in from cold; they are someone already holding legitimate access and using it for something it was not meant to do.
This is the shape of modern OT risk: flaws that sit at the boundary between “legitimate” and “malicious.” A hard-coded credential is not a payload; it is an invitation. Missing authentication is not a signature; it is an absence. And an authenticated operator misusing serialized data looks, to any log, like an authorised session.
What actually reduces risk inside the gap?
The conventional answer is “patch faster.” It is a good answer and a necessary one — but it has a ceiling. You cannot patch what you cannot take offline, and you cannot take offline what keeps the plant running. Some of these devices will carry today’s vulnerabilities into next year, and the year after, because the cost of remediation exceeds the risk appetite of the business on any given Tuesday.
So the question becomes: inside the gap, what is defending the device?
The answer that scales is behavioural detection — not a faster patch cycle, but a way to see what the unpatched device is doing while it waits.
A network-level detection system that learns what normal looks like for each device can flag the moment a gap starts to be exploited, regardless of whether the vulnerability has a CVE or a fix:
- A hard-coded credential being used: the device suddenly answers a connection from a workstation that has never talked to it before, at an hour when no engineering happens.
- Missing authentication being abused: a configuration or logic change arrives from a device that has no change-control history against that controller.
- An authenticated operator misusing the SCADA HMI: a serialized-command pattern that diverges from everything that operator — and every operator like them — has ever issued.
None of this requires knowing the vulnerability exists. It only requires knowing what the network normally does, and flagging the deviation. That is precisely why it matters when patching is structurally slow: detection does not depend on the patch.
What would the control platform scenario look like to detection?
Consider the HIPASE-250 case as an operator, not as an advisory reader.
Your plant is running V7.x because the control system has been stable for years and the maintenance window is hard to justify. You did not know — until August 2026 — that the device stored passwords in a recoverable format, or carried hard-coded credentials, or allowed a critical function to be reached without authentication. An attacker who did know could recover credentials, reach the platform, and move to connected workstations.
To a signature-based tool, this is invisible: there is no known-bad artifact, no indicator of compromise, no malicious hash. But to a behavioural baseline, the signals are plain. The control platform’s network behaviour is narrow and predictable — a small set of peer devices, a steady heartbeat, rare configuration writes. The first time an unfamiliar workstation authenticates to it, the first time a configuration write arrives outside a maintenance window, the first time a credential that should never be used gets used — each is a deviation from normal. Each is visible without a patch and without a signature.
That is the point: you may not be able to close the gap, but you can watch it.
The takeaway
The August 13 advisory batch is not remarkable because of what it contained. It is remarkable because of what it reveals about timing — a fix that sat in release notes for twenty months, on a control system that cannot be patched casually, carrying flaws that look like normal access.
Vulnerability management in OT will always lag the threat. That is not a failing to be embarrassed about; it is a condition to be engineered around. Patching closes the gap slowly and imperfectly. Detection closes it continuously — by watching behaviour, not waiting for a fix.
If you can patch, patch. For everything you cannot patch this month, the question is simpler and harder: can you see it behave?
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.
Maigadi Networks provides passive, signature-less network detection & response for OT/ICS environments. We help operators see what their industrial networks are actually doing — on-premise, explainable, and sovereign by design.