Modbus is a communication protocol used to exchange data between industrial devices — most commonly between a controlling computer (E.G. a PLC, a Programmable Logic Controller) and the sensors, valves, motors, and other equipment it monitors and controls. First published by Modicon in 1979, Modbus predates almost every other protocol covered on this site, and remains one of the most widely deployed protocols in industrial environments today — found in power generation, water treatment, manufacturing, building automation, and countless other operational technology (OT) settings around the world.
Modbus’s age and simplicity are, at once, the entire reason for its enduring popularity and the source of nearly all of its security problems, as covered below.
Modbus variants
Modbus exists in a few different physical forms, all sharing the same underlying logic:
- Modbus RTU: The original, serial-based version, running over RS-232 or RS-485 wiring directly between devices — no IP networking involved at all.
- Modbus ASCII: A less common serial variant, using human-readable ASCII characters rather than raw binary, at the cost of efficiency.
- Modbus TCP: The modern, networked version, which simply wraps the same Modbus message structure inside a standard TCP/IP packet, allowing Modbus communication to travel over an ordinary Ethernet network rather than requiring dedicated serial wiring. Modbus TCP typically operates on port 502.
This page focuses primarily on Modbus TCP, since it’s the version most relevant to a modern IT/OT-converged network, and the version most exposed to network-based attacks.
The Modbus roles: Master and Slave
Modbus communication follows a simple client/server model, using terminology from the protocol’s original design:
- Master (client): The device initiating communication — typically a central controlling computer, a PLC, or a SCADA (Supervisory Control and Data Acquisition) system.
- Slave (server): The device responding to requests — typically the actual field equipment, such as a sensor, an actuator, or a remote terminal unit (RTU) controlling physical machinery.
Communication is always initiated by the master; a slave device never sends data unprompted. The master periodically polls each slave device for its current readings, or sends a command for it to carry out.
Modbus data model
Modbus organises the data a device exposes into four simple table types:
- Coils: Single-bit, read/write values — typically representing a discrete output, like a relay being switched on or off.
- Discrete Inputs: Single-bit, read-only values — a discrete input, like a sensor reporting whether a door is open or closed.
- Holding Registers: 16-bit, read/write values — used for things like a configurable setpoint (a target temperature, for instance).
- Input Registers: 16-bit, read-only values — used for things like a live sensor reading (an actual measured temperature).
Each of these tables is addressed by a numeric offset, and — much like the OIDs covered on the SNMP page — a specific address doesn’t inherently mean anything on its own; the meaning of “holding register 40001” is entirely down to how that particular device’s manufacturer or integrator has documented and configured it.
Modbus function codes
Every Modbus request includes a function code, specifying what action the master wants to carry out. A handful of the most common:
| Code | Function | Purpose |
|---|---|---|
| 01 | Read Coils | Read the current state of one or more coils |
| 02 | Read Discrete Inputs | Read the current state of one or more discrete inputs |
| 03 | Read Holding Registers | Read the current value of one or more holding registers |
| 04 | Read Input Registers | Read the current value of one or more input registers |
| 05 | Write Single Coil | Set a single coil on or off |
| 06 | Write Single Register | Write a value to a single holding register |
| 15 | Write Multiple Coils | Set multiple coils at once |
| 16 | Write Multiple Registers | Write to multiple holding registers at once |
A basic Modbus TCP exchange, in simplified form, might involve a master sending a Read Holding Registers (03) request specifying a starting address and how many registers to read, with the slave responding with the requested values — or a master sending a Write Single Coil (05) request to physically open a valve, with the slave carrying out that action and confirming.
Querying Modbus yourself
Free, open-source tools exist for interacting with a Modbus TCP device directly, useful both for legitimate diagnostics and for demonstrating the protocol’s behaviour in a lab setting. mbpoll is a common command-line option:
mbpoll -m tcp -a 1 -r 1 -c 10 192.168.1.50This example polls a device at 192.168.1.50, unit ID 1, starting at register address 1, reading 10 registers. On a real industrial network, this same simple command structure is exactly what an attacker (or an unauthorised, curious employee) could use to start probing an exposed device.
Modbus and security
Modbus’s design dates from an era — and a physical context — where security wasn’t a meaningful consideration at all: a serial cable running directly between two pieces of equipment on the same factory floor simply didn’t need authentication, since physical access to that cable was already the only way to reach it. That assumption has not aged well now that Modbus TCP allows the exact same, unmodified protocol to run over an ordinary IP network.
Modbus has no authentication whatsoever. There is no username, password, certificate, or any other credential built into the protocol at all. Any device that can reach a Modbus TCP endpoint over the network can send it commands, and the receiving device has no way to verify who — or what — is on the other end. This is a fundamentally different situation from almost every other protocol covered on this site, most of which have at least evolved some form of authentication over time (even SNMPv1’s weak community strings are, at minimum, an attempt at one); Modbus, in its standard form, has never had one at all.
There is no encryption. Every request and response is sent as plain, readable data. Anyone able to observe Modbus TCP traffic can see exactly what commands are being sent and what data is being returned, in full.
This combination means a network position is often functionally equivalent to full operational control. Where compromising many other protocols covered on this site might expose data, or grant a foothold requiring further steps, an attacker who can simply reach a Modbus TCP device on the network can — with no credentials, no exploit, and no further effort — send it a Write Single Coil or Write Single Register command directly. Depending on what that specific device controls, this could mean opening a valve, disabling a safety interlock, or altering a critical process setpoint, using nothing more sophisticated than the exact same legitimate, standard protocol the real control system uses every day. This is a crucial, sobering distinction from most IT security: in an OT/ICS environment, “gaining access to the network” and “gaining the ability to physically manipulate equipment” can be the same single step.
IT/OT network convergence has significantly widened Modbus’s exposure. Modbus TCP was a reasonably contained risk when industrial networks were genuinely isolated (an “air-gapped” network, with no connection at all to the wider corporate IT network or the Internet). Modern operational efficiency demands — remote monitoring, centralised dashboards, integration with business systems — have led many organisations to bridge their previously isolated OT networks into their broader corporate IT network, sometimes with the connection between the two far less carefully controlled than the sensitivity of what’s on the OT side would warrant. This blurring of the traditional IT/OT boundary is a frequent, recurring theme across real-world incidents involving Critical Infrastructure.
Internet-exposed Modbus devices are routinely found by mass scanning. Search engines that index Internet-facing devices (similar to the exposed MQTT brokers mentioned on the IoT Communication Protocols page) regularly catalogue thousands of Modbus TCP endpoints directly reachable from the public Internet — often the result of a misconfigured firewall rule, or a remote-access solution set up for convenience without fully considering what it was actually exposing.
Given these fundamental protocol-level weaknesses, standard ICS/SCADA security guidance focuses heavily on network-level controls rather than relying on the protocol to protect itself, since it largely can’t:
- Network segmentation: Keeping OT networks genuinely isolated from corporate IT networks and the Internet, with any necessary connection between them passing through a tightly controlled, monitored boundary — often a dedicated firewall or a data diode permitting traffic in one direction only.
- Never exposing Modbus TCP (port 502) directly to the Internet, in the same spirit as the RDP, SMB, and SNMP guidance already covered elsewhere on this site — but with meaningfully higher real-world stakes given what a Modbus device may actually control.
- Modbus/TCP Security (a newer, TLS-based extension to the protocol): An evolution of Modbus that does add authentication and encryption, though adoption across the huge existing installed base of legacy equipment remains slow and inconsistent, given how much industrial equipment stays in service for decades.
- Anomaly-based monitoring: Since legitimate Modbus traffic on a given network tends to follow very predictable, repetitive patterns (the same master polling the same slaves for the same registers, on a regular schedule), unusual or unexpected Modbus commands — particularly unexpected write operations — are often a strong, detectable signal of something worth investigating.