Why Your OT Security Fails at the Protocol Layer: A Configuration Deep Dive

Imagine you're the controls engineer on a night shift at a mid-sized chemical plant. A DCS alarm flashes: a pump in the solvent recovery unit is cycling faster than its design limit. You pull up the historian and see a series of Modbus writes coming from an IP address that shouldn't be talking to that pump. The vendor's remote-access VPN was supposed to be locked down, but someone left a default password on a maintenance laptop. Before you can kill the session, the pump overspeeds and trips a relief valve. No one is hurt, but production is down for six hours. The post-incident review will call it a 'cyber event,' but the real story is that the protocol itself—Modbus—has no security controls, and your configuration did nothing to compensate.

We've all been there. The market is exploding—the global industrial automation market is projected to hit $326.48 billion by 2032 (Maximize Market Research)—and we're layering new protocols on old ones, but we keep treating security as an IT problem. The truth is, most OT security failures start at the protocol layer, where configuration is the only thing standing between a field device and a malicious write. And that's the question we need to answer: What is the single highest-impact configuration change you can make to secure your plant floor protocols?

The Protocol Zoo: Know What You're Actually Running

Walk onto any plant floor and you'll find a menagerie. Modbus, developed in the late 1970s, is still everywhere, using a master-slave register model over serial or Ethernet (OPC Foundation). PROFINET, from Siemens and the PROFIBUS/PROFINET International, brings real-time and isochronous real-time classes for motion control (OPC Foundation). EtherNet/IP, running the Common Industrial Protocol over standard Ethernet, dominates North American Rockwell shops (OPC Foundation). These are the workhorses that talk to sensors and PLCs. Above them, OPC UA and MQTT carry data up to SCADA, MES, and the cloud—OPC UA with built-in encryption and authentication, MQTT as a lightweight publish/subscribe transport standardized in ISO/IEC 20922 (OPC Foundation, ISO/IEC 20922 MQTT Standard).

Here's the kicker: the field-level protocols, the ones that directly control physical processes, were designed in an era of trust. Modbus has zero authentication. PROFINET and EtherNet/IP, in their standard flavors, offer little to no security. That's why the ISA/IEC 62443 series exists—it sets cybersecurity benchmarks for industrial automation and control systems across all sectors (ISA/IEC 62443). But standards only help if you implement them, and that's where we fail.

The Configuration Gap: Where We Drop the Ball

CISA's Secure by Demand guidance for OT warns that threat actors exploit weak authentication, insecure settings, and outdated protocols (CISA Industrial Control Systems). That's not a vague warning; it's a description of the typical plant floor. We're not talking about sophisticated zero-days. We're talking about default passwords, open ports, and protocols that broadcast their registers to anyone who asks.

In our experience, the most common configuration sin is leaving field devices exposed on the same flat network as the enterprise. A PLC with a Modbus/TCP port open to the IT LAN is a write-your-own-disaster. The fix isn't to rip out Modbus—that's impractical. It's to configure the network so that only authorized masters can talk to slaves, and to enable whatever security features the protocol does support. For Modbus, that means using a firewall or a gateway to restrict access by IP and function code. For PROFINET and EtherNet/IP, it means segmenting the real-time traffic and using the security options that exist in the newer versions.

Case in Point: A Concrete Fix for Modbus

Let's get specific. Suppose you have a Modbus/TCP network controlling a set of variable frequency drives (VFDs) for conveyor motors. In a default configuration, any device on the network can send a Modbus write to any register on any drive, changing speed, torque, or even disabling safety functions. A simple misconfiguration—say, a PLC programmer's laptop with a stray Modbus client—can cause a production line to halt. To fix this, you could implement a Modbus gateway that enforces a whitelist: only the PLC's IP and a limited set of function codes (like 03 for read holding registers and 06 for write single register) are allowed through. This is a configuration change, not a protocol upgrade, and it can be done with existing hardware. The ISA/IEC 62443 standard would call this 'network segmentation' and 'least privilege' (ISA/IEC 62443).

We've done this in practice, and it's not glamorous. It takes an afternoon to map the traffic, a day to configure the firewall rules, and a week of testing. But it stops the scenario I opened with—the rogue write to a pump—cold. And it's the kind of change that doesn't require a shutdown if you do it during a planned outage.

Why We Keep Avoiding It

Why don't we do this more often? Because it's boring. We'd rather chase the shiny new protocol—MQTT with its TLS and OAuth—than harden the legacy stuff. But MQTT itself is not a security silver bullet. It's a messaging transport that is agnostic to payload content (ISO/IEC 20922 MQTT Standard). Yes, it supports TLS and client authentication, but you have to configure those (MQTT.org). And when you bridge MQTT to a Modbus network, you still have to secure the Modbus side.

The market pressures don't help. With the industrial IoT market growing at a 12.2% CAGR (Maximize Market Research), vendors are pushing connectivity, not security. But the ISA/IEC 62443 framework, which is recognized as a horizontal standard by the IEC, gives us a roadmap (ISA/IEC 62443). The problem is that asset owners and integrators often skip the risk assessment and jump straight to buying a firewall. That's backward.

The One Change That Matters Most

So what's the single highest-impact configuration change? It's this: Implement strict network segmentation between the field-level protocol networks (Modbus, PROFINET, EtherNet/IP) and everything else, and enforce allow-listing at the protocol layer. That means using firewalls, VLANs, or protocol-aware gateways to ensure that only authorized devices can initiate communication, and only on the specific function codes and register ranges they need.

This is not a new idea—it's the core of the 'zones and conduits' concept in ISA/IEC 62443 (ISA/IEC 62443). But we consistently fail to execute it. We leave a PLC on the same subnet as a Wi-Fi access point, or we open a port for a vendor and forget to close it. The fix is not to add more security software; it's to configure what you have correctly.

Here's a short list of what that configuration looks like in practice:

• Segment each cell or area into its own VLAN, with no direct routing to the IT network.
• Deploy a protocol-aware firewall or gateway that can inspect Modbus/TCP, PROFINET, or EtherNet/IP and enforce allow-lists of IP addresses and function codes.
• Disable any unused services on PLCs and drives—if a port isn't needed, close it.
• Change all default passwords, and use strong authentication for any remote access, per NIST SP 800-82 Rev. 3 guidance (NIST SP 800-82 Rev. 3).

It's Not About the Protocol, It's About the Configuration

We've seen too many articles that debate Modbus vs. OPC UA or tell you to adopt MQTT for security. That's missing the point. The protocol is just a tool; the configuration is what makes it secure or not. OPC UA has built-in encryption, but if you leave the anonymous access enabled, it's as insecure as Modbus. MQTT supports TLS, but if you don't enforce it, your data is in the clear.

Our recommendation is plain: stop waiting for a new protocol to save you. Instead, audit the systems you have, segment the networks, and configure the security features that already exist. The ISA/IEC 62443 standard gives you a framework, and CISA's Secure by Demand guidance tells you what to look for in new products (CISA Industrial Control Systems). But the real work is on the plant floor, in the configuration files and firewall rules.

We're not saying it's easy. It takes time and discipline. But it's the highest-leverage change you can make. A well-configured Modbus network is more secure than a poorly configured OPC UA network any day. And when the next audit comes, you'll have the evidence to show you're not just paying lip service to security.

Bottom Line

The single best move you can make today is to map your field-level protocol traffic, segment those networks, and enforce allow-lists at the protocol layer. That's the configuration that will stop the next attack, and it's within your control. Do that before you chase another protocol.

Sources

• OPC Foundation - https://opcfoundation.org/
• Maximize Market Research - https://www.maximizemarketresearch.com/
• ISO/IEC 20922 MQTT Standard - https://www.iso.org/standard/69466.html
• MQTT.org - https://mqtt.org/
• ISA/IEC 62443 - https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• NIST SP 800-82 Rev. 3 - https://csrc.nist.gov/pubs/sp/800/82/r3/final
• CISA Industrial Control Systems - https://www.cisa.gov/topics/industrial-control-systems