OPC UA Secured OT Traffic. It Also Made Attacks Harder to See.
For a decade, the standard advice to any plant modernizing its network has been the same: get off Modbus, move to OPC UA. The reasoning is sound. Modbus has no authentication — any device on the wire can write to any register it can reach. DNP3’s secure authentication is an optional layer many utilities never turn on. S7comm trusts whoever holds the connection. OPC UA closes all of that: certificates identify every application, sessions are signed and encrypted, and a real permission model governs who may read, write, or call. It is, by any fair measure, the most secure industrial protocol in wide deployment.
Which is exactly why its latest advisory is worth sitting with.
On 15 October, CISA published ICSA-26-288-01 for Eclipse Milo, a widely used open-source OPC UA stack that ships inside industrial software from HMI and SCADA products to gateways and edge devices. The advisory lists five vulnerabilities with a CVSS v3 score of 8.2, spanning the chemical, critical manufacturing, energy, and water sectors, affecting versions 0.6.0 through 1.1.4. One of them is a particularly neat little attack.
CVE-2026-62927 lives in Milo’s Call service. The authorization check is applied to a batch of method calls as a whole — but the batch is then dispatched to the address space one method at a time. A client with low, or even anonymous, privileges can slip a method it is not allowed to execute into a batch alongside one it is. The denied method still runs. No exploit, no malware, no memory corruption: just a logic gap between “check the batch” and “run the batch.”
Notice what kind of attack that is. There is no signature for it. No known-bad byte sequence, no C2 beacon, no malicious file. The attack is a legitimate OPC UA Call service used in a way its own authorization logic failed to anticipate. It is novel by definition — the vulnerability was published this month, and the first signature for it cannot exist until someone writes one after the fact. That is the category of problem a signature-based detector is structurally unable to catch, and it arrived in the one protocol everyone treats as the secure option.
What OPC UA changed, and why it won
The legacy protocols OPC UA displaces were designed for a different world: a serial line or a closed plant floor where every device was assumed to be friendly. Modbus has function codes, not identities. DNP3 can authenticate, but the flag is off by default and often stays off because enabling it adds overhead to every message on a link sized in the 1990s. S7comm has no authentication at all, because the engineers who built it never imagined a controller talking to anything but a trusted engineering station.
OPC UA was the industry’s answer: a protocol built from the start around certificates, session encryption, and a role-based permission model. A server knows which client it is talking to. A client knows it is talking to the real server, not an imposter. A malicious device cannot simply sit on the wire and inject a write the way it can with Modbus. That is a genuine improvement, and it is why OPC UA won. It now sits at the backbone of a generation of industrial systems, from wind farms to water plants.
Encryption is the point — and also the catch
Here is the part nobody put on the slide. The same encryption that makes OPC UA trustworthy also makes its traffic opaque. A signature-based detector, the kind that watches for known-bad payloads, can only match what it can see. In a Modbus network it sees everything, because the traffic is clear text: the function code, the register, the value. In an OPC UA network with encryption enabled, the payload is ciphertext. A write to a lye-feed setpoint and a routine read of a tank level are both just opaque OPC UA messages on the same port.
That is not an argument against encryption. Encryption is correct, and a plant that runs OPC UA in clear-text or sign-only mode to keep its legacy tools working is trading away the exact property it migrated for. The point is narrower: the security property and the visibility property pull in opposite directions. The traffic did not get safer and stay visible. It got safer by becoming invisible to everything that cannot decrypt it.
What encryption can’t hide
Encryption hides the content of a message. It does not hide the fact of a conversation — and for a surprising amount of what goes wrong in an OT network, the fact of the conversation is enough.
Start with the certificate. When an OPC UA client opens a secure channel to a server, the two applications exchange their X.509 certificates before the channel encrypts anything. That exchange is visible on the wire: which application, with which identity, connected to which server, and when. A plant that has been running for years has a small, stable population of those identities. A certificate nobody has ever seen, appearing on the OPC UA port at three in the morning, is not a subtle event — unless nothing is watching for it.
Then the shape of the session. OPC UA runs on a known port, 4840 by default. Sessions are long-lived, and traffic has a rhythm: this client polls that server every thirty seconds, all day, every day. A behavioral baseline learns that rhythm the way an operator learns the sound of a pump. When a client that has polled the same three tags for a year suddenly opens a session to a server it has never touched, or fires a burst of calls where it has always been a quiet reader, that deviation is visible entirely in the metadata — the who, the when, the how often — without ever decrypting a single value.
Doesn’t OPC UA authentication stop attackers before they get in?
Authentication answers one question: are you who you say you are? It does not answer the harder one: are you supposed to be doing this? A stolen or compromised certificate gives an attacker a perfectly valid identity. A legitimate client — an integrator’s laptop, a contractor’s gateway — that has drifted into hostile hands still presents its real certificate and still passes the authentication check. And Milo’s batching flaw shows the model itself can have holes: the authorization logic checked the batch, then ran it method by method, and a denied method still executed.
None of these require breaking encryption or forging an identity. They require an identity the network already trusts to do something it was never meant to do. That is a behavioral question, not an authentication one.
Can’t you just decrypt and inspect OPC UA?
Technically, sometimes. You can terminate the session in a proxy, decrypt, inspect, re-encrypt, and forward. But that is a man-in-the-middle by design, and in an OT plant it carries real costs: it breaks the end-to-end trust model the protocol was built around, it becomes a new single point of failure sitting in front of a process that cannot stop, and it tends to be unacceptable to the same engineers who chose OPC UA precisely so that nobody could sit in the middle of their traffic. Key escrow raises the same objections from a different direction.
The alternative is to stop demanding the payload and start reading what encryption leaves in the open: the relationships, the identities, and the rhythms.
What does a healthy OPC UA network look like?
It looks boring. A small, stable set of clients talks to a small, stable set of servers. Each client holds one certificate, renewed on a schedule. Sessions are long-lived. Traffic has a rhythm. That boringness is the asset — it is exactly what a behavioral baseline captures, and exactly what makes the exceptions stand out. The new certificate at 3 a.m. The client that has only ever read, suddenly calling methods. The batch of service calls from an account with no business issuing them.
A healthy network does not need to be watched for what it contains. It needs to be watched for what it stops being. And here the baseline framing matters: we freeze the baseline, not the detection — the attack is still fully caught, and the baseline is just the reference of normal it is measured against.
A secure protocol is not a watched network
OPC UA was a genuine step forward for OT security, and no clear-eyed engineer would go back to clear-text Modbus. But the migration quietly moved a lot of traffic out of reach of the tools built for the clear-text era, and the Milo advisory is a reminder that a secure protocol is not the same thing as a secure network.
The protocol’s job is to keep the wrong people out. Detection’s job is to notice when someone already in — with a valid certificate and a legitimate client — starts doing something the network has never seen. That second job does not get easier when the traffic is encrypted. It just moves to the one layer encryption cannot hide: the shape of the network itself, and whether it still looks like itself.
This is the problem Maigadi was built to address.
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.