OPC UA vs. MQTT: a decision guide for connecting machines

OPC UA and MQTT compete far less often than the search term "OPC UA vs. MQTT" suggests. OPC UA describes what a measured value means and governs secure access to the machine; MQTT moves messages through a broker without caring what is inside them. In most plants the answer is therefore not "either / or" but: OPC UA at the asset, MQTT on the way up - and a gateway in between.

Why "OPC UA or MQTT" is usually the wrong question

OPC UA and MQTT solve different jobs along the data path, which is why the difference between OPC UA and MQTT is not a performance comparison. OPC UA (OPC Unified Architecture) defines how a server exposes its variables as an address space with data types, status codes and timestamps, how client and server identify themselves, and how messages are signed and encrypted. MQTT defines how a client hands a message to a broker and how the broker distributes it to subscribers. The content is of no interest to the protocol.

Whoever asks the question usually reveals the real decision. Maintenance wants machine states to show up reliably on a dashboard. IT management wants to know which ports are open, who runs the broker and how certificates are renewed. The machine builder wants one interface that ships identically to every customer. Behind "OPC UA or MQTT" sits a decision about data model, connection direction through the firewall and operating model - not about bytes per second. Both standards are actively maintained: OPC 10000 Part 2 and Part 14 have been available in release 1.05.06 since October 2025, and MQTT 5.0 has been an OASIS standard since March 2019.

What OPC UA delivers: information model, address space, security model

OPC UA ships context with every value. An OPC UA server exposes its data as nodes with unique NodeIds. When a client reads a variable it receives, per OPC 10000-4, a DataValue carrying not only the value but a StatusCode, a SourceTimestamp and a ServerTimestamp. The status code says whether the server was able to supply the value; if the status indicates an error, the specification says the value must be ignored. That is exactly the information a bare MQTT payload lacks unless somebody writes it in.

On top of that sit the companion specifications: industry-specific information models that define how, say, a machine tool structures its data. Two machines from different manufacturers using the same companion specification report operating state or piece count under the same node names. With MQTT that agreement has to be made outside the protocol - in the project, afresh with every supplier.

The security model in OPC 10000-2 is built on certificates. Every OPC UA application holds an application instance certificate that is exchanged when the SecureChannel is established; the recipient checks it against its trust list, a certificate store maintained by the administrator. The user authenticates separately through the session services. How messages are protected is set by the message security mode (Tab. 01). What that means for one specific controller family is covered in Reading S7 data: OPC UA server, Snap7 and optimised data blocks.

Part 14 also gives OPC UA a publish/subscribe model of its own: broker-less over UDP on the local network, or through an MQTT broker. The MQTT mapping (OPC 10000-14, section 7.3.4) defines addresses of the form mqtt:// (port 1883) and mqtts:// (port 8883), a topic structure with the prefix opcua, the UADP and JSON encodings, and the mapping onto MQTT QoS 0, 1 and 2. "OPC UA over MQTT" is therefore a specified route, not a contradiction.

What MQTT delivers: broker, topics, QoS and behaviour when the link drops

MQTT decouples sender and receiver completely. A client connects to the broker, publishes messages to a topic and subscribes to the topics it cares about; who else is reading, it does not know. Topics are hierarchical strings whose levels are separated by /. The OASIS standard prescribes no structure and explicitly lists as a feature a transport that is agnostic to the content of the payload - simultaneously the protocol's greatest strength and its biggest project risk.

Three mechanisms make MQTT robust on unstable links. First, retained messages: if the publisher sets the RETAIN flag, the broker must store the message and deliver it immediately to every later subscriber - a dashboard that has just restarted sees the last state without waiting. Second, the will message: at connection time the client deposits a message that the broker publishes if the connection drops without a regular DISCONNECT. With the Will Delay Interval from MQTT 5.0 the broker waits a defined period; if the client reconnects before it expires, the will message is never sent.

Third, session persistence: through the Session Expiry Interval the client sets how long the broker keeps subscriptions and unacknowledged QoS 1 and 2 messages after a drop; at 0 the session ends with the connection. This is why MQTT copes better over mobile networks and WAN links than a session-based client/server connection: the client only has to reach the broker, the broker buffers, and "machine unreachable" is itself a message.

The decision matrix: OPC UA vs. MQTT by scenario

OPC UA vs. MQTT comes down to a handful of criteria you can answer per plant. Tab. 03 sets the properties side by side, Tab. 04 translates them into the typical scenarios of connecting machines. Both compare OPC UA client/server with MQTT as a transport; OPC UA PubSub over MQTT sits between the two and follows in the section on the bridge.

Two statements are deliberately absent. "MQTT is faster" is not in the matrix, because latency depends on the broker, the QoS level, the network path and the sampling rate, not on the protocol's name. "OPC UA is more secure" is not there either, because a server running in mode None is less secure than an MQTT broker with TLS and client certificates. With both protocols, security is a configuration decision.

Sparkplug B: the structure bare MQTT does not bring with it

Sparkplug B closes the three gaps MQTT deliberately leaves open. Without a convention every integrator invents their own topics, packs numbers sometimes as text, sometimes as JSON, sometimes as binary, and nobody can tell whether a device is still alive or has merely stopped sending. After the third project a plant has three namespaces. The Eclipse Foundation publishes the Sparkplug specification for exactly this, currently version 3.0.0 from 2022.

• —Topic namespace: every client must use the structure namespace/group_id/message_type/edge_node_id/[device_id]; for Sparkplug B the namespace is spBv1.0.
• —Payload: messages are encoded with Google Protocol Buffers; metrics carry a name, a data type, a timestamp and a value.
• —Session state management: edge nodes announce themselves with NBIRTH and register NDEATH as the MQTT will message; host applications publish their state on spBv1.0/STATE/<host_id> with QoS 1 and the retain flag set.
• —Report by exception: after the birth message carrying all current values, new values are sent only on change; the specification does not mandate RBE for every case.

Sparkplug B (Eclipse 3.0):
  spBv1.0/<group_id>/<message_type>/<edge_node_id>/[<device_id>]
  Example: spBv1.0/hall2/DDATA/edge-line1/press04

OPC UA PubSub over MQTT (OPC 10000-14, 7.3.4.7):
  <Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/[<WriterGroup>[/<DataSetWriter>]]
  Example: opcua/json/data/press04/wg1/dsw1

Sparkplug comes at a price. The specification ties the edge node to fixed MQTT settings: Clean Start or Clean Session set to true, Session Expiry Interval 0, NBIRTH and NDATA at QoS 0 without retain. Reliability does not come from QoS 1 but from the state logic of birth and death. On top of that, only Sparkplug-aware tools read the protobuf payload directly. How Sparkplug groups grow into a plant-wide naming scheme along ISA-95 is described in Unified namespace: a reference architecture with an ISA-95 topic scheme.

The bridge in practice: OPC UA at the asset, MQTT for transport

The reference path in most plants runs PLC → OPC UA server → gateway → MQTT broker → time-series store. OPC UA sits where meaning is created: in or directly at the controller. MQTT sits where many consumers want to read many sources. The OPC UA to MQTT gateway - an industrial PC on the shop floor or an edge module in the control cabinet - is the machine's only OPC UA client and the only publisher of its topics.

1. 01

   Inventory the OPC UA servers

   Record endpoints, security policies, namespaces and the nodes you actually need - do not subscribe to the entire address space.

2. 02

   Set up the gateway as an OPC UA client

   Generate its own application instance certificate, add it to the server's trust list, use mode SignAndEncrypt and subscriptions rather than polling.

3. 03

   Agree the payload contract

   What travels with the DataValue: value, StatusCode, SourceTimestamp, unit, NodeId. Sparkplug B, OPC UA PubSub JSON or your own JSON - decide before the first topic exists.

4. 04

   Run the broker with TLS and permissions

   Port 8883, certificates or accounts per gateway, write rights per topic prefix, a will message for every gateway.

5. 05

   Connect storage and consumers

   One subscriber writes to the time-series database, others read for dashboards or alerting. No consumer talks to the controller directly.

Whatever the gateway does not deliberately carry over is lost in translation. Three things regularly fall by the wayside: the status code - a value with a Bad status lands in the database as an ordinary number; the timestamp source - the broker only knows the arrival time, and once buffered values are re-sent after a network outage every curve is wrong; and the semantics - ns=3;s=Press04.Motor.Temp with a unit becomes a topic called temp1. A payload that carries these fields costs a few bytes and saves the analysis.

{
  "nodeId": "ns=3;s=Press04.Motor.Temp",
  "value": 63.4,
  "unit": "°C",
  "statusCode": "Good",
  "sourceTimestamp": "2026-09-21T06:12:03.418Z",
  "serverTimestamp": "2026-09-21T06:12:03.421Z",
  "source": "opc.tcp://press04:4840"
}

Network, firewall and security: what IT will actually ask

IT's first question is not "which protocol" but "which direction". With OPC UA client/server the client opens the connection to the server on the machine - the rule points into the OT network. With MQTT all clients open outbound to the broker; if it sits in a DMZ or with a hosting provider, the OT network needs no inbound rule at all. In many plants that is precisely the argument for the bridge: the gateway stands in the OT segment, speaks OPC UA locally and MQTT outbound.

The second question concerns certificates - on both sides. OPC UA requires an application instance certificate per application and a maintained trust list per server; if a certificate expires or the hostname does not match, the connection fails with a rarely unambiguous error message. Narrowing that down means checking three things in order: the endpoint URL the client is actually using, the security policy the server offers, and whether the client certificate sits in the server's trust list. The same applies at the broker for TLS server and client certificates. Without a renewal process, data acquisition stops on the first expiry date.

The third question is segmentation: a shared broker is a zone transition and needs a zone of its own, permissions per topic prefix and write rights for gateways only. Commands heading towards the controller - a Sparkplug NCMD or an OPC UA write - should be checked by the gateway against an allow list rather than passed through unfiltered.

Checklist before you decide

Ten questions settle the protocol before the first tool is installed - after that, OPC UA vs. MQTT follows from Tab. 04.

Conclusion: OPC UA at the asset, MQTT for the way up

OPC UA vs. MQTT is not an either/or question but a question of layer. OPC UA belongs where meaning is created and access is governed: at the machine, with certificates and in mode SignAndEncrypt. MQTT belongs where many consumers read in a decoupled way: through the broker, with TLS and a convention such as Sparkplug B or OPC UA PubSub. The bridge between them is not a compromise but the architecture that holds up in most plants.

The next step is not a tool purchase but the checklist above - above all the questions about naming conventions, certificate renewal and network outages. If you would like to see what such a data path looks like in practice, from the OPC UA server through to the dashboard, the Solutions pages show examples that ralwo builds for production operations.