In the field of industrial automation, two technologies stand out due to their widespread use and specific capabilities: OPC Unified Architecture (OPC UA) and Message Queuing Telemetry Transport (MQTT). Both protocols play a crucial role in today’s IT/OT integration. However, OPC UA and MQTT serve different requirements and use-cases. Therefore, this article highlights the key differences between OPC UA vs. MQTT in terms of their specific characteristics.
OPC UA Fundamentals
OPC UA (Open Platform Communications Unified Architecture) is a communication standard developed by the OPC Foundation. This standard was designed for secure, reliable and platform-independent data exchange in industrial automation systems. Unlike simple data transfer protocols, OPC UA supports complex data types and object models, making it well-suited for advanced industrial processes. Detailed information on OPC UA can be found here.
Key features of OPC UA:
- Information modeling: Supports structured data types, object-oriented models, and complex data structures.
- Integrated security mechanisms: Provides built-in security features, including authentication, authorization, encryption and data integrity.
- Platform independence: Operates across embedded devices and server infrastructures, supporting both client-server and publish-subscribe communication models.
MQTT Fundamentals
MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol originally developed by IBM for networks with limited bandwidth and high latency. This is particularly relevant in IoT scenarios (e.g. integration of external sensors). Based on a publish/subscribe model, MQTT provides efficient and scalable data distribution to large numbers of subscribers. You can find more information here.
Key features of MQTT:
- Efficiency: Lightweight protocol with minimal overhead, ideal for constrained networks and devices.
- Decoupling: Publisher/subscriber model enables loose coupling between devices and applications.
- Scalability: Easily scales to support thousands to millions of devices and subscribers.
OPC UA vs. MQTT
OPC UA and MQTT are built for different industrial applications and target groups, making them not directly comparable. Their differences become clear in the following characteristics.
1. Integration Effort
OPC UA spans more than 1,200 pages of specifications, covering a broad set of functions for industrial automation. In contrast, MQTT is defined in just around 80 pages, focusing on core features optimized for efficiency and simplicity in IoT scenarios. These differences in scope and complexity reflect their distinct design goals and use cases — and directly impact the integration effort required for each standard.
OPC UA: The OPC UA specifications are divided into multiple parts, each addressing different aspects of the architecture. This illustrates that OPC UA is not merely a data transfer protocol, but a comprehensive communication framework for industrial systems. This includes security, data modeling, state management and historical data access. Many of these features are optional, leaving it up to the implementer to decide which parts to adopt. Moreover, the breadth and maturity of the standard, developed over decades, make practical implementation complex and resource-intensive. As a result, most systems use only a fraction of the specification.
MQTT: MQTT: In contrast, MQTT is a lightweight and streamlined protocol, defined in just two specification documents of about 80 pages (MQTT 3 and MQTT 5). These focus primarily on the protocol’s core elements, making integration significantly simpler and less resource-demanding compared to OPC UA.
In summary: While implementing OPC UA is complex and time-consuming, MQTT can be set up and put into operation in just a few minutes.
2. Communication Model: OPC UA vs. MQTT
OPC UA and MQTT differ fundamentally in their communication architectures. These differences have a significant impact on their application and performance in industrial environments.
OPC UA Client/Server relies on a traditional client-server model. In this one-to-one topology, a client requests data and the server responds (poll-response). While clients can connect to multiple servers, servers can serve multiple clients. This architecture is best suited for direct, synchronous communication in automation scenarios such as closed-loop or command-and-control between a limited number of systems.
MQTT takes a different approach by replacing the poll-response behavior with an event-driven publish-subscribe model. Here, a broker decouples communication and distributes messages asynchronously. Instead of polling, data consumers simply wait for updates when values change (instead of requesting them cyclically), enabling event-driven communication across devices and applications. This makes MQTT particularly effective in scenarios involving dozens to millions of data producers and subscribers.
OPC UA Pub/Sub (introduced in Part 14 of the specification in 2017) extends OPC UA beyond the client-server model to improve scalability. It was designed to meet the demand for lightweight communication in IoT scenarios but is itself built on standard pub/sub protocols such as MQTT or AMQP.
In summary: OPC UA Client/Server is suitable for synchronous machine-to-machine communication, while MQTT Pub/Sub is optimized for efficient and lightweight communication between dozens to thousands of IT/OT systems.
3. Security
Developers and users of OPC UA and MQTT should consider security aspects at both the protocol and network levels.
Protocol Comparison: Security Mechanisms OPC UA vs. MQTT
While MQTT provides flexibility in how security is implemented, OPC UA includes integrated security mechanisms that cover a wide range of aspects. Both approaches have their strengths but require sufficient expertise to implement effectively.
MQTT does not define its own security protocols. Instead, MQTT leaves the implementation of security to the TCP/IP level. This means that the user can choose between suitable security models such as TLS/SSL or certificates. In addition, the MQTT standard does not offer any specific measures for user and application security, which is often compensated by additional security implementations at application level. While the possibility of using recognized standards such as TLS/SSL makes the implementation easier in principle, additional effort is still required at application level.
OPC UA, on the other hand, provides a built-in security framework that covers user, application, and transport layers. It supports authentication, authorization, encryption, and data integrity, making it a potentially robust choice for industrial automation. However, this strength comes with complexity: if not carefully implemented and configured, OPC UA systems often end up with weak or inconsistent security in practice.
In summary: MQTT relies on external security standards and requires additional implementations at the application level. OPC UA, on the other hand, offers integrated mechanisms, but these are complex to implement in practice.
Network Security: OPC UA vs. MQTT
A critical aspect of security in IT/OT architectures is the protection of OT networks. The way OPC UA and MQTT handle network connections has a direct impact on the attack surface.
MQTT Pub/Sub does not required inbound ports to be opened into the OT network. Even for bidirectional data exchange between IT and OT, all connections are initiated outbound from the OT client to the broker. This design minimizes exposure, significantly reduces the attack surface, and lowers the risk of unauthorized access.
OPC UA Client/Server requires open inbound ports into the OT network, since the server passively waits for external client requests. Whether installed directly on a machine or on a gateway, this increases the potential attack surface and demands additional network security measures (e.g., firewalls, DMZs, or proxies) to mitigate risks.
In summary: OPC UA Client/Server is best suited for internal network communication, whereas MQTT Pub/Sub enables secure, bidirectional communication across distributed IT/OT networks without exposing critical OT infrastructure.
4. Interoperability: OPC UA vs. MQTT
Interoperability is a popular buzzword. And unfortunately, the term is often not well understood by those who promote it. In reality, neither OPC UA nor MQTT alone ensure true interoperability in practice. To illustrate this challenge, Matthew Parris’ Data Access Model (source) defines six levels of interaction (L0–L5) between data sources and consumers in industrial environments.
Three guiding principles apply:
- True “plug-and-play” interoperability between systems is only possible when all levels (L0–L5) are consistently aligned.
- Undefined levels provide flexibility but increase integration effort, as every implementation must be defined and integrated individually.
- Multiple options on one level favor flexibility at the expense of higher integration effort, as different implementations have to be integrated individually.
Level 0 – Transport
This level defines the basic transport mechanisms for data exchange between systems. MQTT relies on TCP/IP or WebSockets for simple and efficient transfer, whereas OPC UA supports additional transport options. The selection of the transport mechanism is left to the user, depending on specific needs and technical requirements.
Level 1 – Protocol
This level defines the specific implementation of the communication protocol. MQTT uses a simple publish/subscribe model that provides high flexibility and scalability but specifies little regarding security or error handling. OPC UA, by contrast, defines a more complex protocol that includes not only publish/subscribe but also session management, authentication, and encrypted communication.
Level 2 – Mappings
This level defines the protocol mappings that determine how data is structured and transmitted. MQTT leaves this open to the user (e.g., topic namespace conventions), whereas OPC UA provides detailed information models that precisely specify data structures.
Level 3 – Encoding
This level defines the data encoding required for network transmission. This includes the choice of format, which affects both efficiency and cross-system compatibility. MQTT leaves encoding decisions entirely to the user, whereas OPC UA specifies options such as binary, XML, and JSON. The final choice of encoding depends on the user’s needs and technical requirements.
Level 4 – Values
This level defines the data types used for transfer. Clear type specifications are essential for correct interpretation and usage across systems. MQTT leaves data typing to the user, whereas OPC UA defines 60 standardized “base types” and allows extensions with custom complex types.
Level 5 – Objects
This level defines data models and schemas, i.e. 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 provides standardized models through companion specifications.
To summarize: MQTT is not equal to MQTT , OPC UA is not equal to OPC UA
OPC UA: The standard was originally developed for cross-platform compatibility to facilitate communication between systems. However, the numerous optional and alternative specifications, combined with the complexity of OPC UA, mean that developers and users typically implement different subsets or versions of the standard. As a result, two OPC UA-enabled systems are often only truly interoperable with a great deal of luck.
MQTT: Because the standard leaves many levels undefined, implementation is left to the user. This can seem flexible and simple at first, but it results in custom implementations. As a consequence, two MQTT-enabled systems often require manual integration at these levels. In SCADA environments, the Sparkplug B standard helps address this gap. You can find more information here.
5. Scalability: OPC UA vs. MQTT
Scalability is a crucial aspect when choosing the right communication protocol. This is particularly true in environments in which the number of connected devices is constantly increasing.
OPC UA: Scaling OPC UA in large industrial environments can be challenging. The traditional client/server model requires point-to-point connections, which quickly become complex as the number of devices increases. Combined with the breadth and complexity of the standard, this significantly limits scalability. To address this, Part 14 of the specification introduced a publish/subscribe model that leverages brokers such as AMQP or MQTT for more efficient message distribution.
MQTT: By design, MQTT is lightweight and efficient, making it ideal for scenarios with thousands to millions of connected devices. Its publish/subscribe architecture minimizes network traffic and resource load, enabling seamless scaling. However, because the MQTT standard leaves many aspects undefined (see interoperability), users must fill these gaps during large-scale deployments. This includes the adoption of additional standards (e.g. Sparkplug B) or the definition of their own standards.
Conclusion
OPC UA and MQTT both play a key role in industrial automation and OT/IT integration. Yet, neither protocol alone delivers fully interoperable system architectures today. With MQTT, this is due to its intentionally limited scope, while OPC UA often suffers from interoperability issues caused by its complexity and breadth. The choice between them ultimately depends on the application’s requirements. OPC UA is best suited for complex industrial use cases that demand detailed data modeling and robust, built-in security (e.g., machine to machine communication). In contrary, MQTT excels in scenarios requiring lightweight, scalable, and efficient data exchange across tens to millions of devices (e.g., IT/OT integration).
In practice, modern industrial architectures increasingly leverage the strengths of both. Within the Unified Namespace (UNS), OPC UA acts as a source of structured, semantically rich data from the OT layer, while MQTT provides the scalable communication backbone that distributes this data reliably across IT and OT systems.
