OPC UA and MQTT solve different problems. OPC UA provides rich, semantic, secure machine-to-machine communication: a typed information model, built-in security, and the vocabulary to describe what data means, not just what it is. MQTT is a lightweight publish-subscribe transport for telemetry at scale: minimal overhead, broker-based fan-out, and suitability for millions of devices on constrained or unreliable networks. The single biggest difference is semantic modeling versus lightweight distribution. This guide is written for automation engineers and IIoT architects making the real decision: which protocol to place where in an industrial architecture, and when to use both.
Key Takeaways
Inside OT zones, controlling machines and enforcing semantic interoperability: OPC UA. For cloud telemetry, remote monitoring, and distributing data at scale: MQTT. For most real production architectures: both, placed where each fits.
OPC UA is designed for secure communication between industrial machines and provides strong semantic interoperability. MQTT is preferred for remote monitoring and cloud data analytics where lightweight transport and massive scalability matter more than rich data semantics. The decisive factor in the choice is whether the consuming system needs to understand what the data means (OPC UA's strength) or just needs to receive it efficiently at scale (MQTT's strength).
For automation engineers integrating machines from different vendors on a plant floor, OPC UA's structured data types and vendor-interoperable information models justify the implementation complexity. For IIoT architects building a Unified Namespace that distributes data from hundreds of OT sources to dozens of IT consumers, MQTT's broker-based fan-out and low overhead are the right foundation.
OPC UA (Open Platform Communications Unified Architecture) is an open-standard, platform-independent protocol for secure, reliable, and semantically rich machine-to-machine communication in industrial automation. Published in 2008 as a successor to the original OPC specification (which was Windows-only and COM-based), OPC UA was designed to address the limitations of its predecessor while extending the standard's scope to cover not just data access but the full richness of an information model that machines can share without pre-agreed interpretation.
Three core OPC UA strengths for integration:
1. Semantic information modeling. OPC UA supports complex data types and object models, providing structured and hierarchical data with metadata that describes what each data item represents. An OPC UA server does not just publish a floating-point number; it publishes a Temperature node with a defined engineering unit, a range, a timestamp, and a structured relationship to the physical component it measures. This information modeling allows a consuming client to understand data without prior out-of-band agreement, which is the foundation of true interoperability among different vendor systems.
2. Integrated security. OPC UA integrates certificate-based authentication and encryption at the message level, supporting multiple security policies for user, application, and transport security. An OPC UA client authenticates to an OPC UA server using X.509 certificates; messages are optionally signed and encrypted between specific client-server pairs. This security is built into the protocol, not added on top of it.
3. Client/server architecture with sessions and subscriptions. OPC UA uses a client/server model where an OPC UA client connects to an OPC UA server, browses its address space, reads or writes attributes, and subscribes to monitored items that send data changes when values change by a configured amount or interval. The server manages the session, ensuring delivery confirmation and handling reconnection. OPC UA also supports a PubSub model extension, published in later specification versions, to address scalability limitations of the base client/server architecture in large-scale deployments.
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol designed in 1999 for low-bandwidth, high-latency, unreliable networks, originally for monitoring oil pipelines over satellite connections. Its design priorities, minimal overhead and reliable delivery on unreliable links, make it ideal for Industrial IoT deployments where thousands or millions of devices need to send telemetry to a central system with minimal resource consumption.
Three core MQTT strengths for telemetry:
1. Extreme lightweight. MQTT has a fixed header of only 2 bytes, minimizing overhead for devices with constrained memory and processing. A complete MQTT implementation can run on a microcontroller with kilobytes of RAM. The specification itself is approximately 80 pages (MQTT 3.1.1, OASIS, 2014), compared to OPC UA's 1,200+ pages of specifications, and an MQTT client can be set up and publishing in minutes.
2. Publish-subscribe fan-out. MQTT employs a publish-subscribe model mediated by an MQTT broker. A device publishes MQTT messages to a topic; the broker distributes those messages to all subscribers to that topic, decoupling publishers from subscribers. This broker-based architecture means adding a new consumer of a data stream requires only a new subscription, not a new connection to the source device, enabling fan-out to many consumers without additional load on the originating device.
3. Flexible payload, QoS levels, and LWT. MQTT transmits raw data formats including JSON and plain text, placing no requirement on payload schema, which makes it adaptable to any data format without protocol changes. Three QoS levels (0: at most once, 1: at least once, 2: exactly once) provide configurable delivery guarantees for different use cases. The LWT (Last Will and Testament) message mechanism allows a device to pre-register a message the broker will publish if the device disconnects unexpectedly, enabling lightweight status monitoring without polling.
Compact comparison table
One-line takeaway. OPC UA is suitable for internal factory automation and vertical integration where semantics and control matter; MQTT is often used for cloud telemetry and remote monitoring where scale and simplicity matter.
The right choice between OPC UA and MQTT depends on five factors: communication model, state management, data types, security implementation, and scalability. The sections below cover each with the practical consequences for an industrial architecture.
OPC UA uses a client/server model as its primary communication architecture. An OPC UA client initiates a connection to an OPC UA server, establishes a session, and then issues requests (read, write, subscribe) to which the server responds. This synchronous, request-response pattern is well suited to control interactions where the initiating system needs confirmation that a command was received and executed. Messages are published in response to a client subscription or a direct request.
MQTT employs a publish-subscribe model mediated by a central MQTT broker. A publisher sends MQTT messages to a topic string on the broker without knowing or caring which clients are subscribed. The broker distributes those messages to all current subscribers. No direct connection between publisher and subscriber is required or maintained. This decoupled, asynchronous communication model is ideal for telemetry, where a sensor just needs to report its current value to whoever is interested, without waiting for a response.
Practical consequence. For a PLC that needs to execute a setpoint change and confirm the result, OPC UA's client/server model maps directly onto that interaction. For a temperature sensor that needs to report its current value to a historian, a dashboard, and an analytics platform simultaneously, MQTT's publish-subscribe fan-out eliminates the need for the sensor to maintain separate connections to each consumer.
OPC UA provides historical data access services as part of its specification, meaning a client can query an OPC UA server for the historical values of a variable over a time range, with the server managing both the current and historical state of the data it exposes. The server-side session and subscription model means the server tracks what each client has seen, and can queue data changes for delivery when a client reconnects.
MQTT retains the last message per topic for subscribers who connect after publication, but does not define a historical data access mechanism. If a subscriber is offline when messages are published and QoS 0 is used, those messages are lost. QoS 1 and 2 provide at-least-once and exactly-once delivery guarantees respectively, but only for the current publication, not for a historical query. State management in an MQTT architecture is the responsibility of the consuming system (a historian, a data lake, or the broker's configured persistence layer), not the protocol itself.
Practical consequence. For a system that needs to query "what was the value of this variable at 14:32:07 three days ago," OPC UA's historical access services provide that capability natively. For a system that only needs the current value and can tolerate loss if a subscriber is temporarily offline, MQTT's retained messages and QoS levels cover the requirement at far lower implementation cost.
OPC UA precisely defines data types through its information modeling layer. An OPC UA address space contains nodes of defined types (Variables, Objects, Methods, Views) with typed attributes (the Value attribute of a Variable has a defined DataType from OPC UA's type system) and semantic relationships (a folder node contains child nodes, a variable has an engineering unit, a measurement has a valid range). This structured data types system means a consumer receiving data from an OPC UA server can determine the data encoding, units, and valid range from the server itself, without relying on external documentation.
MQTT transmits raw data formats: the payload of an MQTT message is an uninterpreted byte array. By convention, payloads are often JSON or another self-describing format, but MQTT itself does not enforce or define data encoding, metadata, or type information. Two different MQTT publishers on the same broker may publish to the same topic structure using entirely different payload formats, and a subscriber must know which format to expect through some out-of-band mechanism.
Practical consequence. For machine integration between systems from different vendors who have agreed on OPC UA companion specifications for their domain (there are OPC UA companions for robotics, CNC machine tools, brewing, and many other domains), OPC UA's information modeling eliminates the integration work of negotiating data schemas bilaterally. For internal telemetry where the publisher and consumer are controlled by the same team and can agree on a JSON schema out of band, MQTT's flexibility is a feature, not a gap.
OPC UA defines an address space with semantic naming: every node in an OPC UA server has a NodeId (a structured identifier consisting of a namespace index and an identifier) and a BrowseName (a human-readable, qualified name). The address space is hierarchical and self-describing: a client can browse from the root of the address space to discover all available data and its structure, without prior knowledge of what the server exposes.
MQTT topic namespaces are flexible, flat string hierarchies separated by forward slashes. Topics like factory/line1/machine3/temperature are conventions that teams define for their own use; MQTT itself imposes no structure, no type information, and no browsability beyond listing all topics (which most brokers support but is not part of the core specification). Topic names are shared conventions that must be documented and enforced operationally.
Practical consequence. OPC UA's address space is self-describing: a new integration can browse the server to discover what it exposes. MQTT's topic names require documentation that must be maintained alongside the integration. For a Unified Namespace, MQTT's flexibility is an advantage (any publisher can define its own topic structure), but Sparkplug B (covered below) adds a structured convention on top of MQTT to recover some of the discoverability that bare MQTT lacks.
OPC UA integrates certificate-based authentication and encryption as core protocol features, not optional extensions. A production OPC UA deployment uses X.509 certificates to authenticate both the application (which OPC UA server or client is connecting) and optionally the user. Messages between OPC UA client and server are optionally signed (ensuring integrity) and encrypted (ensuring confidentiality). The protocol supports multiple security policies of increasing strength. Security implementation is defined in the specification and must be supported by any compliant OPC UA implementation.
MQTT relies on external standards like TLS for transport security and does not define its own security protocols. Authentication in MQTT is typically username/password passed in the CONNECT packet (transmitted in plaintext unless TLS is active) or client certificates if the broker supports TLS mutual authentication. The level of security in an MQTT deployment depends on the broker configuration, which varies widely across deployments. MQTT does not define message-level signing or encryption between specific publisher-subscriber pairs.
OPC UA provides implicit delivery confirmation through its request-response model: a client that sends a write request receives an acknowledgment from the server. Subscriptions use a session-management mechanism that queues monitored items for delivery when communication is interrupted and delivers them when the session resumes.
MQTT offers QoS 0 (at most once, no delivery guarantee), QoS 1 (at least once, with broker acknowledgment), and QoS 2 (exactly once, with a four-part handshake). For session management, MQTT supports persistent sessions that queue QoS 1 and 2 messages for offline subscribers. The publish-subscribe model does not provide delivery feedback from subscriber to publisher; the publisher knows the broker received the message (for QoS 1+), but not whether any subscriber processed it.
OPC UA's built-in PKI and message-level security are more complete and standardized by specification. MQTT's security is more variable, dependent on broker configuration and external TLS infrastructure, but is adequate for most industrial telemetry use cases when properly configured.
MQTT scales to millions of values and publishers: the publish-subscribe broker architecture inherently handles fan-out from one publisher to many subscribers without additional load on the publisher, and MQTT broker implementations (Mosquitto, EMQX, HiveMQ) are designed to handle millions of concurrent connections. A single central MQTT broker cluster can aggregate telemetry from an entire industrial estate and distribute it to enterprise consumers, reducing network traffic significantly compared to point-to-point polling.
OPC UA's client/server architecture limits scalability in large environments: each OPC UA client must maintain a session with each OPC UA server it subscribes to. A plant with 500 OPC UA servers and 50 analytics consumers would require up to 25,000 sessions if each consumer connected directly to each server. OPC UA aggregation servers (which aggregate multiple downstream OPC UA servers and expose a unified namespace to upstream clients) address this at additional architectural cost. OPC UA supports a PubSub model extension (specified in OPC UA Part 14) that maps OPC UA data to MQTT topics or UDP multicast, improving scalability by decoupling publishers and subscribers in the same way MQTT's native architecture does.
Practical consequence. For a Unified Namespace serving a large industrial estate, MQTT's inherent scalability and broker-based architecture make it the natural distribution backbone. OPC UA, with its PubSub extension or via edge gateways that translate OPC UA to MQTT, feeds the UNS at the edge, where its semantic richness and built-in security are most valuable.
Sparkplug B (Eclipse Sparkplug, maintained by the Eclipse Foundation) is a structured MQTT payload specification that adds to bare MQTT what MQTT deliberately omits: a defined topic namespace, a typed payload format (Protocol Buffers), session management, and bidirectional communication conventions for SCADA-style applications.
MQTT Sparkplug defines how SCADA hosts and edge nodes should structure their MQTT topics and payloads to ensure interoperability across different systems using the same broker. It defines birth certificates (announcing a device's availability and its data model when it connects), death certificates (published by the LWT mechanism when a device disconnects), and the DDATA/NDATA/NCMD/DCMD message types for data and command flows. Sparkplug B optimizes MQTT for real-time SCADA applications by providing the semantic layer that bare MQTT lacks, without requiring the full OPC UA specification.
MQTT can integrate legacy devices via Sparkplug through edge-of-network gateways (called Edge Nodes in Sparkplug terminology) that translate from legacy protocols (Modbus, DNP3, PROFIBUS) to Sparkplug-formatted MQTT messages, making devices that cannot natively speak MQTT participants in a Sparkplug-compliant UNS.
When Sparkplug B reduces integration complexity. If the primary challenge is standardizing MQTT payloads across many different device types and integration partners without requiring OPC UA implementations, Sparkplug B provides a well-documented convention that many SCADA and historian vendors support natively, reducing bilateral schema negotiation across a large integration landscape.
A Unified Namespace (UNS) is a single, centralized, consistently structured data distribution architecture where all OT and IT systems publish and subscribe to a common broker, eliminating point-to-point integrations. MQTT is the natural backbone protocol for a UNS because its broker-based publish-subscribe architecture is exactly the fan-out pattern a UNS requires: one publisher to many consumers, with no direct publisher-consumer coupling.
OPC UA can feed the UNS via edge gateways that connect to OPC UA servers inside OT zones, translate the OPC UA data into a structured MQTT topic hierarchy (or Sparkplug B format), and publish to the central MQTT broker. This pattern preserves OPC UA's semantic richness inside the OT zone (where machine-level interoperability and control matter) while using MQTT's scalable distribution for the cross-system layer (where data needs to reach enterprise analytics, historian, and IT systems simultaneously).
Using OPC UA and MQTT together is common in modern industrial architectures for exactly this reason. The unified architecture that results, OPC UA inside OT zones for semantics, MQTT as the UNS backbone for distribution, edge gateways bridging between them, is the pattern that gives the best of both protocols without forcing a single-protocol compromise that serves neither use case well.
Recommended scenarios for combining both:
For the broader integration architecture, see industrial DataOps and industrial IoT architecture.
OPC UA has over 1,200 pages of specifications across its published parts (OPC Foundation, multiple parts since 2008), covering the core services, security, information modeling, access types (DA, HA, AC), and the PubSub extension. In practice, most systems implement only a small subset of OPC UA: typically data access (DA), subscriptions, and the security model. Even so, a compliant OPC UA server implementation requires handling sessions, subscriptions, monitored items, security certificates, and the address space, which is weeks to months of development for a from-scratch implementation. Industrial automation vendors (Siemens, Rockwell, Kepware, Prosys) provide OPC UA SDK libraries and server products that substantially reduce this effort.
MQTT's specification is approximately 80 pages (MQTT 3.1.1, OASIS, 2014; MQTT 5.0 adds features with more specification pages but remains far simpler than OPC UA). An MQTT client library exists for virtually every programming language and embedded platform. A working MQTT publisher can be set up in minutes using open-source libraries (Paho, EMQX SDK, Mosquitto client library) and a free or open-source broker. The lightweight design means minimal infrastructure requirements: a Mosquitto broker runs on a Raspberry Pi; enterprise-grade MQTT brokers (HiveMQ, EMQX, AWS IoT Core) scale to millions of connections.
For OPC UA-to-MQTT bridging, commercial and open-source gateway products (Kepware, HighByte, Cogent DataHub, node-RED with OPC UA and MQTT plugins) translate between the protocols without requiring custom integration code. These gateways handle the OPC UA session management, address space browsing, and MQTT publication, letting integration teams configure rather than code the bridge.
Winner-by-factor table
Choose OPC UA if: semantic interoperability and control are the requirements. You are integrating machines from different vendors where a shared information model eliminates bilateral schema negotiation. You need the consuming system to understand what data means without pre-agreed documentation. You require built-in security with certificate-based authentication and message-level encryption. You need historical access services as part of the protocol. OPC UA assists in data modeling which aids machine communication in exactly these scenarios.
Choose MQTT if: lightweight telemetry and massive scale are the requirements. You are collecting data from many devices on constrained networks or over unreliable connections. You are building the distribution backbone of a Unified Namespace. You need cloud analytics integration with minimal configuration overhead. You need a protocol that can be implemented on a microcontroller in kilobytes.
Choose both if: you need semantics inside OT zones and scale for distribution. Run OPC UA for machine-to-machine communication inside the factory floor, translate to MQTT at the edge gateway for the UNS distribution layer, and use Sparkplug B to add structure to MQTT payloads where bare MQTT topic conventions are insufficient. This hybrid pattern is how most mature industrial information technology architectures actually work, not as a theoretical best of both worlds, but as a practical deployment pattern proven in real industrial integrations.
In real industrial integrations, the protocol choice is not binary. The practical patterns that work in production are:
OPC UA client/server runs within each OT zone, handling machine-to-machine communication, setpoint writes, and event subscriptions at the plant-floor level. Edge gateways at the OT/IT boundary connect to each OPC UA server, browse its address space, map selected data points to MQTT topic hierarchies, and publish to the central MQTT broker acting as the Unified Namespace. IT consumers (MES, historian, analytics platforms) subscribe to the MQTT broker. OPC UA semantics are preserved at the machine level; MQTT provides the scalable, decoupled distribution across systems.
OPC UA Part 14 (PubSub) allows OPC UA publishers to emit OPC UA-encoded data directly to an MQTT broker, preserving the OPC UA type information and security model while using MQTT's broker for fan-out. Consumers with OPC UA libraries can decode the typed payload; others can consume raw JSON-encoded OPC UA values. This pattern is best when OPC UA's full semantic richness must reach IT consumers without a translation step that discards type information.
Where running OPC UA on every device is impractical (legacy PLCs, constrained embedded devices, third-party equipment without OPC UA support), Sparkplug B edge nodes provide the translation layer. Each edge node speaks to local devices in their native protocol (Modbus, EtherNet/IP, BACnet) and publishes Sparkplug B-formatted MQTT messages to the broker, giving the UNS consistent payload structure and session management without requiring OPC UA on the device.
Most real industrial estates have a mix: some new machines with native OPC UA servers, some legacy machines with Modbus or PROFIBUS only, and some third-party systems with neither. A gateway platform (Kepware, HighByte, Ignition, or custom node-RED flows) handles all protocol translations and publishes a uniform MQTT topic structure to the central MQTT broker. Downstream consumers see a consistent data model regardless of what protocol each source device actually speaks.
The make the point concrete: you rarely pick one protocol and apply it uniformly across an industrial integration. You place OPC UA where semantic interoperability and control justify its complexity, MQTT where lightweight distribution and scale matter, Sparkplug B where MQTT needs structure, and edge gateways wherever bridging is needed. The result is a layered architecture where each protocol operates in its zone of strength. For the full integration architecture, see industrial IoT architecture.
InTechHouse case study: OPC UA and MQTT in a delivered OT/IT integration
InTechHouse implemented an OT/IT integration for an industrial operator using both protocols in their complementary roles: OPC UA inside the OT zone for machine-level data access, and an MQTT broker as the Unified Namespace backbone for distributing that data to enterprise consumers.
Edge gateways deployed at the OT/IT boundary connected to the site's OPC UA servers, browsed their address spaces to identify the data points required for the integration use cases (production rates, alarm states, energy consumption), and published structured MQTT messages to the central broker using a consistent topic hierarchy. The gateway layer handled the session management and security of the OPC UA connections while maintaining a stateless, low-overhead MQTT publisher toward the broker.
The resulting Unified Namespace gave the operations management team, the MES, and the enterprise analytics platform a single subscription point for all OT data without any of those IT systems requiring OPC UA client implementations or direct access to the OT network. The OT zone's security and availability were maintained throughout.
Not sure where to start? We work with companies at every stage, from early ideas to enterprise-level builds. A 30-minute call can save you months of guesswork.
Can I replace OPC UA with MQTT entirely?
For most use cases, no. MQTT can replace OPC UA's transport function, moving data from a publisher to subscribers efficiently, but it cannot replace OPC UA's information modeling, semantic typing, or built-in security. A system that relies on OPC UA companion specifications for domain-specific interoperability (CNC machine tools, robotics, process automation) or on OPC UA's historical access services cannot replicate that functionality with bare MQTT. Where the only requirement is data movement from device to cloud, MQTT often suffices and is simpler to implement. Where machine-level semantic interoperability or integrated security matter, OPC UA is not replaceable by MQTT alone.
Is Sparkplug B required for a Unified Namespace?
No, but it significantly reduces integration complexity when MQTT payload conventions need to be standardized across many different devices and integration partners. A bare MQTT UNS works if all publishers and subscribers agree on topic structure and payload format out of band. Sparkplug B provides a well-documented, vendor-supported convention for that structure, including birth/death certificates, typed payloads, and bidirectional command support, which makes the UNS more self-describing and easier to integrate with third-party systems that support Sparkplug B natively.
How do you migrate an OPC UA fleet to a UNS architecture?
Incrementally, using edge gateways as the bridge. Deploy a gateway platform (Kepware, HighByte, Ignition, or similar) that connects to each existing OPC UA server, maps selected data points to MQTT topics in the target UNS topic hierarchy, and publishes to the central MQTT broker. Existing OPC UA clients continue to function as before, reading directly from OPC UA servers. New IT consumers subscribe to the MQTT broker rather than requiring OPC UA client implementations. Over time, the MQTT UNS becomes the primary data distribution layer, and OPC UA client/server connections are retained only where their specific capabilities (write operations, historical access, method calls) are actually required.
Which is more secure, OPC UA or MQTT?
By specification, OPC UA is more secure. OPC UA defines certificate-based authentication, message signing, and message encryption as built-in, mandatory-to-support protocol features. MQTT's security depends entirely on configuration: TLS must be configured at the broker and client level, authentication is optional and varies by broker implementation, and no message-level security between specific publisher-subscriber pairs is defined by the protocol. In a well-configured MQTT deployment with TLS and certificate authentication enabled on the broker, the practical security level is adequate for most industrial telemetry use cases. For control applications where the security model must be guaranteed by specification rather than configuration, OPC UA's integrated security is the stronger foundation.
Can OPC UA and MQTT run together?
Yes, and in most mature industrial architectures they do. OPC UA and MQTT together address complementary requirements in the same integration stack. OPC UA runs inside OT zones for machine communication and semantic interoperability; MQTT provides the distribution backbone for the Unified Namespace that carries that data to IT consumers. Edge gateways bridge between them, translating OPC UA data to MQTT topics. OPC UA's PubSub extension (Part 14) enables direct OPC UA publication over MQTT transport, allowing the two protocols to interoperate without a translation gateway in architectures where that approach fits.
An expert in Artificial Intelligence, professor and researcher, who has authored numerous scientific publications and led international projects focused on AI, machine learning, and data-driven systems.
His work connects academic research with industrial applications, applying advanced AI models to practical challenges across sectors such as defense, telecommunications, smart industry, and cybersecurity. He has extensive experience in designing and implementing intelligent systems in complex, high-demand environments.
In addition to his technical work, Prof. Andrysiak shares insights on AI trends and applications as a speaker, mentor, and author, contributing to discussions on the role of AI in modern technology and digital transformation.
This initial conversation is focused on understanding your product, technical challenges, and constraints.
No sales pitch - just a practical discussion with experienced engineers.
Share a few details about your product and context. We’ll review the information and suggest the most appropriate next step.
