Modbus RTU - the oldest fieldbus protocol and its security

Modbus RTU (Remote Terminal Unit) is a serial communication protocol developed in 1979 by Modicon (now Schneider Electric) for PLC communication. Despite being nearly five decades old, Modbus RTU remains one of the most commonly encountered protocols in industrial automation - from simple HVAC installations, through production lines, to energy infrastructure. Its popularity stems from simplicity, low implementation costs, and universality - virtually every OT device supports Modbus.

Modbus RTU transmits data in binary format over RS-485 or RS-232 serial links. Its network counterpart - Modbus TCP (port 502) - carries the same logic over Ethernet, but Modbus RTU still dominates at the field level (levels 0-1 of the Purdue model), where RS-485 connects PLCs to sensors, transducers, and actuators.

Protocol architecture

Modbus RTU operates on a master-slave model (in newer terminology: client-server). The master (PLC, SCADA) sends queries, the slave (sensor, transducer, drive) responds.

Parameter	Modbus RTU
Physical layer	RS-485 (2/4-wire, multidrop) or RS-232 (point-to-point)
Topology	Master-slave, up to 247 devices on an RS-485 bus
Speed	9600-115200 baud (typically 9600 or 19200)
Authentication	None
Encryption	None
Integrity	CRC-16 (transmission error detection, not cryptographic protection)
Addressing	1-247 (slave address in frame header)
Range	RS-485: up to 1200 m, RS-232: up to 15 m

Key Modbus function codes:

• 01/02 - read coils / discrete inputs
• 03/04 - read registers (holding/input registers)
• 05/06 - write single coil / register
• 15/16 - write multiple coils / registers

Each of these functions executes without any authentication - whoever has access to the bus can both read and write registers of any device.

Applications

Modbus RTU is used wherever PLCs or RTUs communicate with field devices:

• Industrial automation - PLC communication with measurement transducers (temperature, pressure, flow), VFD drives, valves
• Energy - reading parameters from power analyzers, energy meters, power protection relays
• Water and wastewater - pump control, tank level monitoring
• HVAC - communication between air handling unit controllers, sensors, and actuators

Security assessment

Modbus RTU was designed in an era when industrial networks were physically isolated and the only threat was transmission errors (hence CRC-16). The protocol contains no security mechanisms:

• No authentication - any device connected to the RS-485 bus can send commands to any slave. There is no concept of an “authorized master”
• No encryption - data is transmitted in the clear. On an RS-485 bus every device sees all traffic (shared medium)
• No cryptographic integrity - CRC-16 protects only against transmission errors, not deliberate frame modification
• No device authentication - an attacker can connect their own device to the RS-485 bus and impersonate an existing slave or master

Attack scenarios on Modbus RTU:

1. Bus eavesdropping - connecting an analyzer to RS-485 (physical access to any point on the bus is sufficient) allows reading all process values
2. Command injection - sending a Write Register frame with a substituted slave address changes process setpoints (e.g. pressure, temperature, RPM)
3. Man-in-the-middle - an intermediary device on the bus can modify slave responses, falsifying process data displayed on the HMI

Segmentation and protection

Since Modbus RTU offers no security mechanisms at the protocol level, protection relies on physical and architectural safeguards.

Physical bus protection:

1. Physical access control - control cabinets with locks, video surveillance in rooms with RS-485 infrastructure
2. Cable route protection - RS-485 buses in enclosed cable trays or conduits with access control
3. Tamper detection - systems detecting control cabinet opening (reed switches, tamper sensors)

Architectural segmentation:

1. RTU/TCP converters as zone boundaries - a Modbus RTU/TCP converter should sit behind a firewall with Modbus inspection (DPI) that filters allowed function codes and register ranges
2. Restricting communication direction - the firewall permits only reads (codes 01-04) from the SCADA level, blocking writes (codes 05, 06, 15, 16) from higher-level networks
3. Bus separation - separate RS-485 segments for different processes (e.g. production line A and B), connected to SCADA through separate converters
4. Traffic monitoring - OT-dedicated IDS systems (e.g. Nozomi Networks, Claroty) can parse Modbus RTU/TCP and detect anomalies (new addresses, unusual function codes, writes outside normal cycles)

Detailed guidelines for designing zones and conduits for networks with fieldbus protocols are described in the article on OT network segmentation.

Sources

• Modbus Application Protocol Specification V1.1b3 - official protocol specification
• Modbus/TCP Security Protocol Specification - TLS extension
• NIST SP 800-82 Rev. 3 - Guide to OT Security
• ICS-CERT - Modbus Protocol Deep Dive - protocol security analysis
• IEC 62443-3-3 - security requirements for industrial automation systems