Every few months, someone asks me the same question in a different shape: “Which industrial protocol is the most secure: Modbus, BACnet, MQTT, or OPC UA?”
The honest answer is that this is the wrong question. It’s a bit like asking which language is the most honest: English, Spanish, or French.
Language doesn’t determine honesty; the speaker does. Protocols don’t determine security; the system around them does.
I’ve spent years working with gas detection and safety systems on plant floors, and I’ve watched this misunderstanding cause real damage, not because engineers are careless, but because protocol documentation and vendor marketing quietly encourage the wrong mental model.
This article breaks down why that model fails, protocol by protocol, and what a security posture that actually holds up looks like.
The Core Problem: Protocols Were Built to Communicate, Not to Defend
Almost every protocol running on a factory floor today, Modbus, DNP3, BACnet, and even early MQTT, was designed in an era when the plant network was physically isolated.
Engineers assumed that if you had a cable plugged into the control network, you were supposed to be there.
Authentication, encryption, and integrity checking weren’t omitted by accident. They were omitted because the threat model didn’t include a remote attacker; it included a technician standing at a panel.
That assumption held up reasonably well until three things happened at once.
- IT and OT networks converged. Plant historians started talking to ERP systems, and firewalls between “the office” and “the floor” became porous by necessity.
- Remote access became routine. Vendors, integrators, and in-house engineers started troubleshooting PLCs from home, from other sites, and from the cloud.
- IIoT pushed protocols like MQTT into environments they weren’t originally hardened for, connecting sensors directly to public cloud brokers.
The protocols didn’t change. The environment around them did, and the environment is what determines whether a lack of built-in security actually matters.
Walking Through the Usual Suspects
Modbus: No Authentication, No Encryption, No Concept of “No”
Modbus RTU and Modbus TCP are still everywhere in industrial control, decades after their design.
The protocol has no authentication field, no encryption, and critically no way for a device to verify that a command actually came from the controller that’s supposed to be sending it. If a device can reach a Modbus slave on the network, it can write to its registers. There’s no built-in mechanism asking “should you be allowed to do this?”
This isn’t a flaw exactly. Modbus was never meant to answer that question. It just means the answer has to come from somewhere else: network segmentation, firewall rules, or an industrial protocol gateway that adds an authentication layer on top.
BACnet: Built for Buildings, Not Adversaries
BACnet’s security story is similar, though BACnet/SC (Secure Connect) has started addressing it with TLS-based encryption and certificate-based device authentication.
The catch is that BACnet/SC adoption is still uneven. Plenty of building automation systems running today still use plain BACnet/IP or MS/TP, where device discovery and control messages travel in the clear.
A BMS that looks modern on the surface can still be running on a transport layer with no real access control underneath it.
MQTT: Security Is Optional, Not Default
MQTT is often treated as “the secure IIoT protocol” because it supports TLS and username/password authentication.
The key word is supports. Nothing in the protocol forces a broker to require them. It’s extremely common to find MQTT brokers deployed with anonymous access enabled, port 1883 open instead of the encrypted 8883, and topic structures that leak plant data to anyone who connects and subscribes to #. The protocol gives you the tools; it doesn’t use them for you.
OPC UA: Strong on Paper, Fragile in Practice
OPC UA is the closest thing to a genuine exception here. It was designed with security in mind from the start, including message signing, encryption, and certificate-based authentication as first-class features. That’s a real architectural improvement over Modbus or classic BACnet.
But “designed with security features” isn’t the same as “secure by default.” OPC UA implementations frequently ship with security policies set to “None” out of the box for ease of setup, and that setting quietly stays in production because reconfiguring it means touching a running system nobody wants to touch.
A well-designed protocol configured insecurely offers no more protection than one that never had the option.
Comparison: What Each Protocol Actually Gives You
| Protocol | Native Authentication | Native Encryption | Common Real-World Gap |
|---|---|---|---|
| Modbus (RTU/TCP) | None | None | Any device on the segment can write to registers |
| BACnet/IP, MS/TP | None | None | Discovery and control traffic sent in clear text |
| BACnet/SC | Certificate-based | TLS | Adoption still limited; legacy devices unsupported |
| MQTT | Optional (username/password) | Optional (TLS) | Anonymous access and unencrypted ports left open |
| OPC UA | Certificate-based | Optional (policy-dependent) | Security policy often set to “None” during setup |
| DNP3 | Optional (Secure Authentication v5) | Optional | Secure auth is rarely enabled outside utilities |
The pattern across every row is the same: whatever protection exists is either absent by design or present but disabled by default. Nothing in this table protects a system on its own.
What Actually Secures an Industrial Network
If the protocol layer can’t be trusted to defend itself, security has to come from the layers around it. In practice, that means.
Network segmentation
Isolate OT networks from IT networks and the internet using an architecture like the Purdue model, with firewalls enforcing traffic rules between zones, not just VLANs that assume goodwill.
Protocol-aware firewalls and gateways
Deep packet inspection for Modbus, DNP3, and OPC UA can catch anomalous function codes or write commands that a generic firewall would pass straight through.
Enabling the security features that already exist
Turning on OPC UA’s signing and encryption, moving MQTT brokers to TLS on 8883 with authentication required, and migrating BACnet systems toward BACnet/SC where hardware allows.
Least-privilege remote access
Jump servers, VPNs scoped to specific assets, and time-limited vendor access instead of standing remote connections into the control network.
Asset visibility and monitoring
You can’t defend devices you don’t know exist. OT-specific monitoring tools that passively fingerprint protocol traffic catch unauthorized devices and unexpected commands that firewalls alone will miss.
Physical and procedural controls
Locked panels, controlled USB access on engineering workstations, and change-management processes for anything that touches PLC logic.
None of these live inside the protocol. They live in how the network, the devices, and the people around the protocol are configured and governed.
FAQ
Is OPC UA secure enough on its own?
OPC UA has real security architecture built in, but only when its security policy is actually configured to require signing and encryption. Left on default or “None” settings, it offers no more protection than Modbus.
Can I make Modbus secure without replacing it?
Yes, though not by changing the protocol itself. Modbus is commonly secured by wrapping it behind a protocol gateway or firewall that adds authentication and by strictly segmenting the network so only authorized controllers can reach Modbus devices at all.
Is MQTT safe for industrial IoT deployments?
MQTT can be deployed securely, but it requires deliberate configuration: TLS encryption, mandatory authentication, and access control lists on topics. An out-of-the-box MQTT broker is not secure by default.
What’s the single biggest security gap across industrial protocols?
Default configurations. Nearly every protocol on this list ships with its strongest security features disabled, and those defaults frequently make it into production unchanged.
Does network segmentation replace the need for protocol security?
No, the two are complementary. Segmentation limits who can reach a device; protocol-level authentication and encryption limit what happens once they can. Relying on only one leaves a real gap.
The Takeaway
Protocol choice matters for interoperability, performance, and how well a system fits your existing infrastructure.
It is not a security strategy. Modbus, BACnet, MQTT, and even OPC UA all depend on the network architecture, configuration discipline, and monitoring built around them.
Ask “Is this protocol secure?” and you’ll get a misleading answer either way. Ask, “Is this system secure?” and you’re asking the question that actually protects the plant.
