Both get lumped together as "the way OT data reaches IT and the cloud" — but one was designed to describe what a piece of data means, and the other was designed to move bytes as cheaply and fast as possible without caring what they mean at all.
OPC UA and MQTT show up on the same architecture diagrams so often that engineers new to IIoT design sometimes assume they're competing options for the same job. They aren't — they solve different problems, and most serious IIoT architectures end up using both, often together. OPC UA (Unified Architecture, from the OPC Foundation) is a rich information-modeling standard: it defines not just a value but a typed, browsable, self-describing structure around that value — units, data quality, historical access, method calls, security — and it supports both client-server request/response and, since UA became transport-flexible, publish-subscribe. MQTT is a minimal publish-subscribe messaging transport built for constrained devices and unreliable networks: a broker, topics, small binary payloads, three quality-of-service levels, and nothing said about what the payload actually contains. That gap is exactly why Sparkplug B exists — a payload specification layered on top of MQTT to give it some of the semantic structure it doesn't have natively.
OPC UA was built by an industry consortium that had already lived through the interoperability pain of proprietary OPC Classic (COM/DCOM-based, Windows-only, fragile across firewalls) and decided the next version needed a real information model: nodes with types, units, historical access, alarm/condition handling, and method calls, all wrapped in built-in transport security (certificates, signing, encryption) rather than bolted on. That makes it well suited to system-to-system integration where both sides need to agree on what a value actually represents — a SCADA server exposing structured data to an MES or ERP system, for instance. MQTT was built for the opposite constraint: IBM and Arcom designed it in 1999 for oil pipeline telemetry over expensive, unreliable satellite links, where every byte of overhead mattered and the priority was "the message gets through reliably" — not "the message explains itself." A three-byte fixed header, a broker doing the fan-out, and three QoS levels is the entire core spec; everything about payload meaning is left to the application, which is exactly why Sparkplug B (an MQTT payload/topic namespace convention from the Eclipse Foundation) exists to bolt back on birth/death certificates, metric typing, and state — the semantic structure MQTT deliberately left out to stay lightweight.
Most mature IIoT architectures use both, at different layers. A common pattern: OPC UA connects the plant floor's PLCs and SCADA servers, where the rich information model and built-in security matter for talking to MES/ERP and other structured enterprise systems. MQTT (often with Sparkplug B) carries high-volume sensor telemetry from a large, distributed device fleet — vibration sensors, remote wellheads, distributed energy assets — up to a cloud or edge broker, where bandwidth efficiency and scale matter more than per-message semantic richness. Since OPC UA 1.04, the UA specification itself even added a PubSub transport binding that can run over MQTT, blurring the line further — you can have OPC UA's information model riding on an MQTT transport. Treating them as mutually exclusive competitors usually means picking the wrong tool for at least one part of the architecture.
Explains why OPC UA and MQTT are not competing options for the same job: OPC UA is a rich, secure information-modeling standard designed to describe what data means, while MQTT is a minimal publish-subscribe transport designed to move data efficiently at huge scale over constrained links, with Sparkplug B layered on top to add back semantic structure. Illustrated with an OPC UA SCADA-to-MES integration and an MQTT sensor-fleet telemetry pipeline.
Both protocols routinely appear on the same IIoT/Industry 4.0 reference architecture diagrams, both are described as ways to get OT data to IT systems and the cloud, and both have largely displaced older proprietary or serial-based integration methods. That shared context — plus marketing material from platform vendors that treats them as interchangeable checkboxes — leads to the assumption that they compete for the same role. They don't: one is an application-layer information model with multiple possible transports, the other is purely a transport-layer messaging protocol with no opinion on data structure.
OPC UA (IEC 62541) was designed by the OPC Foundation as the successor to OPC Classic, explicitly to fix that older standard's dependence on Windows COM/DCOM and its poor behavior across firewalls and networks. The result is a platform-independent, service-oriented architecture with a genuine information model — nodes carry type definitions, units of measure, data quality/timestamp metadata, historical access, alarms and conditions, and callable methods — plus built-in security via X.509 certificates, message signing, and encryption. It supports both classic client-server request/response and, since UA added PubSub, publish-subscribe patterns over multiple transports including UDP, AMQP, and MQTT.
MQTT was designed in 1999 by IBM and Arcom for SCADA-style pipeline telemetry over expensive, low-bandwidth, unreliable satellite links. Its entire design brief was minimizing overhead: a two-byte minimum fixed header, a broker that decouples publishers from subscribers by topic, and three quality-of-service levels (0 = at most once, 1 = at least once, 2 = exactly once) to trade reliability against overhead as needed. It says nothing about what a payload contains — that is left entirely to the application, or to a convention like Sparkplug B layered on top.
The practical design question is rarely "which protocol" in isolation — it's which layer of the architecture you're solving for. Connecting a SCADA server to an MES, historian, or enterprise system where both sides need to agree on exactly what a value represents (units, quality, whether it's a setpoint or a process variable) favors OPC UA's built-in semantics and security. Streaming telemetry from a large, geographically distributed, bandwidth- or power-constrained device fleet — remote wellhead sensors, a fleet of vibration monitors, a distributed solar asset network — favors MQTT's minimal overhead and broker-based fan-out, usually paired with Sparkplug B so downstream consumers get consistent metric typing and device birth/death state without hand-rolling it. Many production architectures run both: MQTT/Sparkplug B for edge-to-cloud sensor scale, OPC UA for the structured plant-to-enterprise integration, sometimes bridged through a single edge gateway that speaks both.
MQTT itself has no mandatory built-in security model — authentication and encryption (typically TLS over port 8883) are optional and left to the implementation. OPC UA has security designed into the specification itself: certificate-based authentication, message signing, and encryption are core parts of the standard, not add-ons. In practice, well-configured MQTT deployments (TLS, client certificates, broker ACLs) can be quite secure, but the responsibility sits with the implementer rather than being enforced by the protocol.
Sparkplug B is a payload and topic-namespace specification, maintained under the Eclipse Foundation, that runs on top of standard MQTT. Because raw MQTT payloads are just opaque bytes with no required structure, Sparkplug B defines a consistent way to encode metric names, data types, timestamps, and device/node birth and death state, so that different vendors' MQTT clients and SCADA/historian software can interoperate meaningfully. It's essentially the semantic layer MQTT deliberately omitted to stay lightweight.
Yes. Since OPC UA 1.04 added the PubSub extension, OPC UA's information model can be transported over several bindings including MQTT (as well as UDP and AMQP), rather than only the classic client-server binary TCP transport. This lets a system get OPC UA's semantic richness while still using a lightweight, broker-based transport for scale — which is part of why the two are increasingly complementary rather than competing.
For a single-site integration where the SCADA server and historian are both on the plant network and need to exchange structured, typed data with strong security, OPC UA's client-server model is usually the more direct fit — it's designed exactly for that kind of system-to-system exchange. MQTT's broker-based scale advantages matter most once you're dealing with large device counts or WAN/cloud connectivity, which a single local historian integration typically doesn't need.
No, but it requires deliberate configuration. A well-designed MQTT architecture still respects Purdue-model segmentation — edge devices publish to a broker that sits in a DMZ or is otherwise firewalled from both the OT network and the open internet, with TLS and authenticated clients. The protocol's lightweight nature doesn't remove the need for the same network security architecture any IIoT data path requires; it just means security has to be added explicitly rather than assumed from the protocol.
Try our SCADA Studio
More calculators, simulators, and guides for this discipline.