Modbus
The 1979-vintage Modicon serial protocol that became the world's de facto industrial-fieldbus interlingua. Plain-text, no authentication, no encryption — and still the protocol of last resort for any piece of plant that needs to be polled by anything else. Modbus TCP is the same protocol over Ethernet, with the same security posture.
Also: MODBUS, Modbus RTU, Modbus TCP, Modbus/TCP
Modbus is the 1979 Modicon protocol that, by virtue of being technically simple and royalty-free for decades, became the world’s de facto industrial-fieldbus interlingua. It is the protocol the cheap I/O module talks. It is the protocol the legacy meter talks. It is the protocol that, when no other protocol is supported, is the protocol that is supported.
In substation context it is rarely the headline — DNP3 and IEC 60870-5-104 carry the SCADA telemetry; MMS and GOOSE carry the protection traffic — but Modbus is sitting underneath them somewhere, talking to a temperature sensor, an auxiliary battery monitor, an HVAC controller, or a vendor I/O block that nobody specified for a more modern protocol.
What it actually is
Modbus is a request/response protocol over a master/slave (the original terminology, retained in most documentation despite renaming efforts) topology:
- A master issues read or write requests addressed to a slave.
- A slave answers with the requested data or acknowledges the write.
- Data is organised into four banks: Coils (read/write single-bit), Discrete Inputs (read-only single-bit), Input Registers (read-only 16-bit), Holding Registers (read/write 16-bit).
- Function codes (3 = read holding registers, 6 = write single register, 16 = write multiple registers, etc.) define the operation.
That’s the whole protocol. It is intentionally trivial to implement, which is why it ended up everywhere.
Modbus RTU vs Modbus TCP
| Modbus RTU | Modbus TCP | |
|---|---|---|
| Transport | RS-485 serial | TCP port 502 |
| Address scheme | One-byte slave address per request | IP address + Unit Identifier byte |
| Framing | CRC-16, inter-character timing | TCP framing + 7-byte MBAP header |
| Year of publication | 1979 | 1999 |
The semantic protocol is identical between the two. Modbus TCP is what most substation auxiliary devices speak today; Modbus RTU lives on in serial multidrop runs to legacy I/O panels.
The security posture
Modbus has none. There is no authentication, no encryption, no message integrity, no replay protection. A request to write to coil 100 from any source the slave can hear is honoured. The only protections are network-layer:
- Physical isolation (the serial bus is in a locked cabinet).
- Network segmentation (Modbus TCP is on a non-routable VLAN).
- Allow-listing (a firewall in front of the device permits only specific source IPs).
This puts Modbus at the same place DNP3 was before 62351-5: the protocol is the integrity boundary, and the integrity boundary is no boundary at all.
The Modbus Organization published Modbus/TCP Security in 2018, which adds TLS as a transport wrapper. Adoption has been near-zero in the field — partly because most Modbus devices are simple sensors with too little memory for TLS, partly because the deployment problem (certificates everywhere, on devices nobody updates) is the same problem 62351-9 confronts, only worse.
Where it appears in the substation
Substation-resident Modbus typically sits on conduits the architect has not been thinking about:
- Battery monitor → SCADA. The battery is critical to substation operation; the battery monitor is often Modbus.
- HVAC controller → BMS. Cabinet temperature regulation, often Modbus, often on the same VLAN as everything else by accident.
- Auxiliary metering for billing or revenue protection — Modbus.
- Generic vendor I/O modules — anything bought from a non-power-systems vendor for an integration that needed a few digital inputs.
- Microgrid controllers and DER aggregators — the cheaper end of the DER integration market often uses Modbus rather than IEC 61850-7-420.
These conduits are the ones that get missed in the 62443 zone-and-conduit exercise because they are auxiliary to the main protection and control story — but they are still on the substation LAN, still plain-text, still bridgeable to anywhere else on the network. They are a recurring source of the “we did not know that was there” finding in substation pen-tests.
Why it persists
Modbus persists for the same reason COBOL persists in banking: the installed base is too large and too deeply embedded to displace, the protocol is good enough for the things it does, and the cost of replacement exceeds the perceived risk.
For the substation architect the practical implication is: assume Modbus is somewhere on the LAN. Audit for it. Put it in a zone of its own with a documented conduit and IP allow-listing. Do not pretend it is not there because it is not in the protection scheme.