Understanding Modbus: The Protocol That Runs (and Risks) Industry

What is Modbus?

Modbus is one of the oldest and most widely deployed industrial communication protocols. Created by Modicon in 1979, it was designed for communication between PLCs and other industrial devices. Nearly 50 years later, it remains ubiquitous in manufacturing, water treatment, energy, building automation, and virtually every sector that uses industrial control systems.

Understanding Modbus is foundational to OT/ICS security because it’s likely to be running on almost any industrial network you’ll encounter.

How Modbus Works

Modbus uses a simple client-server (master-slave) architecture:

• The client (typically an HMI or SCADA server) initiates requests
• The server (typically a PLC or RTU) responds with data or confirms a write operation

The protocol operates on four types of data:

Common Function Codes

Every Modbus message includes a function code that tells the server what to do:

1
2
3
4
5
6
7
8

0x01 - Read Coils
0x02 - Read Discrete Inputs
0x03 - Read Holding Registers    ← Most common
0x04 - Read Input Registers
0x05 - Write Single Coil
0x06 - Write Single Register
0x0F - Write Multiple Coils
0x10 - Write Multiple Registers  ← Most dangerous for attackers

The Security Problem

Modbus was designed in 1979 for isolated serial networks. It has zero security features:

No authentication — any device that can reach the Modbus server can read or write data. There’s no username, password, certificate, or token. If you can send a TCP packet to port 502, you can control the PLC.

No encryption — all data travels in cleartext. An attacker with network access can observe every process value and every command.

No integrity checking — beyond a basic CRC for transmission errors, there’s no way to verify that a message hasn’t been tampered with.

No authorisation — there’s no concept of permissions. A device that can read sensors can also write to actuator controls.

Why It Still Exists

If Modbus is so insecure, why hasn’t industry replaced it? Several reasons:

• Legacy investment — billions of pounds worth of installed equipment speaks Modbus
• Simplicity — it’s easy to implement, debug, and maintain
• Availability priority — in OT, uptime is often more critical than confidentiality
• “If it isn’t broken” — many operators are reluctant to change systems that have worked for decades
• Replacement cost — upgrading protocols often means replacing hardware, not just software

This is one of the central tensions in OT cybersecurity: the gap between what security requires and what operational reality permits.

Defensive Approaches

Since you often can’t replace Modbus, defenders focus on compensating controls:

• Network segmentation — isolate Modbus traffic to dedicated VLANs
• Deep packet inspection — use OT-aware firewalls that can inspect and filter Modbus function codes
• Allowlisting — only permit expected function codes and register addresses
• Network monitoring — baseline normal Modbus traffic patterns and alert on deviations
• Physical controls — hardware key switches that must be turned before PLCs accept write commands

Try It Yourself

If you want to explore Modbus hands-on in a safe lab environment:

1. Set up OpenPLC on a Raspberry Pi or VM
2. Use ModRSSim2 as a Modbus device simulator
3. Capture traffic with Wireshark (filter: modbus)
4. Use mbtget or Python’s pymodbus library to read and write registers

This is genuinely one of the best ways to understand both how ICS communication works and why it’s so vulnerable.

Further Reading

• Modbus Protocol Specification
• SANS Reading Room: Modbus Security
• NIST SP 800-82: Guide to OT Security

Customise this with your own Modbus captures, screenshots, and lab observations.