The Modbus blind spot: when a valid command is the attack
In 1979, Modicon published a protocol specification for their programmable logic controllers. It was simple — read a coil, write a register, move on. No handshake. No session. No identity check. The assumption was that if you were on the factory floor, you belonged there.
Forty-seven years later, Modbus runs the same way. It carries millions of OT commands every day — pump speeds, valve positions, temperature setpoints — and it has no built-in mechanism to verify who sent any of them. That is not a bug. It is the design.
What Modbus actually is (and why it’s everywhere)
Modbus is the lingua franca of industrial control. It speaks across RS-232, RS-485, and TCP/IP. It is implemented by every major PLC, RTU, and HMI vendor. It is simple enough to fit in a single-page reference card and powerful enough to run a water treatment plant.
The protocol’s simplicity is its superpower and its Achilles’ heel. A Modbus request is a short binary packet: a function code (read holding registers, write single coil), a data address, and a value. There is no field for “who sent this.” There is no authentication token, no cryptographic signature, no role identifier. A write to register 40001 looks the same whether it came from the engineering workstation, the SCADA server, or a compromised historian sitting three network hops away.
The authentication gap that signatures can’t close
When we talk about OT attacks, the default mental model is often signature-based: a known exploit payload, a specific byte pattern, a CVE with a detection rule. That model works for attacks that break things — malformed packets, buffer overflows, protocol violations that crash the controller.
But a perfectly valid Modbus write, entirely compliant with the protocol specification, can also be an attack — if it comes from a device that should never issue one.
Consider a temperature setpoint changed from 150°F to 500°F. Every byte is valid. The function code is correct. The address exists. The value is within range. No signature will flag it, because there is nothing malformed about it. The danger is not in the content of the command — it is in the context of who sent it and whether that device has any business writing to that register.
This is the Modbus blind spot. Signatures catch what’s been seen before. They cannot catch a legitimate command issued by the wrong actor at the wrong time.
The dual problem: identity and expectations
There are really two problems layered on top of each other.
The first is identity. Modbus does not authenticate. Anyone with network access to a device that speaks Modbus TCP over port 502 can read coils, write registers, and modify the behaviour of physical processes. No password. No key exchange. The protocol assumes trust at the network layer — an assumption that made perfect sense when the factory floor was air-gapped and Ethernet had not yet connected it to the world.
The second is expectations. On a real OT network, devices have highly constrained roles. An engineering workstation writes configuration changes. A SCADA server polls for telemetry. A PLC talks to its I/O. An HMI reads data for display. These roles are stable over weeks and months. When a historian suddenly issues a write command to a pump controller, that is not an authentication failure in the cryptographic sense. It is an expectation violation — a device doing something it has no business doing.
What good detection actually looks like
This is where the detection model has to shift. Instead of asking “is this packet malicious,” the question becomes “is this behaviour unexpected.”
A passive network sensor that learns the normal communication patterns of an OT environment can answer that question. It observes which devices talk to each other, what function codes they use, how often they poll, and what range of values they write. Over time, that becomes a behavioural baseline — not a list of rules, but a model of what this network looks like when it’s healthy.
Against that baseline, a routine Modbus write that deviates from the learned pattern — different source, unusual register, unexpected value — is surfaced. Not because the packet is malformed. Because the behaviour doesn’t fit the normal.
Equally important is knowing what a healthy OT network should look like in the first place. A truly novel attack might be the first anomaly a baseline ever sees. Engineering first principles — proper Purdue model segmentation, sane polling intervals, expected protocol behaviour — provide that second lens. Together, the two lenses let detection say not just “this changed” but “this shouldn’t be happening at all.”
The question worth asking
The defender’s challenge with Modbus is not about patching the protocol. Modbus will not be rewritten. Authentication will not be retrofitted onto forty-year-old field devices. The installed base is too large, the operational risk of change too high, and the industry’s hardware refresh cycles are measured in decades.
The question worth asking is a different one: can you tell when a valid Modbus write is unexpected — from a device that should never issue one? That question shifts the burden from the protocol (which offers no help) to the network (which holds the answer, if you’re watching closely).
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.