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 way 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. Every major PLC, RTU, and HMI vendor implements it. It is simple enough to fit on a single-page reference card and powerful enough to run a water treatment plant.
That simplicity is both 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.” 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 signatures can’t close
When we talk about OT attacks, the default mental model is usually 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 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 in 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 — who sent it, and whether that device has any business writing to that register.
That is the Modbus blind spot. Signatures catch what has been seen before. They cannot catch a legitimate command issued by the wrong actor at the wrong time.
Two problems stacked on top of each other
The first is identity. Modbus does not authenticate. Anyone with network access to a device speaking Modbus TCP over port 502 can read coils, write registers, and change the behaviour of physical processes. No password. No key exchange. The protocol assumes trust at the network layer — an assumption that made 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 tightly 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 for 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
So the question has to shift. Instead of asking “is this packet malicious,” ask “is this behaviour unexpected.”
A passive network sensor that learns the normal communication patterns of an OT environment can answer that. It watches which devices talk to each other, what function codes they use, how often they poll, 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 is healthy.
Against that baseline, a routine Modbus write that deviates from the learned pattern — different source, unusual register, unexpected value — gets surfaced. Not because the packet is malformed. Because the behaviour does not fit the normal.
Just as important is knowing what a healthy OT network should look like in the first place. A genuinely 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 run in decades.
The question worth asking is different: can you tell when a valid Modbus write is unexpected — from a device that should never issue one? That shifts the burden from the protocol (which offers no help) to the network (which holds the answer, if you are 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.