Modbus TCP is endemic in manufacturing—thousands of devices across industrial sectors run Modbus. The protocol has no inherent security: no authentication, no encryption, no message integrity checking. It assumes a trusted local network. Yet most modern OT networks are not local anymore. They are spread across multiple zones, connected through firewalls, and exposed to risks that were unimaginable when Modbus was designed.
The question is not how to replace Modbus TCP—that is not feasible in existing deployments. The question is how to run Modbus safely across untrusted network segments and how to detect when it is being abused. The answer combines firewall rules, authentication proxies, and monitoring.
Firewall Rule Design for Modbus
Modbus TCP runs on port 502 (or on non-standard ports if configured). Firewall rules should be explicitly narrow: allow traffic from specific source devices to specific destination devices on specific ports. Never allow any device to reach any other device on 502. Track which Modbus servers exist in your network and which clients legitimately access them, then write rules accordingly.
Distinguish between human access (engineering workstations querying servers) and device-to-device access (PLCs running Modbus commands). Human access can terminate through bastion hosts; device access should be direct where possible to minimize latency. Configure rules to reflect these patterns.
Authentication and Monitoring for Modbus
- Session Logging: Place a Modbus proxy at zone boundaries that logs all Modbus connections: source device, destination device, function codes requested, and data accessed. This creates an audit trail and baseline of normal access patterns. Anomalies—a PLC requesting data it has never requested before, or requesting at unusual times—become detectable.
- Rate Limiting: Configure firewall or proxy to rate-limit Modbus connections. Legitimate production traffic follows regular patterns. Scanning or brute-force attacks against Modbus servers will show up as connection rate spikes.
- Function Code Filtering: Some Modbus function codes are more dangerous than others. Write function code 16 (write multiple registers) should be more tightly restricted than function code 3 (read holding registers). Configure proxy or IDS to alert on unexpected function codes or writes from unexpected sources.
- Encrypted Tunnels: If Modbus must cross untrusted network segments, tunnel it through encrypted channels (IPsec, TLS, SSH port forwarding) rather than sending it in the clear. This prevents passive eavesdropping and simplifies authentication.
Protocol Upgrading Path
Modbus TCP remains deeply embedded in manufacturing because it is simple and widely supported. Newer protocols like OPC-UA provide authentication, encryption, and better semantics. If you are designing new systems or planning major upgrades, OPC-UA is more defensible long-term. But for existing Modbus deployments, focus on network-layer controls that compensate for lack of built-in security.
The goal is to make Modbus attacks difficult and detectable without requiring complete infrastructure replacement. If you'd like to discuss Modbus security for your facility, reach out.
This article was written by the Cascadia OT Security practice, which advises Pacific Northwest data centers and manufacturers on industrial cybersecurity. For engagement inquiries, reach our practice team.