The Modbus Problem Nobody Wants to Talk About
Modbus TCP is everywhere in OT. PLCs, RTUs, SCADA gateways, building management systems. If you've worked in industrial environments for more than a year, you've touched it.
The protocol was designed in 1979. It assumes a trusted, air-gapped network where everyone with physical access is authorized. That assumption stopped being true about two decades ago, but most plants still run Modbus wide open on flat networks with no authentication, no encryption, and no access control whatsoever.
This isn't a theoretical risk. Anyone with Wireshark and network access can read every register value in plaintext. Anyone with a Python script can write to coils and holding registers. There's no handshake, no session token, nothing.
What Makes Modbus TCP Hard to Secure
Modbus TCP takes the original serial protocol and wraps it in TCP/IP on port 502. That's it. There's no TLS, no authentication header, no concept of user identity.
No authentication. A Modbus TCP server will happily accept commands from any IP address that can reach it. There's no username, no password, no certificate exchange. If you can open a TCP connection to port 502, you're in.
No encryption. Every function code, register address, and value travels in cleartext. An attacker on the network can see exactly what your HMI is reading and writing. They can also modify packets in transit if they're positioned for a man-in-the-middle attack.
Replay is trivial. Modbus TCP packets are stateless enough that captured traffic can be replayed later. Record a "write single coil" command and you can fire it again whenever you want. The PLC won't know the difference.
Network Segmentation: Start Here
If you do nothing else, segment your Modbus traffic away from the rest of your network. This single step eliminates the largest class of attacks, which is someone on the corporate LAN (or a compromised IT workstation) reaching directly into your control network.
VLANs are the minimum. Put your Modbus devices on their own VLAN. Don't just tag the traffic and call it done. Make sure inter-VLAN routing is locked down so only specific hosts can cross the boundary.
Firewalls between zones matter. A VLAN without a firewall between it and the rest of the network is just organizational decoration. You need stateful packet inspection at the boundary, with rules that explicitly allow only the source/destination pairs and ports you expect.
If you're following IEC 62443, this maps to the zone and conduit model. In practice, that means drawing a clear line between your Level 2 (control) and Level 3 (site operations) networks, with a defined conduit for any traffic that needs to cross.
Encrypting Modbus Traffic
Since Modbus TCP has zero native encryption, you have to wrap it in something else.
VPN tunnels between sites or between an engineering workstation and the control network are the most common approach. IPsec or WireGuard both work. The key is making sure the tunnel terminates as close to the Modbus device as possible, not at the edge of a flat network where traffic travels unencrypted for the last hop.
TLS wrappers like stunnel can encrypt Modbus TCP between two endpoints. This works well for point-to-point links, like an HMI talking to a specific PLC. It's more overhead to manage at scale, but it gives you per-connection encryption.
Protocol-aware firewalls add another layer. A firewall that understands Modbus function codes can block write commands from hosts that should only be reading, or restrict which register ranges a particular source can access. An inline proxy that understands Modbus function codes can enforce per-device, per-function-code policies without requiring changes to the PLC or the HMI.
Access Control Without Native Support
Modbus doesn't know what a "user" is. So you have to enforce access control at the network and application layers instead.
Allowlist source IPs at the firewall. Only the HMI, the historian, and the engineering workstation should be able to reach port 502 on your PLCs. Everything else gets dropped. This is crude, but it eliminates drive-by access from random machines on the network.
Use a gateway or proxy for role-based control. If you need finer granularity (read-only for operators, read-write for engineers), you need something sitting in front of the Modbus device that maps authenticated users to permission sets. A Modbus-aware access gateway does this by terminating the Modbus connection, authenticating the user, and then proxying only the allowed function codes to the downstream device.
MFA for remote access, always. If anyone is connecting to your control network remotely, whether through a VPN, a jump host, or a cloud gateway, they need multi-factor authentication. This is non-negotiable. A stolen password should not be enough to reach a PLC.
Monitoring: You Can't Protect What You Can't See
Flat Modbus traffic is actually easy to monitor because it's plaintext and well-structured. Take advantage of that.
Run an IDS that understands Modbus. Snort and Suricata both have Modbus preprocessors. They can alert on unexpected function codes, writes to register ranges that shouldn't be written to, or traffic from IP addresses that aren't on your allowlist.
Baseline your normal traffic first. Before you start writing alert rules, capture a week of normal Modbus traffic and characterize it. How often does the HMI poll? Which registers does it read? Does anyone ever write to coils during normal operations? Once you know what "normal" looks like, anomalies become obvious.
Log everything at the gateway. If you're running a Modbus proxy or gateway, log every connection and every function code. When something goes wrong, having a full audit trail of who wrote what to which register, and when, is the difference between a 30-minute investigation and a three-day forensic exercise.
Patch Management in OT Is Different
Patching in OT isn't like patching IT. You can't just push updates on Tuesday night and reboot. Downtime costs real money, and a bad firmware update on a PLC can shut down a production line.
Know what you're running. Maintain an inventory of every Modbus-speaking device, its firmware version, and its vendor's patch status. Most plants can't answer this question, which means they can't patch even if they want to.
Test patches in a staging environment. If you have a test PLC or a simulation setup, validate patches there before deploying to production. If you don't have a test environment, you need one. The cost is trivial compared to a failed update on a live system.
Schedule maintenance windows realistically. Work with operations to find windows where patching is possible. Quarterly is a reasonable target for most environments. Annual is too slow. Monthly is aspirational for OT, but aim for it if you can.
Standards Worth Following
IEC 62443 is the gold standard for industrial cybersecurity. It gives you a framework for zones, conduits, and security levels that maps directly to real network architecture decisions. Start with parts 3-2 (security risk assessment) and 3-3 (system security requirements).
NIST SP 800-82 is the U.S. government's guide to ICS security. It's practical and well-written. If you're in a CMMC or NIST 800-171 environment, it aligns with those requirements and gives you OT-specific guidance that 800-171 alone doesn't cover.
NIS2 applies if you're operating in the EU or selling into EU critical infrastructure sectors. It imposes incident reporting obligations and security requirements that specifically cover OT environments. If you're not already tracking NIS2 compliance, check whether your organization falls under its scope.
Where to Start Tomorrow
Pick the highest-impact item you haven't done yet. For most plants running Modbus TCP on a flat network, that's segmentation. Put your control devices behind a firewall, restrict which hosts can reach port 502, and log the connections. That alone will close most of the gaps. Everything else builds on top of that foundation.
