OPC UA vs MQTT: Why You Probably Need Both

Ask ten IIoT architects whether to build on OPC UA or MQTT, and most will answer as if it's a single choice, like picking PROFINET over EtherNet/IP. It isn't. Industrial Ethernet still carries 76-79% of new industrial networking nodes; OPC UA and MQTT sit far behind it, described by HMS Networks as emerging protocols with no significant market share of their own yet (HMS Networks, 2025/26). That gap is the tell: these two aren't competing for the same job.

OPC UA and MQTT solve different problems at different layers of the stack. Treating them as rivals is how teams end up locking a plant into one protocol, then hitting an integration wall six months later when the other one proves unavoidable.

TL;DR: OPC UA and MQTT solve different problems. OPC UA is a semantic, secure client-server (and now pub-sub) protocol for modeling data on the plant floor; MQTT is a lightweight publish-subscribe transport for moving telemetry to the cloud. Most real IIoT stacks run both, bridged at an edge gateway - a pattern that adds 50-200ms of latency (Arulnithika et al., 2025, via Azeta et al. 2025), so keep real-time control local to OPC UA.

What's the Real Difference Between OPC UA and MQTT?

OPC UA models data; MQTT moves it. OPC UA (IEC 62541) attaches semantic metadata, units, ranges, accuracy, and context, to every value it exposes, while MQTT (OASIS / ISO-IEC 20922) carries whatever payload you hand it through a broker without inspecting or interpreting it. For a full breakdown of what OPC UA actually is, including its address space and security model, see our dedicated explainer.

That distinction sounds academic until you've debugged a legacy system. A raw Modbus register just holds a number; nothing in the wire protocol tells you it's a temperature in Celsius, bounded between -40 and 150, read from a specific sensor tag. OPC UA's information model carries all of that alongside the value itself, which is exactly the gap our Modbus TCP for plant networks comparison runs into on the legacy side.

Most comparisons stop at "OPC UA has semantics, MQTT doesn't." The more useful framing: OPC UA's semantic layer is the reason it's expensive to implement on constrained devices, and MQTT's lack of one is the reason it scales to thousands of publishers without anyone agreeing on a schema first. Neither trait is a flaw. Each is the direct tradeoff for what the protocol is optimized to do.

MQTT, by contrast, is payload-agnostic on purpose. A broker moving JSON, binary, or Sparkplug-encoded telemetry doesn't know or care what's inside the message; it just routes it to subscribers on a matching topic. That simplicity is what lets MQTT scale to thousands of low-power publishers without a shared schema getting negotiated up front.

Citation capsule: OPC UA (IEC 62541) attaches semantic metadata, units, ranges, accuracy, and source context, to industrial values, while MQTT (OASIS / ISO-IEC 20922) transports opaque payloads through a broker with no awareness of their meaning. That single design difference explains why OPC UA suits plant-floor modeling and MQTT suits high-fan-out cloud telemetry. The distinction shows up the moment a team tries to reuse data outside the system that produced it: an OPC UA client can browse a server's address space and immediately know what a value represents, its engineering units, its valid range, and where it came from, without consulting a separate document. A raw MQTT payload carries none of that context on its own; two teams publishing to the same broker have to agree on a schema by hand, or adopt something like Sparkplug B, before a subscriber can trust what it receives. Neither approach is wrong. OPC UA trades implementation weight for built-in meaning, while MQTT trades that meaning for the lightness that lets it fan out to thousands of publishers without anyone negotiating a schema first.

How Do Their Architectures Actually Work?

OPC UA runs on a client-server model with built-in service discovery; MQTT runs on a broker-mediated publish-subscribe model that decouples publishers from subscribers entirely. A client asking an OPC UA server for a value gets a structured, browsable response; an MQTT publisher just fires a message at a topic and never even knows who, if anyone, is listening.

That decoupling is MQTT's core architectural bet. A sensor publishing to a topic doesn't hold a connection open to every consumer, and it doesn't wait on a reply. The broker handles fan-out, so adding a hundredth subscriber costs the publisher nothing. Classic OPC UA client-server, by comparison, ties a session to a specific server, which is exactly what you want when a SCADA client needs to browse a live, structured address space.

OPC UA hasn't stood still on this front. OPC UA PubSub lets the same information model ride a broker-based transport, including MQTT itself, instead of the classic client-server session. Pair that with Time-Sensitive Networking at the field level, and OPC UA can now cover both the structured-discovery use case and the decoupled, high-throughput one, at least on paper.

OPC UA vs MQTT across the eight axes that actually decide a design.

Scoring both protocols side by side across eight practical axes, rather than leaving it in prose, makes the tradeoff scannable: latency, security posture, semantic modeling, scale/fan-out, firewall and cloud friendliness, implementation complexity, retrofit fit on legacy gear, and ecosystem maturity. On five of those eight, the honest answer is "depends on which layer you're solving for," which is the whole point of this piece.

Which Is More Secure - OPC UA or MQTT?

OPC UA ships with security built into the specification: TLS transport encryption, X.509 certificate-based application and user authentication, role-based access control, and audit logging. MQTT relies on whatever the application layer bolts on, typically TLS plus username/password or client certificates, with Sparkplug B adding a lighter structural layer on top.

That built-in-versus-bolted-on distinction matters for how deployments actually fail. An OPC UA server misconfigured out of the box still defaults toward a defined security policy the spec requires implementers to support. A bare MQTT broker, on the other hand, has no security posture at all until someone explicitly configures TLS and access control, and plenty of quick industrial pilots ship without either.

Citation capsule: OPC UA's specification (IEC 62541) mandates TLS encryption, X.509 certificate-based application and user authentication, role-based access control, and audit logging as core features. MQTT provides none of this natively; industrial deployments layer TLS and authentication on separately, which is why Sparkplug B's added structure has become a de facto baseline for serious MQTT rollouts. That gap matters most at the moment of deployment, not in a security audit six months later. An OPC UA server that ships with a default configuration still points an implementer toward a defined security policy, because the specification requires vendors to support one, so there's a baseline to fall back on even when nobody configures anything by hand. A bare MQTT broker offers no equivalent fallback. It stays wide open until someone explicitly turns on TLS, sets up certificate-based authentication, and defines access control, and in a rushed industrial pilot, that configuration step is exactly the one most likely to get skipped under deadline pressure.

MQTT isn't insecure by definition. In our experience, its security is a deployment decision instead of a specification guarantee, and that gap is exactly where a rushed IIoT pilot gets burned.

What Does Sparkplug B Add to MQTT?

Sparkplug B adds three things raw MQTT lacks on its own: a defined topic namespace, birth and death certificates, and stateful session awareness. Together they turn MQTT from "a message goes somewhere" into a protocol that knows whether a device is online, offline, or silently stuck.

The topic namespace matters because raw MQTT lets every implementer invent its own topic structure, which is fine for one team and chaos across a multi-vendor plant. Sparkplug B standardizes that structure, so a Sparkplug-aware subscriber can parse any compliant publisher's topics without a custom integration per vendor.

Birth and death certificates solve a different problem: MQTT's transport layer alone can't tell a subscriber whether silence means "nothing changed" or "the device died." Sparkplug B's birth message announces a device coming online with its full data set; its death certificate, delivered via the broker's last-will mechanism, tells subscribers the moment a device drops off, rather than leaving them guessing from a stale value.

The first time I saw a raw-MQTT pilot go sideways, the cause was a sensor that had lost power silently and kept publishing its last cached value from a downstream historian cache. Nobody caught it for two shifts. Sparkplug B's death certificate exists to close that exact gap, and it's the single feature that convinces most controls teams MQTT is ready for a real plant floor.

For a detailed technical guide on what makes Sparkplug B essential for industrial MQTT, see our complete breakdown.

Can OPC UA and MQTT Work Together?

Yes, and this is the pattern most real IIoT stacks already use: OPC UA stays on the plant floor as the structured source of truth, while an edge gateway translates that data into MQTT for cloud, cross-site, or IT-facing telemetry. The two protocols aren't competing for the same job here; they're stacked.

The gateway is the load-bearing piece of this architecture. It speaks OPC UA (or Modbus, or a PLC-native protocol) to the field devices on one side, and publishes structured MQTT, often Sparkplug B, out to a broker on the other. Everything upstream of that gateway, historians, dashboards, cloud analytics, only ever sees MQTT.

Citation capsule: The dominant real-world IIoT pattern bridges OPC UA on the plant floor to MQTT for the cloud through an edge gateway, rather than replacing one protocol with the other. This lets plant-floor systems keep OPC UA's semantic modeling and security guarantees while cloud and cross-site systems get MQTT's lightweight, firewall-friendly fan-out. The gateway is doing real work in this pattern, not just relaying bytes: it terminates the OPC UA session on one side, translates the structured information model into a topic and payload MQTT can carry, and republishes that data outward, often using Sparkplug B so downstream subscribers know a device's state as well as its value. Everything above the gateway, historians, SCADA overlays, cloud analytics, only ever touches MQTT, which is what keeps the plant network from being exposed directly to IT systems. Getting that translation layer right, rather than picking a favorite protocol, is what determines whether the architecture holds up once it reaches production.

This is also the architecture behind the Unified Namespace idea gaining traction in IIoT circles: one MQTT broker acting as a single source of truth that every system, SCADA, MES, cloud analytics, publishes to and subscribes from, fed by OPC UA and other field protocols translated at the edge. It's a discipline about where translation happens, not a new protocol.

What Does the Integration Actually Cost?

The bridge, not the protocol choice, is where the real cost and risk live. Protocol translation through an edge gateway adds 50-200ms of latency, and teams spend 40-60% of integration budgets on middleware and gateway development. Industrial case studies show integration success rates of only 45-65% (Arulnithika et al., 2025; Mourtzis et al., 2023).

Read those three numbers together and the pattern most "OPC UA vs MQTT" content skips becomes clear: the risk in these projects was never picking the wrong protocol; it was underestimating the gateway. A 40-60% budget share for middleware means the translation layer, not either endpoint protocol, is the biggest line item on most integration projects.

We've found that teams scoping this work tend to price the OPC UA server and the MQTT broker carefully, then treat the gateway between them as an afterthought, a box to buy rather than a system to design. That's backwards. The 45-65% success rate in industrial case studies (Mourtzis et al., 2023) tracks almost exactly with how much attention that middleware layer got during planning, not with which protocol sat on either side of it.

The 50-200ms latency figure has a practical consequence worth stating plainly: don't route anything time-critical through the bridge. A closed-loop control signal that needs a millisecond-scale response has no business crossing a gateway built for telemetry throughput. Keep that loop on OPC UA, locally, and let MQTT carry everything that can tolerate a couple hundred milliseconds of delay.

When Should You Use OPC UA vs MQTT?

Use OPC UA when the job is local, real-time, and needs rich modeling: LAN-scale deployments, deterministic control loops, device discovery, and anywhere a PLC needs to be the authoritative source of truth. Use MQTT when the job is cloud-facing, high fan-out, bandwidth-constrained, or has to cross a firewall without opening inbound ports.

Most projects that span the plant floor to the cloud need both, and that's the default worth planning for rather than an edge case. OPC UA anchors the deterministic, semantically rich layer close to the machines; MQTT (often Sparkplug B) carries the resulting telemetry outward to whoever needs to see it, dashboards, historians, cloud ML pipelines, without exposing the plant network directly.

Adoption data backs up how deliberately teams are already making this split. OPC UA adoption sits at 31% for new industrial installs versus just 7% for retrofits. That split comes from a surveyed set of 342 industrial deployments (Mourtzis et al., 2023). Greenfield projects can design the OPC UA layer in from day one; retrofits more often bolt MQTT onto whatever legacy protocol is already running, because rewriting the field layer costs far more than adding a gateway.

If your project also touches device-level protocols below the network layer, our piece on device-layer protocols covers where IO-Link fits into that stack, and our guide on digital data over legacy wiring covers HART for plants that haven't moved off 4-20 mA loops yet. For the industrial Ethernet layer these protocols usually ride on top of, see our PROFINET vs EtherNet/IP comparison, or our guide to real-time Industrial Ethernet like EtherCAT vs PROFINET for servo and motion-control applications.

Conclusion

OPC UA and MQTT aren't fighting for the same job, and framing the decision as "vs" is what sends teams down the wrong path in the first place.

• OPC UA models data with semantics and built-in security; MQTT moves data with lightweight, broker-based fan-out.
• The edge gateway bridging them is the expensive, risky part of the project, not the protocol choice itself.
• Keep anything real-time or deterministic on OPC UA, locally; let MQTT carry telemetry that can tolerate the bridge's latency.
• Running both, stacked rather than chosen, is the normal architecture for anything spanning plant floor to cloud.

For a broader view of where this decision sits alongside fieldbus, industrial Ethernet, and device-layer protocol choices, see our full IIoT protocol framework.