Quick answer: OPC Unified Architecture (OPC UA) and MQTT (originally Message Queuing Telemetry Transport) do different jobs. OPC UA gives industrial data structure and meaning, and lets applications browse, read, write and call methods on equipment over secure sessions, so it is the natural interface to programmable logic controllers (PLCs), distributed control systems (DCS) and supervisory control and data acquisition (SCADA). MQTT distributes messages through a broker to any number of subscribers over outbound-only connections, which suits remote sites and constrained links. Most Industrial Internet of Things (IIoT) architectures use both: OPC UA close to the process, MQTT between sites and into IT.
An integrator scoping data acquisition for twenty remote well pads usually reaches the same fork: expose everything over OPC UA, or publish it to an MQTT broker? Both are open standards, both can be secured, and both appear in every IIoT reference architecture. They were designed for different problems, and most good designs use both. This guide shows where each one fits, what each one leaves to you, and how to combine them, for the information technology (IT) and operational technology (OT) teams that have to agree on one architecture.
- OPC UA describes. Data arrives typed, with units, limits and relationships, and writes and method calls return a status.
- MQTT distributes. One publish reaches every subscriber, and remote sites only ever connect outbound.
- Use both. The useful design question is where OPC UA ends and MQTT begins.
What OPC UA does well
OPC UA (IEC 62541) is the OPC Foundation’s platform-independent successor to OPC Classic, which depended on Microsoft DCOM (Distributed Component Object Model). [1] Its strength is semantics. A server exposes an address space of typed nodes with units, ranges and relationships. A client connecting to a compressor skid can browse it and learn that Discharge Pressure belongs to Compressor C-101, is measured in bar and has a high alarm limit, without a separate tag list.
Clients open secure sessions to read, write, call methods and subscribe to changes. One standard covers live data, history, and alarms and conditions. Companion specifications standardize information models for whole equipment classes, so machines of the same type from different vendors look the same to a client. Security is part of the protocol: X.509 application certificates, signed or signed-and-encrypted messages, and user authentication by password, certificate or token
What Is OPC UA? The Complete Guide for Industrial Automation
Where it stops. Sessions are point-to-point, so ten applications mean ten sessions on the same server. The client usually opens the connection, which needs an inbound firewall rule at a remote site unless the server uses reverse connect. The full stack is heavier than an MQTT client, although embedded profiles run on small devices.
What MQTT does well
MQTT is an OASIS publish/subscribe standard, also published as ISO/IEC 20922. [3] Publishers send messages to topics such as field/pad07/compressor1/discharge_pressure on a broker, and subscribers receive what matches their subscription. Neither side knows the other exists, so adding a consumer never touches the source.
Three features matter in industry. Quality of Service (QoS) levels 0, 1 and 2 set the delivery guarantee: at most once, at least once or exactly once. Retained messages give a late subscriber the last known value. Last Will and Testament lets the broker announce when a client drops off. Every client connects outbound, so remote sites need no inbound firewall rule, and report by exception keeps cellular and satellite traffic low. MQTT 5.0 adds reason codes, message expiry and shared subscriptions.
What Is MQTT? Architecture, QoS, and Industrial Use Cases
Where it stops. Plain MQTT defines nothing about payloads, units or device state, so two integrators can publish the same pump in incompatible ways. Sparkplug B, an Eclipse Foundation specification (ISO/IEC 20237:2023), closes much of that gap with a standard topic namespace, typed payloads, and birth and death messages that tell consumers what each node publishes and whether its data is current. [4] It also defines command messages, but confirming that a command took effect is left to your design.
OPC UA vs MQTT: side-by-side comparison
| Criterion | OPC UA | MQTT (with Sparkplug B) |
| Primary role | Structured access to industrial data and control | Message distribution to many consumers |
| Pattern | Client/server sessions (PubSub also specified, Part 14) | Publish/subscribe through a broker |
| Data model | Rich, typed, browsable; companion specifications | None in plain MQTT; Sparkplug B adds typed metrics |
| Discovery | Clients browse servers; discovery servers list them | Sparkplug birth messages announce available metrics |
| Writes and commands | Writes and method calls return a status code | Supported; confirmation logic is yours to design |
| History and alarms | Historical Access and Alarms and Conditions defined | Not defined; handled by historians and consumers |
| Security | Application certificates, signing, encryption, user authentication | Transport Layer Security (TLS), broker authentication, topic access control |
| Connection direction | Client connects to server (reverse connect available) | Every client connects outbound to the broker |
| Many consumers | One session per client per server | One publish, any number of subscribers |
| Network fit | Reliable plant local area network (LAN) | LAN, plus cellular, satellite and intermittent links |
When to Use MQTT
MQTT is the right choice when the priority is moving data efficiently across constrained, distributed, or high-device-count environments:
- Remote monitoring of assets that are impractical to poll continuously: pipelines, offshore equipment, remote pumping stations
- Edge-to-cloud telemetry feeding dashboards, analytics platforms, or a data lake
- High-device-count deployments where a broker’s fan-out model scales better than point-to-point polling
- Environments with intermittent or bandwidth-constrained connectivity, where MQTT’s small header and change-based publishing matter
When to Use OPC UA
OPC UA is the right choice when the priority is interoperability and trustworthy semantics between industrial systems that need to understand each other’s data, not just receive it:
- Plant-floor communication between PLCs, SCADA, and MES systems from different vendors
- Any environment where security has to be part of the connection itself, certificate-based trust, not bolted-on TLS
- Applications that need OPC UA’s rich data typing, historical data access, or alarm and event models
- Systems that must discover what data is available and what it means without manual configuration
Security: OPC UA vs MQTT in an OT network
Neither protocol is insecure by design. The difference is where the security lives, and how it usually gets weakened.
- OPC UA secures the protocol. Each application holds an X.509 certificate, and each endpoint declares a security mode: None, Sign, or Sign and Encrypt. Typical weak points are endpoints left at None and certificates trusted automatically. A Global Discovery Server (GDS) manages certificates at scale. See OPC UA security.
- MQTT secures the transport and the broker. Use TLS, client authentication and an access control list per topic. Typical weak points are unencrypted listeners, anonymous access, and command topics that any client can publish to.
- Architecture matters more than the protocol. Outbound-only MQTT fits segmented networks, with a broker in the industrial DMZ (demilitarized zone) receiving data without opening paths into the control network. OPC UA reverse connect gives OPC UA servers the same direction. Either way, put the protocol break at a zone boundary, following the ISA/IEC 62443 zones-and-conduits model. [5] See Bridging the OT and IT gap.
Which one, for which job
Four questions usually settle it: who consumes the data and how many consumers there are, what network carries it, whether the consumer needs context or just values, and whether commands flow back and need confirmation.
| Scenario | Better fit | Why |
| SCADA or manufacturing execution system (MES) reading PLCs and DCS on the plant network | OPC UA | Context, browsing and confirmed two-way control over a reliable LAN |
| Remote well pads, pumping stations or reservoirs on cellular or satellite | MQTT with Sparkplug B | Low bandwidth, outbound only, stale-data detection |
| Same data needed by a historian, analytics and a cloud platform | MQTT broker | One publish serves every consumer |
| Operator sends a setpoint and needs confirmation | OPC UA | Writes and method calls return a status |
| Unified Namespace (UNS) across several sites | Both: OPC UA at the edge, MQTT for distribution | OPC UA supplies context; the broker hosts the topic tree |
| Equipment builder delivering a skid with a standard interface | OPC UA with a companion specification | Customers get a known model, with no tag mapping |
| Legacy OPC Classic servers feeding modern applications | OPC UA, through a wrapper | Removes DCOM without replacing the server |
Five misconceptions to avoid
- “MQTT is not secure enough for OT.” A broker with TLS, authentication and topic access control is a sound design. The risk is the default configuration, not the protocol.
- “OPC UA is too heavy for the edge.” Embedded OPC UA servers run in PLCs and small devices. The real cost of OPC UA is the session model at scale, not the footprint.
- “OPC UA PubSub makes MQTT unnecessary.” PubSub can use an MQTT broker as its transport. [2] You still run, secure and govern a broker.
- “Sparkplug B is a Unified Namespace.” Sparkplug organizes topics by group, edge node and device, not by the business. Many teams translate it into an ISA-95 tree above the edge. [6]
- “We have to choose one.” Most multi-site architectures use both, and the standards increasingly overlap.
Using both: a hybrid OPC UA and MQTT architecture
In multi-site projects, the real question is where OPC UA ends and MQTT begins. A common split keeps control local and moves data centrally.
- At the machine. Devices expose data over OPC UA or their native protocols, such as Modbus or DNP3. Local SCADA keeps reading and writing over OPC UA, so control never depends on the wide-area network (WAN).
- At the edge. An edge node reads those sources, adds units, quality and timestamps, buffers data during outages (store-and-forward) and publishes it outbound as Sparkplug B.
- In the middle. A broker organized around an ISA-95 asset model becomes the Unified Namespace (UNS) that any authorized system can subscribe to.
- Historians, analytics, MES, enterprise resource planning (ERP) and cloud platforms subscribe to the branches they need, with no new connections to the field.
Where commands must cross the WAN, keep them on separate, access-controlled topics and validate them at the edge. OPC UA PubSub can also publish over MQTT, so the two standards increasingly meet in the middle. For the topic design itself, see What Is a Unified Namespace (UNS)? The Roles of MQTT and OPC UA.
See MQTT Universal Broker in Action
From OPC Classic to OPC UA and MQTT
Many sites still run OPC DA, HDA and AE servers (Data Access, Historical Data Access, and Alarms and Events). Bringing them into a hybrid architecture does not require replacing them. Integration Objects offers standalone OPC products for each step:
- OPC UA Wrapper lets OPC UA clients access OPC Classic (DA, HDA and AE) servers. Its OPC UA Proxy component covers the opposite direction: OPC Classic clients accessing OPC UA servers.
- OPC UA Bridge bridges OPC Classic and OPC UA in both directions, with encryption, authentication, DCOM elimination and audit logging.
- OPC Client for MQTT publishes data from OPC DA servers to MQTT brokers and cloud platforms.
- OPC UA Client and OPC UA Server Simulator – Free Edition, both free of charge, help you test OPC UA connections before go-live. See also Migrating OPC Classic to OPC UA.
How SIOTH® handles both protocols
Hybrid designs often turn into a chain of gateways, a standalone broker and scripts, each to license, patch and troubleshoot. SIOTH® (Smart IoT Highway) is the Integration Objects platform for IT/OT integration. Engineers configure Data Flows instead of point-to-point connectors, and one platform covers both sides of the protocol question.
- Data Flow connects 100+ OT protocols, including OPC UA, OPC Classic, Modbus, DNP3 and IEC 61850, with store-and-forward buffering for intermittent links.
- Data Model applies an ISA-95 compatible asset hierarchy, so MQTT topics and OPC UA clients share one structure.
- OPC UA Universal Server, a configurable server within Data Flow, exposes all connected sources as one secure OPC UA endpoint, with Data Access, Historical Access and Alarms and Conditions.
- MQTT Universal Broker, also a configurable server within Data Flow, is Eclipse Sparkplug B certified and supports MQTT Standard and Sparkplug B over TCP and WebSocket, with TLS/SSL.
- Security by design: protocol break, DMZ support, role-based access control (RBAC) and an audit trail. SIOTH® is IEC 62443-aligned.
Because SIOTH® feeds the existing SCADA over OPC UA and connects natively to AVEVA PI, nothing that already works has to be replaced. Typical single-site go-live is 2–5 weeks, depending on scope.
Plan your OPC UA and MQTT architecture with an expert.
Frequently Asked Questions
Is MQTT faster than OPC UA?
For fan-out to many consumers and over constrained links, MQTT is usually more efficient, because one publish serves every subscriber. On a plant LAN, OPC UA subscriptions also report by exception, so the difference is smaller. Test with your own data before deciding.
Can OPC UA run over MQTT?
Yes. OPC UA Part 14 (PubSub) defines how OPC UA data sets are published through an MQTT broker, in JSON (JavaScript Object Notation) or binary encoding. Support varies by product. [2]
What is Sparkplug B, and do I need it?
Sparkplug B is an Eclipse Foundation specification on top of MQTT that standardizes topics, payloads and device state. Use it when many devices and consumers must interpret data the same way without custom agreements. [4]
Which protocol is more secure?
Both can meet OT security requirements. OPC UA builds security into the protocol; MQTT relies on TLS and broker access control. Misconfiguration is the usual risk, not the protocol.
Can SCADA read data from an MQTT broker?
Many modern SCADA systems include an MQTT client. Where a SCADA only speaks OPC UA or OPC Classic, an OPC UA server that exposes the same data bridges the gap, such as the OPC UA Universal Server within SIOTH® Data Flow.
Which protocol should I use for remote sites?
MQTT with Sparkplug B, in most cases. Outbound-only connections, report by exception and stale-data detection suit cellular and satellite links. Keep local control on OPC UA at the site.
References
[1] OPC Foundation. OPC UA specifications (OPC 10000 series), also published as IEC 62541, and Companion Specifications. opcfoundation.org
[2] OPC Foundation. OPC UA Part 14: PubSub (OPC 10000-14; also IEC 62541-14). reference.opcfoundation.org
[3] OASIS. MQTT Version 3.1.1 (2014; ISO/IEC 20922:2016) and MQTT Version 5.0 (2019). oasis-open.org
[4] Eclipse Foundation. Sparkplug Specification 3.0 (ISO/IEC 20237:2023). sparkplug.eclipse.org
[5] ISA/IEC 62443, Security for industrial automation and control systems; NIST SP 800-82 Rev. 3, 2023. isa.org, csrc.nist.gov
[6] ISA. ANSI/ISA-95: Enterprise-Control System Integration (series); also IEC 62264. isa.org
Check versions and standards status against current publications.
