MQTT vs OPC-UA:
Which Industrial Protocol
Fits Your Plant in 2026?

▶ MQTT vs OPC UA - Which Protocol for Your Plant Data? - from the Merobix channel. Subscribe for weekly SCADA explainers.

Why Your Industrial Protocol Choice Matters

The protocol sitting between your field devices and your SCADA or cloud platform is not a minor implementation detail. It determines your bandwidth costs every month for the operational life of the system. It sets your security posture against increasingly sophisticated ICS threats. It defines the ceiling on how many endpoints you can scale to before the architecture breaks down. And it determines how much context - metadata, engineering units, data types, relationships between tags - travels alongside the raw values your operators need.

Legacy Modbus, developed in 1979, remains one of the most widely installed industrial device communication protocols. It is simple, deterministic, and universally supported - but it was designed for point-to-point serial communication between a master and a handful of slaves, carries no security whatsoever, and transmits raw register values with no data type information attached. Understanding how Modbus works and where it falls short is the foundation for appreciating why MQTT and OPC-UA exist at all.

The rise of IIoT and cloud SCADA has put industrial protocol selection under a spotlight it never received during the Modbus era. When your data needs to travel from a wellhead in west Texas to a cloud database in us-east-1, then appear in a mobile dashboard in a Houston office, the protocol stack you choose has real consequences for latency, reliability, cost, and security. Neither MQTT nor OPC-UA is universally the right answer - the best architects understand both and know when to use each. Understanding what SCADA is and how it has evolved provides the wider context for this protocol comparison.

What Is MQTT? (Message Queuing Telemetry Transport)

MQTT was born at IBM in 1999, developed by Andy Stanford-Clark and Arlen Nipper for a specific industrial problem: monitoring an oil pipeline running over satellite links in the Middle East. The protocol was engineered from day one for constrained networks with limited bandwidth and unreliable connectivity - which makes it remarkably well-suited for modern IIoT applications that face the same constraints, just over cellular rather than satellite.

The core architecture of MQTT is publish-subscribe, mediated by a central message broker. Devices (publishers) post messages to named topics on the broker. Any number of subscribers - SCADA servers, cloud platforms, data historians, analytics engines - can receive those messages by subscribing to the relevant topics. The publisher and subscriber never communicate directly and need not even know of each other's existence. This decoupling is what makes MQTT scale so well: adding a new subscriber to an existing data stream requires zero changes to the publishing device.

MQTT QoS Levels

MQTT defines three Quality of Service levels that trade off message delivery guarantees against network overhead:

• QoS 0 (At Most Once): Fire-and-forget. The broker delivers the message at most once and does not acknowledge receipt. Zero additional overhead. Use for high-frequency sensor data where occasional packet loss is acceptable.
• QoS 1 (At Least Once): The message is delivered at least once, possibly more. The sender retries until it receives an acknowledgment. Duplicate messages are possible. Appropriate for most SCADA telemetry where reliable delivery matters.
• QoS 2 (Exactly Once): A four-way handshake guarantees exactly one delivery. Maximum overhead. Use only for critical setpoint commands or state changes where duplicate delivery would cause operational problems.

MQTT 5.0, released as an OASIS standard in 2019, added significant improvements over the long-running 3.1.1 standard: message expiry intervals, shared subscriptions (load-balancing across multiple subscribers), user properties (custom key-value metadata attached to messages), enhanced authentication flows, and reason codes for better error diagnostics. For industrial deployments, the shared subscription feature is particularly valuable - it enables multiple SCADA server instances to load-balance incoming data from thousands of field devices without receiving duplicate messages.

What Is OPC-UA? (OPC Unified Architecture)

OPC-UA did not emerge from a single clever engineering decision - it emerged from a decade of pain. OPC Classic (OPC DA, OPC HDA, OPC A&E) was the industry's first serious attempt at protocol standardization for SCADA integration, and it worked - but only on Windows, only over COM/DCOM, and with a security model that was essentially nonexistent. OPC-UA, published by the OPC Foundation in 2008, threw out every Windows dependency and rebuilt the protocol from scratch as a platform-independent, security-first, information-modeling standard.

The fundamental architecture of OPC-UA is client-server. An OPC-UA server exposes a structured address space - a hierarchical graph of nodes representing real-world objects: PLCs, sensors, process variables, alarm states, historical data, and the relationships between them. An OPC-UA client connects to the server, browses the address space to discover available data, and subscribes to the items it needs. Unlike MQTT's flat topic hierarchy, the OPC-UA address space carries rich semantic context: not just a value, but the variable's engineering unit (bar, degC, m3/h), its data type (Float, Int32, Boolean), its timestamp, its quality status, and its place in a structured object model that mirrors the actual physical system.

OPC-UA Information Modeling

The OPC-UA information model is arguably the protocol's most significant technical contribution. Rather than exposing raw register values (as Modbus does) or opaque tag names (as raw MQTT does), OPC-UA servers expose typed objects with defined properties and methods. A pump in an OPC-UA server is not just a tag called "Pump1_Speed" - it is an object of type PumpType with properties for speed, flow, pressure, temperature, vibration, and motor current, each with defined data types, engineering units, and value ranges. This semantic richness enables client applications to reason about the data rather than just display it.

The OPC Foundation maintains companion specifications - standardized information models for specific industries and equipment types. The OPC-UA for EUROMAP (plastics machinery), OPC-UA for CNC (machine tools), OPC-UA for PackML (packaging), and OPC-UA for ISA-95 (manufacturing operations) companion specs define standard object models that any compliant device from any vendor must expose identically. This interoperability at the semantic level is something MQTT cannot deliver without application-layer conventions like Sparkplug B.

In 2018, the OPC Foundation published the Pub/Sub extension to OPC-UA, allowing OPC-UA data to be published and subscribed over message brokers rather than direct client-server connections. This extension can run over MQTT or AMQP as the transport layer, which began blurring the boundary between the two protocols - a topic explored in depth in the OPC-UA Pub/Sub section below.

MQTT vs OPC-UA: Head-to-Head Comparison

When to Use MQTT

MQTT is the correct protocol choice when your primary challenge is getting data from many geographically dispersed endpoints to a central platform efficiently. The protocol was born for constrained links and is a strong fit whenever bandwidth, endpoint count, or cloud integration are the dominant design constraints.

Remote RTUs and field devices sending telemetry to cloud are the canonical MQTT use case. An RTU polling a pressure transmitter and a flow meter at a wellhead every 30 seconds does not need the full OPC-UA session stack - it needs to publish a small payload to a broker and move on. The entire MQTT PUBLISH message for two analog values with timestamp and quality fits comfortably in under 100 bytes. The equivalent OPC-UA subscription setup involves session establishment, channel security negotiation, subscription creation, and monitored item configuration - appropriate overhead for a plant-floor PLC, excessive overhead for a battery-powered RTU on a cellular link with a monthly data cap.

Deployments with thousands of endpoints - oil and gas wellfields, utilities, smart grid infrastructure, water distribution networks - are where MQTT's pub/sub architecture pays the largest dividends. A single clustered MQTT broker can handle tens of thousands of concurrent connections and millions of messages per second. An OPC-UA server handling the same load would require careful scaling and is architecturally less suited to fan-out at that scale. SCADA monitoring for oil and gas operations in the Permian Basin is a perfect illustration: hundreds of wells, each an autonomous data source, aggregating into a single cloud dashboard.

Cloud-native architectures strongly favor MQTT. AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all provide managed MQTT brokers that accept device connections, apply routing rules, and deliver messages to downstream services (Lambda, Stream Analytics, Pub/Sub) with no additional integration layer. Building the same pipeline over OPC-UA requires an edge gateway, a protocol translator, and a custom integration - significantly more engineering work with no operational benefit.

When to Use OPC-UA

OPC-UA is the correct protocol choice when your primary challenge is integrating plant-floor devices with context-aware data into SCADA systems, historians, and MES platforms. The protocol's information modeling capabilities and native PLC support make it the standard for any application where data needs to carry semantic meaning, not just raw values.

Plant-floor PLC-to-SCADA communication is where OPC-UA has become the widely adopted successor to OPC Classic. Allen-Bradley CompactLogix and ControlLogix PLCs, Siemens S7-1200 and S7-1500 PLCs, and many other modern PLCs include a native OPC-UA server. An operator configuring a SCADA connection to a Siemens S7-1500 does not write a Modbus driver and map registers to tags - they browse the PLC's OPC-UA address space and subscribe directly to typed variables with engineering units already attached. The time savings are substantial; the error reduction from eliminating manual register-to-tag mapping is even more so.

Regulated industries requiring audit trails and security certificates have adopted OPC-UA as a compliance tool, not just a communication protocol. The built-in PKI certificate infrastructure, role-based access control, signed message audit logs, and granular permissions map directly onto requirements in FDA 21 CFR Part 11, NERC CIP, and the ISA/IEC 62443 series. The full protocol specification is maintained by the OPC Foundation. An OPC-UA server knows exactly which client read which value at what time, with cryptographic proof. Modbus knows nothing of the sort, and raw MQTT relies entirely on broker-level access control for any security posture.

MQTT Sparkplug B: The Best of Both Worlds?

Raw MQTT's biggest industrial weakness is what it deliberately omits: any definition of what a message contains, how data should be structured, or how devices should announce their presence and capabilities. Two MQTT-enabled devices from different vendors will publish data to completely different topic structures in completely different payload formats, and a subscriber must be pre-configured with knowledge of both to make sense of either. For consumer IoT, this is acceptable. For industrial SCADA integration, it is a significant interoperability problem.

MQTT Sparkplug B, originally developed by Cirrus Link Solutions and now an Eclipse Foundation open specification (Eclipse Sparkplug), solves this problem by defining a complete topic namespace, payload format, and device lifecycle model on top of standard MQTT. Sparkplug B requires no changes to the MQTT broker - it is a convention layer that transforms raw MQTT from a generic transport into an industrial-grade telemetry protocol.

Sparkplug B introduces several critical concepts. Birth certificates (NBIRTH/DBIRTH messages) are published when an Edge Node or Device comes online, advertising every metric the device will publish - name, data type, engineering unit, and current value - in a single protobuf-encoded message. Death certificates (NDEATH/DDEATH) are registered as MQTT Last Will messages and fire automatically when the device disconnects unexpectedly. This birth/death lifecycle enables automatic discovery of new devices on the SCADA platform with zero manual configuration - a device appears, publishes its birth certificate, and the SCADA system knows exactly what data to expect from it.

Sparkplug B uses Google Protocol Buffers (protobuf) for payload encoding, which provides a compact binary format with defined data types - integer, float, boolean, string, dataset - and eliminates the ambiguity of JSON or raw binary payloads. Data messages (DDATA) use report-by-exception: only metrics that have changed since the last report are included in each payload, dramatically reducing bandwidth consumption on stable processes.

Sparkplug B is natively supported across a wide range of edge gateways and SCADA platforms, which is a large part of why it has been widely adopted for industrial MQTT in North America. A SCADA server running a Sparkplug-aware MQTT engine can automatically discover Sparkplug B-compliant edge nodes, create tag structures matching each device's birth certificate, and begin trending data with no manual tag configuration - a workflow that would otherwise require hours of manual setup per device.

Sparkplug B's primary limitation compared to OPC-UA is information model depth. The Sparkplug specification defines a flat metric list with no concept of object hierarchy, relationships between metrics, methods, or the rich companion specification ecosystem that OPC-UA has built over a decade. A Sparkplug B birth certificate tells you what metrics a device has. An OPC-UA address space tells you what kind of device it is, how its components relate to each other, and what operations can be invoked on it.

OPC-UA Pub/Sub: OPC-UA Goes Cloud-Native

The OPC Foundation recognized OPC-UA's cloud-scale limitation and published the Pub/Sub extension in 2018 as Part 14 of the OPC-UA specification. Rather than requiring the client-server session model for every data delivery, OPC-UA Pub/Sub allows an OPC-UA server or edge device to publish data to a message broker - MQTT or AMQP - and any number of subscribers to receive it without maintaining a direct connection to the publishing device.

This architecture hybridizes the two protocols in a technically elegant way. The OPC-UA information model defines the data - types, engineering units, object relationships, quality codes - while MQTT provides the transport - broker-based fan-out, cloud platform integration, and scalability across thousands of endpoints. An OPC-UA Pub/Sub publisher at the plant floor can push structured, semantically rich data to an MQTT broker, which delivers it to cloud SCADA platforms, analytics engines, and digital twin systems simultaneously.

OPC-UA Pub/Sub messages can use either JSON or UA-Binary encoding. The JSON encoding is human-readable and easy to process in cloud services, while UA-Binary is more compact - approximately 30–50% smaller than the equivalent JSON payload for typical process data. Both encodings preserve the full OPC-UA data model including value, status code, and timestamps.

Despite its technical elegance, OPC-UA Pub/Sub remains less mature than native MQTT implementations in 2026. Vendor support is still inconsistent - some PLC vendors and OPC-UA stacks implement it fully, others support only subsets of the specification, and configuration tooling is less polished than native MQTT environments. For greenfield deployments where interoperability across vendors is a concern, Sparkplug B over native MQTT currently delivers a more predictable implementation experience. OPC-UA Pub/Sub is more compelling in architectures where OPC-UA is already deeply embedded and the goal is extending cloud connectivity without replacing the existing plant-floor integration layer.

Security: MQTT vs OPC-UA

Industrial cybersecurity is not an abstract concern - it is a critical operational risk. The 2021 Oldsmar water treatment attack, the Colonial Pipeline ransomware incident, and a steady stream of ICS intrusions have made protocol-level security a board-level conversation in industrial operations. MQTT and OPC-UA have very different security profiles, and the choice between them has direct implications for your ICS/OT security posture.

MQTT Security

MQTT's base specification provides no security - no authentication, no encryption, no authorization. This is a deliberate design choice for constrained devices where the overhead of TLS may be prohibitive. In practice, MQTT security is added as a layer on top: TLS encryption of the TCP connection, username/password credentials for broker authentication, and broker-level ACLs that control which clients can publish or subscribe to which topics. MQTT 5.0 enhanced the authentication flow with a multi-step challenge-response mechanism that supports more sophisticated authentication schemes including OAuth2 and SASL-based methods.

The security reality in production MQTT deployments is less reassuring. Shodan and similar scanners routinely discover internet-exposed MQTT brokers running without authentication - a configuration that exposes every subscribed topic to any anonymous client on the internet. Industrial deployments must enforce TLS and authentication at the broker configuration level, and operators must audit ACL configurations as device fleets grow. Broker clustering adds complexity to access control management that can introduce configuration drift if not carefully managed.

OPC-UA Security

OPC-UA was engineered with security as a first-class requirement, not an afterthought. Every OPC-UA session uses one of three defined security modes: None (no security, development only), Sign (messages are digitally signed to prevent tampering), or Sign & Encrypt (messages are both signed and AES-256 encrypted). The security mode is negotiated during session establishment, and production deployments should always use Sign & Encrypt.

Authentication in OPC-UA uses X.509 certificates managed through a PKI infrastructure. Each OPC-UA server maintains a certificate trust list and a certificate revocation list, and only clients presenting trusted certificates are permitted to establish sessions. This eliminates the username/password credential management problem and provides cryptographically verifiable identity. Role-based access control (RBAC), standardized in OPC-UA 1.05, allows server administrators to define fine-grained permissions: read-only operators, write-capable engineers, administrator-level configurators - all enforced at the protocol level regardless of the application accessing the data.

For ICS/OT environments, the air-gap vs cloud connectivity decision intersects with protocol security choice in an important way. A fully air-gapped OPC-UA network between PLCs and a historian carries minimal cybersecurity risk regardless of security mode - there is no internet path for an attacker to traverse. The moment you introduce cloud connectivity - MQTT to an external broker, OPC-UA Pub/Sub over the internet - the attack surface grows dramatically. A zero-trust network architecture, certificate-pinned MQTT connections to managed cloud brokers, and network segmentation between OT and IT are the operational controls that make cloud SCADA architectures defensible regardless of which protocol carries the data.

How Merobix Uses Both Protocols

At Merobix, we do not advocate for MQTT over OPC-UA or vice versa - we architect systems that use each protocol for what it does best, connected by intelligent edge gateways that bridge the plant-floor and cloud worlds.

Our typical architecture for an oil and gas customer follows a well-defined pattern. At the field device layer, legacy equipment communicates via Modbus RTU or Modbus TCP - protocols that are ubiquitous in RTUs, flow computers, and older PLCs that cannot be economically replaced. Newer PLCs expose their data natively over OPC-UA, providing structured, typed data with engineering units already defined. Understanding how Modbus works and its limitations is essential context for appreciating why the edge gateway layer matters.

At the edge gateway layer, a Merobix-configured edge device polls Modbus devices and connects as an OPC-UA client to OPC-UA-capable PLCs. The gateway normalizes all data into a unified tag model - applying engineering unit conversions, outlier filtering, and data quality tagging - then publishes the normalized data to our cloud platform over MQTT with TLS and certificate authentication. For customers using Sparkplug B-compatible edge devices, the Merobix cloud platform accepts Sparkplug B payloads directly, auto-discovering device tags from birth certificates.

At the cloud layer, the Merobix platform receives MQTT messages from the broker, stores time-series data in the historian, evaluates alarm conditions in real time, and serves dashboard data to operator browsers and mobile devices. This architecture gives operators the best of both protocols: the semantic richness and PLC interoperability of OPC-UA at the plant floor, and the cloud-scale delivery and low bandwidth overhead of MQTT for the wide-area link. Customers monitoring oil and gas operations in the Permian Basin with dozens or hundreds of distributed sites benefit specifically from this layered approach - high data fidelity from the field, efficient cellular transport to the cloud, and real-time visibility from any location.

This best-of-both architecture is increasingly recognized as the industry standard. The Industrial Internet Consortium (IIC) and OPC Foundation have both published reference architectures recommending OPC-UA for device integration and MQTT for cloud transport. The Unified Namespace (UNS) architecture, gaining adoption in smart manufacturing, formalizes this pattern: OPC-UA provides the information model, MQTT Sparkplug B provides the cloud transport, and the MQTT broker becomes the single source of truth for all plant and enterprise data consumers.

Frequently Asked Questions