In the field of industrial automation, two technologies stand out due to their widespread adoption and specific capabilities: OPC Unified Architecture (OPC UA) and Message Queuing Telemetry Transport (MQTT). Both protocols play a decisive role in connecting OT devices and IT applications. However, based on their specific characteristics, OPC UA and MQTT address different requirements and use cases. This article therefore highlights the key differences between OPC UA and MQTT with regard to these characteristics.
OPC UA Fundamentals
OPC UA (Open Platform Communications Unified Architecture) is a communication standard developed by the OPC Foundation. It was designed for secure, reliable, and platform-independent data exchange in industrial automation systems. OPC UA supports complex data types and object models, enabling it to represent sophisticated industrial processes. Detailed information on OPC UA can be found here.
Key features of OPC UA:
- Information Modeling: Supports extensive information modeling, including structured data types, object-oriented models, and complex data structures.
- Integrated Security Mechanisms: Provides built-in security functions including authentication, authorization, encryption, and data integrity.
- Platform-Independent Communication: OPC UA supports both client/server and publish/subscribe communication models and can run on embedded devices as well as on large server infrastructures.
MQTT Fundamentals
MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol originally designed for networks with low bandwidth and high latency. This is particularly relevant in IoT scenarios (e.g. integration of external sensors). Developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Cirrus Link), MQTT is based on a publish/subscribe model. This makes the standard highly scalable and efficient when distributing information to a large number of subscribers. More information can be found here.
Key features of MQTT:
- Efficiency: Lightweight protocol with minimal data transmission, ideal for use cases with constrained networks or IoT devices.
- Decoupling: The publisher/subscriber model decouples devices and applications.
- Scalability: Easy to scale to support dozens to millions of devices and subscribers.
OPC UA vs. MQTT
OPC UA and MQTT are designed for different purposes and are therefore not directly comparable. These differences are reflected in the following characteristics.
1. Implementation Effort
With more than 1,200 pages, OPC UA features an extensive specification covering a wide range of functions for industrial automation. MQTT, by contrast, concentrates on a small set of core specifications (approx. 80 pages) geared toward efficiency and simplicity in IoT scenarios. These differences in scope and structure reflect the distinct design goals and fields of application — and translate directly into the implementation effort required for each standard.
OPC UA: The OPC UA specifications are split into multiple parts addressing different aspects of the OPC architecture. This structure shows that OPC UA is not merely a data transmission protocol but a comprehensive framework for communication in industrial systems, covering security, data modeling, state management, and historical data access. Much of this is optional — meaning that users decide which parts of the specification to implement. Due to the decades of growth and the breadth of the standard, real-world implementation is complex and resource-intensive. Not least for this reason, most systems only use a small subset of the standard.
MQTT: Unlike OPC UA, MQTT is a simple and lightweight protocol. It essentially consists of two documents totaling around 80 pages (MQTT 3.1.1 and the newer MQTT 5.0), focused mainly on the core elements of the protocol. As a result, integration is significantly easier and typically requires far fewer resources.
In summary: While implementing OPC UA is complex and resource-intensive, MQTT can be set up and put into operation within a matter of minutes.
2. Communication Model: OPC UA vs. MQTT
When it comes to communication models, OPC UA and MQTT differ fundamentally in their architecture. These differences have significant implications for their use and performance in industrial environments.
OPC UA Client/Server: At its core, OPC UA uses a client/server model. In this “one-to-one” topology, a client requests data from a server, and the server responds with the requested data (poll-response). While clients can interact with many servers simultaneously, servers can serve many clients. The client/server architecture is particularly suited to automation scenarios requiring direct, synchronous communication (e.g. closed-loop) between a limited number of systems.
MQTT minimizes bandwidth usage by moving from a conventional “poll-response” behavior (as used in the OPC UA client/server architecture) to an event-based “publish-subscribe” behavior. In this model, communication is decoupled by a broker that asynchronously routes messages between participants. Event-based means that a data consumer waits for data changes (rather than polling cyclically). This enables event-driven communication between devices and applications. These characteristics make the pub/sub architecture especially well suited to scaling scenarios involving dozens to millions of data producers and subscribers.
OPC UA Publisher/Subscriber (Pub/Sub), Part 14 of the specification, was first released in 2017 as an addition to the original client/server-based communication model. Pub/Sub specifically addresses the scalability limitations of the client/server model and was developed to meet the growing demand for efficient and lightweight communication mechanisms in IoT applications. It is important to note, however, that OPC UA Pub/Sub is based on standard pub/sub protocols such as MQTT or AMQP.
In summary: OPC UA Client/Server is suited for synchronous machine-to-machine communication, while MQTT Pub/Sub is optimized for efficient and lightweight communication between dozens to millions of IT/OT systems.
3. Security
Users of OPC UA and MQTT should consider security aspects at both the protocol and the network level.
Protocol Comparison: Security Mechanisms OPC UA vs. MQTT
While MQTT offers users flexibility in security implementation, OPC UA provides built-in security mechanisms covering a wide range of security aspects. Both approaches have their advantages but require corresponding expertise on the user side.
MQTT does not define its own security protocols. Instead, MQTT delegates security implementation to the TCP/IP layer. This means that users can choose between appropriate security models such as TLS/SSL or certificates. In addition, the MQTT standard provides no specific measures for user and application security. These gaps are often filled through additional security implementations at the application layer. While the ability to leverage established standards such as TLS/SSL generally simplifies the implementation of a secure MQTT architecture, additional effort at the application layer is still required.
OPC UA, in contrast, offers an integrated security solution covering user, application, and transport security. This OPC UA security architecture supports authentication, authorization, encryption, and data integrity. This can make the protocol a robust choice for industrial automation systems — but only when implemented and configured correctly. And this is precisely where problems often arise in practice. Due to the scope and complexity of OPC UA, weak security implementations are frequently encountered in real-world deployments.
In summary: MQTT relies on external security standards and requires additional implementations at the application layer. OPC UA, on the other hand, provides built-in mechanisms that are often complex to implement in practice.
Network Security: OPC UA vs. MQTT
An important security aspect is network security within the IT/OT architecture. Particular focus should be placed on measures to protect critical OT networks.
MQTT uses the pub/sub model, which means no open inbound ports into the critical OT network are required for communication. This holds true even for bidirectional data exchange between IT and OT, as all connections are initiated outbound from the internal OT client to the broker. As a result, the attack surface is significantly reduced and the risk of unauthorized access is lowered.
OPC UA Client/Server, in contrast, requires open inbound ports into the critical OT network, as the server passively waits for requests from external clients. These servers are typically deployed directly on the machine or as a separate gateway in the OT environment. This increases the attack surface and requires additional measures at the network architecture level to mitigate potential risks.
In summary: OPC UA Client/Server is suited for communication within a network, while MQTT Pub/Sub enables secure bidirectional communication across distributed IT/OT networks.
4. Interoperability: OPC UA vs. MQTT
Interoperability is a popular buzzword — and unfortunately, the term is often poorly understood by those who promote it. In fact, neither OPC UA nor MQTT in and of themselves guarantee true interoperability in practice. To illustrate this challenge, we refer to the “Data Access Model” by Matthew Parris (source), which defines the key layers (L0 to L5) for interaction between data sources and consumers in industrial environments. 
The following applies:
- Interoperability (“plug and play”) between systems is only ensured when all layers (L0–L5) match.
- Undefined layers within the MQTT or OPC UA specification favor flexibility at the cost of additional effort, as each implementation must be defined and integrated individually.
- Multiple options at a given layer favor flexibility at the cost of additional effort, as different implementations must be integrated individually.
Level 0 – Transport
This layer defines the fundamental transport mechanisms required for data transmission between systems. While MQTT uses TCP/IP or WebSockets for lightweight and efficient data transmission, OPC UA supports additional transport options. The choice of transport mechanism is left to the user, depending on requirements and technical constraints.
Level 1 – Protocol
This layer concerns the actual implementation and application of the communication protocol itself. MQTT relies on a simple publish/subscribe model that offers high flexibility and scalability but specifies little in terms of security features and error handling. OPC UA, by contrast, defines a more complex protocol that covers not only publish/subscribe but also session management, authentication, and encrypted communication.
Level 2 – Mappings
This layer defines the specific protocol mappings that determine how data is structured and transmitted within the chosen communication protocol. While MQTT leaves this to the user (e.g. conventions for topic namespaces), the OPC UA specification includes detailed information models that precisely define the structure of the data.
Level 3 – Encoding
This layer defines the data encoding required for transmission over the network. It includes the choice of data format, which determines both the efficiency of transmission and compatibility between different systems. While MQTT leaves data encoding to the user, OPC UA specifies encodings such as binary, XML, and JSON. The selection of the appropriate encoding is left to the user, depending on requirements and technical constraints.
Level 4 – Values
This layer defines the data types used for data transmission. A clear specification of data types is essential for the correct interpretation and use of data across different systems. While MQTT leaves this to the user, OPC UA specifies 60 so-called “base types” and allows users to define additional complex types.
Level 5 – Objects
This layer defines the data models and schemas — that is, how data is organized as objects, including their attributes and methods. This is particularly relevant for application logic. While MQTT leaves this to the user, OPC UA specifies these models through so-called Companion Specifications.
In summary: MQTT is not always MQTT, OPC UA is not always OPC UA
MQTT: Because the standard does not specify essential layers, implementation is left to the user. While this may initially appear far more flexible and simpler, it leads to individualized implementations. Two MQTT-capable systems therefore have to be integrated individually at these layers. In a SCADA environment, the newer “Sparkplug B” standard can help close these gaps. More information can be found here.
OPC UA: Although the standard was originally developed for cross-platform compatibility — to facilitate communication across different hardware systems — the high number of optional and alternative specifications combined with its accumulated complexity means that different parts and versions of the standard are typically implemented. Two OPC UA-capable systems are therefore rarely truly interoperable without significant integration effort.
5. Scalability: OPC UA vs. MQTT
Scalability is a decisive factor when selecting the right communication protocol — especially in environments where the number of connected devices is continuously growing.
OPC UA: Scaling OPC UA can be challenging in large industrial environments — particularly when a large number of devices and systems need to be connected for data exchange. The OPC UA client/server architecture requires point-to-point integration, which can result in a very large number of connections to implement and maintain. In addition, the complexity of the standard and its implementation significantly limit scalability. To improve scalability, OPC UA also supports a publish/subscribe model (Pub/Sub), leveraging brokers such as AMQP or MQTT to ensure efficient distribution of messages to many subscribers.
MQTT: MQTT, in contrast, was designed with lightness and efficiency in mind. It is ideal for scenarios where dozens to millions of devices must be supported efficiently. The MQTT publish/subscribe model minimizes the number of connections, reduces network traffic, and substantially lowers the resource load. Simplicity and efficiency make MQTT particularly well suited to scaling scenarios. However, due to the limited depth of the standard (see point 4), users must close existing gaps when scaling — for example by adopting additional standards (such as Sparkplug B) or by defining their own.
In summary: OPC UA scales only to a limited extent due to its client/server architecture, while MQTT is natively designed for high scalability thanks to its lightweight publish/subscribe model.
6. Reliability & Quality of Service
The differences in communication model directly affect how reliably data is delivered. OPC UA’s client/server architecture provides implicit delivery confirmation through its request-response logic, whereas a decoupled pub/sub model offers no such feedback by design. Publishers and subscribers do not know each other, responsibility for message delivery therefore shifts to the protocol itself.
MQTT — Three core mechanisms address this challenge:
- Quality of Service (QoS): MQTT defines three QoS levels (0: “At most once”, 1: “At least once”, 2: “Exactly once”) that can be set on a per-message basis. This allows delivery guarantees to be tuned to the specific use case (see details).
- Retained Messages: Since new subscribers in a pub/sub model cannot query the last known value, the broker stores it via the retained flag and delivers it immediately to every subscriber. In a Unified Namespace, this is essential for restoring consistent state after connection drops (see details).
- Last Will Testament (LWT): On connect, each client registers an LWT message that the broker automatically publishes if the connection drops unexpectedly. This enables device failure detection across distributed IT/OT architectures without additional heartbeat logic (see details).
OPC UA: OPC UA offers no comparable QoS levels. Due to its client/server model, reliability and state management are handled implicitly through the underlying session and subscription architecture. Parameters such as Publishing Interval, Keep-Alive Count, Lifetime Count, and Queue Size govern how the server captures, buffers, and forwards data changes to the client. Connection losses are detected via session timeouts, and historical values are accessed through the Historical Access service.
In summary: While OPC UA achieves reliability through its session-based client/server mechanics, MQTT provides dedicated mechanisms that specifically address the decoupling inherent to the pub/sub model. In a Unified Namespace, these are essential for consistent state, delivery guarantees, and failure detection across distributed systems.
Combining the Best of Both Worlds: OPC UA and MQTT in the UNS
The distinct strengths of OPC UA and MQTT are reflected in their typical fields of application. OPC UA is particularly well suited for structured and vendor-independent communication at the OT layer. Examples include field devices, PLCs, and control units. Here, OPC UA delivers significant value through its information modeling capabilities. However, the protocol reaches its limits in heterogeneous IT/OT architectures, particularly in terms of scalability and flexibility.
MQTT, in contrast, plays to its strengths as a lightweight, pub/sub-based protocol. It enables efficient and decoupled communication between a large number of data sources and sinks. Modern industrial architectures (e.g., the Unified Namespace) therefore rely on MQTT as a scalable distribution layer. It delivers data in real time to systems such as MES, ERP, or analytics platforms.
In practice, combining both approaches has proven particularly effective:
- OPC UA serves as a reliable data source, providing semantically enriched information from the OT layer.
- MQTT acts as the scalable transport and integration layer, making this information accessible within the UNS to all relevant IT and OT systems.
In summary: Within the context of the RAMI 4.0 model, OPC UA is primarily positioned at the field device (Level 0), control (Level 1), and station/supervisory (Level 2) layers, while MQTT orchestrates communication at the higher layers. This way, both technologies complement each other seamlessly within the UNS. More information can be found here.
Conclusion
Both OPC UA and MQTT play a decisive role in the ecosystem of industrial automation and OT/IT integration. However, neither OPC UA nor MQTT alone delivers truly interoperable system architectures in practice today. While the limited depth of MQTT was never designed for this, OPC UA’s interoperability issues arise in practice from the complexity of its specification.
The choice between OPC UA and MQTT largely depends on the specific requirements of each application. For complex industrial applications that require detailed data modeling and robust security, OPC UA is the preferred protocol. MQTT, by contrast, offers a solution for lightweight, efficient data transmission with dozens to millions of data producers and subscribers. Owing to these complementary strengths, the two technologies can be combined within the Unified Namespace (UNS) to ensure efficient and reliable data communication between OT and IT.
