Stop Chasing the New Protocol: Fix Your OT Security Configuration First

Imagine you're the plant manager at a mid-sized chemical facility. You've just spent the weekend migrating your control system from an aging Modbus network to a shiny new OPC UA backbone. You're proud of the Ethernet cables and the TLS certificates. But Monday morning, the same alarm bells ring: a suspicious login attempt from a forgotten vendor account. You didn't change the password. You didn't update the firewall rules. You just moved the same insecure configuration to a new protocol.

That's the dirty secret of industrial networking: protocols are not the problem. The problem is how we configure them. I'm not saying protocols are irrelevant—they matter. But we've been sold a bill of goods that swapping to OPC UA or MQTT will magically secure our plants. It won't. The real battlefield is configuration, and it's time we fought there.

The Protocol Hype Cycle

Every few years, we get a new protocol that's supposed to fix everything. Modbus was simple, but it's a master-slave register-based model that's been around since the late 1970s (OPC Foundation). Then came PROFINET with real-time and isochronous real-time classes for motion control, and EtherNet/IP running the Common Industrial Protocol over standard Ethernet (OPC Foundation). Now OPC UA is the darling of the IIoT world—vendor-neutral, platform-independent, with built-in encryption and authentication (OPC Foundation). And let's not forget MQTT, the lightweight publish/subscribe messaging transport that's standardized in ISO/IEC 20922:2016 (ISO/IEC 20922 MQTT Standard).

But here's the uncomfortable truth: the protocol is just the carrier. OPC UA can be configured with no security at all. MQTT can run without TLS and with wide-open topics. I've seen EtherNet/IP networks with no authentication. The protocol isn't the defense; the configuration is.

The Configuration Crisis

Look at the security guidance from the people who actually track these attacks. CISA's Secure by Demand guidance for OT explicitly warns that threat actors exploit weak authentication, insecure settings, and outdated protocols (CISA Industrial Control Systems). Notice the order: weak authentication, insecure settings—not "wrong protocol." And the ISA/IEC 62443 standards, which define requirements for securing industrial automation and control systems, focus on processes and stakeholder roles, not on picking a specific protocol (ISA/IEC 62443).

Now, I'm not saying protocols are irrelevant. They are the backbone of your network. But the market is booming—the global industrial automation market is projected to grow from about $184.43 billion in 2025 to $326.48 billion by 2032 (Maximize Market Research). That growth is driving a lot of new devices and new connections. And with that, a lot of new misconfigurations.

Here's a concrete example: You've just installed a new OPC UA server to bridge your PLCs to your MES. You've enabled encryption—good. But you've also left the default admin password on the server, and you've bound it to all network interfaces, exposing it to the IT network. A malicious insider or a remote attacker who finds that port can read your production data or, worse, send false commands. The protocol didn't fail; the configuration did.

The Counter-Argument: "New Protocols Are More Secure"

I can already hear the pushback: "But OPC UA has built-in encryption and authentication—that's more secure than Modbus." True, OPC UA does offer that (OPC Foundation). But built-in doesn't mean automatically enabled. I've seen OPC UA servers deployed with security set to "None" because the integrator didn't want to deal with certificates. I've seen MQTT brokers with no authentication because "it's just for telemetry." The capability is there; the configuration is the bottleneck.

And let's not forget MQTT's QoS levels—0, 1, and 2 (MQTT.org). They control delivery guarantees, not security. A QoS 2 message is still unencrypted if you don't set up TLS. So, no, a new protocol doesn't save you from yourself.

What Actually Works: Configuration Discipline

So, what's the fix? It's boring, but it works: follow the standards. NIST SP 800-82 Rev. 3 is the guide to operational technology security, covering industrial control systems, SCADA, DCS, and PLCs (NIST SP 800-82 Rev. 3). It's not about which protocol; it's about how you configure your network segments, authentication, and monitoring.

Here's my no-nonsense checklist for any plant floor:

• Change default credentials on every device—PLCs, HMIs, gateways, servers. That's the first thing CISA warns about (CISA Industrial Control Systems).
• Segment your network. Don't put OT devices on the same subnet as IT. Use firewalls and VLANs.
• Disable unused protocols and services. If you don't need Modbus, turn it off.
• Keep a configuration baseline and audit it regularly. If a vendor changes a setting, you'll know.

And when you do roll out OPC UA or MQTT, make security mandatory: enable TLS, use strong authentication, and validate certificates. That's not optional.

Bottom Line

Stop chasing the protocol. The best move you can make is to fix your configuration first. Adopt new protocols if they bring business value, but don't expect them to be a silver bullet. The threat actors are exploiting your settings, not your protocol choice. So, go change those default passwords, segment your network, and audit your configurations. That's the war you need to win.

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