Three protocols answering three different questions
The comparison gets botched when a candidate lines the three up as competing options and ranks them by modernity. They are not alternatives on one axis. Modbus answers "how do I read a number out of this device". OPC UA answers "how does a machine describe itself so a client can find that number without a manual". MQTT answers "how do I move messages over an unreliable link without either end knowing about the other". You can and often do use two of them in one path: an edge gateway that speaks Modbus downwards and publishes over MQTT upwards is an entirely ordinary design.
Modbus: the lowest common denominator
Modbus is a request/response protocol from the late 1970s, still everywhere because it always works. One client (historically called the master) addresses a server device, either over serial as Modbus RTU with a CRC, or over TCP as Modbus TCP on port 502. The data model is four flat spaces of numbered items: coils and discrete inputs, which are single bits, and holding registers and input registers, which are 16 bits each. Function codes cover reading and writing those spaces and little else.
What Modbus does not carry is meaning. A register is sixteen bits; nothing in the protocol says it holds a temperature, in what unit, scaled by what factor, or whether it is valid right now. That knowledge lives in a vendor register map, frequently a spreadsheet, and the failure mode follows directly: a value that is silently wrong rather than an error. Anything wider than sixteen bits is split across consecutive registers, and while the byte order within a register is big-endian, the order of the two registers making up a 32-bit value is a vendor choice. Read a float with the words swapped and you get a plausible-looking number that is nonsense, with no exception to tell you.
Security is the other half of the story: there is none. No authentication, no encryption, no integrity beyond a link-level checksum meant for detecting line noise. Whoever can reach port 502 can write a register, and writing a register can move an actuator. Modbus is a protocol you use inside a protected segment, never one you expose.
OPC UA, standardised as IEC 62541, is the modern interoperability layer, and its defining feature is that it carries a model rather than only values. A server exposes an address space of nodes: typed, named, browsable objects with attributes, references and metadata, so a client can discover that a machine has a motor which has a temperature with an engineering unit, without a register map. Each value comes with a source timestamp and a status code, which is how you distinguish a good reading from a stale or failed one — the thing Modbus cannot express.
Reading works either as client/server or as publish/subscribe. In client/server, a client creates a session, then a subscription containing monitored items, each with a sampling interval and optionally a deadband, and the server pushes changes at the publishing interval — a genuine improvement over polling, because sampling happens server-side at a rate the server can sustain. Part 14 of the standard adds PubSub, where publishers emit datasets without knowing their subscribers.
Security is layered and worth describing as layers, because candidates blur them. Applications authenticate each other with X.509 certificates and establish a secure channel that can be set to sign, or sign and encrypt, under a named security policy. Separately, the user presents a token: anonymous, username and password, or a certificate. The transport is usually the binary opc.tcp protocol, conventionally on port 4840.
The failure modes are mostly operational rather than protocol-level. Certificate trust is the classic: two applications each rejecting the other's self-signed certificate, requiring someone to move files into trust stores on both machines, which is exactly the task that gets solved at three in the morning by turning security off. Deployments left on a no-security policy with anonymous access are common enough that "it uses OPC UA" tells you nothing about whether it is secured. Servers also enforce limits on sessions, subscriptions and monitored items, so a client that subscribes to everything gets refused or degrades the server.
MQTT: transport, and nothing about meaning
MQTT is a lightweight publish/subscribe transport standardised at OASIS, with 3.1.1 and 5.0 both in wide use. Clients connect to a broker, publish to hierarchical topics, and subscribe with + and # wildcards. It gives you three quality-of-service levels, retained messages so a new subscriber immediately sees the last value on a topic, and a last will and testament the broker publishes if a client disconnects ungracefully — which is how you detect a dead device without polling it.
Security here is TLS for the transport plus a client identity, either username and password or a client certificate. Authorisation is not in the specification: which topics a client may publish or subscribe to is enforced by broker-specific access control lists. That is the point candidates miss, because it means an MQTT deployment's real security posture is a configuration file in the broker, not a property of the protocol.
Because MQTT is indifferent to payloads, industrial users add a convention on top, most commonly Sparkplug, now an Eclipse specification. Sparkplug fixes the topic namespace, defines birth and death certificates so a subscriber learns a node's full tag list on connect rather than guessing, registers the death certificate as the MQTT will message, and defines a STATE topic through which a primary host application announces whether it is online. Without something in that role, every integration invents its own topic scheme and payload format.
MQTT's failure modes cluster around the broker. It is a single point of failure and a single point of load, and a wildcard subscriber on a busy hierarchy can be the load. Quality of service is defined per hop between a client and the broker, so QoS 2 across a bridge to a second broker is not an end-to-end exactly-once guarantee, and QoS 1 permits duplicates by design. Retained messages go stale silently and will serve a new subscriber a value from before the outage. And a persistent session for a device that stays offline accumulates a queue somebody has to bound.
| Modbus | OPC UA | MQTT |
|---|
| Carries data types and names | No | Yes | No, payload is opaque |
| Value quality and timestamp | No | Yes | Only if your payload adds it |
| Authentication | None | Certificates plus a user token | TLS identity or credentials |
| Authorisation | None | Server-side, per node | Broker ACLs, outside the spec |
| Typical use | Reading a device in a protected segment | Machine-to-system integration | Getting data out over a poor link |
What the comparison is really testing
The distinction that separates a strong answer is refusing the security ranking. "OPC UA is secure, Modbus is not, MQTT is somewhere between" is what everybody says, and it is shallow in a specific way: it treats security as a scalar property of a protocol rather than as separable concerns. MQTT with TLS gives you a confidential channel to a broker and tells you nothing about whether the publisher is entitled to speak for that tag, or what the tag means. OPC UA gives you identity, authorisation and value quality, and is routinely deployed with the first two switched off.
The protocol determines what you can verify; the deployment determines what you do verify. Say what each one makes expressible, then say what still has to be established outside it.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).