OPC UA vs MQTT for IIoT: Choosing the Right Industrial IoT Protocol

TL;DR

OPC UA and MQTT are the two dominant protocols in industrial IoT, but they solve different problems. OPC UA provides a rich, self-describing data model with built-in security and is the standard for connecting to PLCs and industrial automation systems. MQTT is a lightweight publish-subscribe messaging protocol optimized for bandwidth-constrained environments and large-scale sensor networks. Many modern IIoT architectures use both — OPC UA at the edge for machine connectivity and MQTT (or cloud-native alternatives) for cloud ingestion.

Introduction

When designing an Industrial IoT system, one of the earliest and most consequential decisions is how devices will communicate with each other and with the cloud. Two protocols dominate the conversation: OPC UA (Open Platform Communications Unified Architecture) and MQTT (Message Queuing Telemetry Transport).

Both protocols are mature, widely supported, and actively developed. But they come from different worlds, solve different problems, and have different strengths. Choosing the wrong one — or using one where the other would be a better fit — can create unnecessary complexity, performance bottlenecks, or security gaps.

This article provides a practical, side-by-side comparison to help IIoT architects and engineering teams make an informed choice.

OPC UA: The Industrial Automation Standard

Background

OPC UA was developed by the OPC Foundation as the successor to the original OPC (OLE for Process Control) standard. Where classic OPC was tightly coupled to Microsoft Windows and COM/DCOM, OPC UA is platform-independent, running on Linux, embedded systems, and cloud servers alike.

OPC UA was designed specifically for industrial automation. It is the native communication protocol for most modern PLCs (Siemens S7-1500, Beckhoff TwinCAT, ABB, Rockwell, and others) and is endorsed by major industry organizations including the German VDMA, OMAC, and the AutomationML consortium.

Architecture: Client-Server (and Pub-Sub)

OPC UA's primary architecture is client-server. An OPC UA server runs on or alongside a machine, exposing its data points (called nodes) through a structured address space. Clients connect to the server, browse the available nodes, and either read values on demand or create subscriptions for change-based notifications.

OPC UA also supports a publish-subscribe mode (introduced in OPC UA Part 14) that enables UDP multicast and broker-based messaging, though this is less widely implemented than the client-server model.

Data Model: Self-Describing Information

OPC UA's most distinctive feature is its information model. Every data point is not just a value — it is a node in a typed, hierarchical structure that includes:

• Data type (integer, float, string, complex structures)
• Engineering units (kg, PSI, degrees C)
• Value range (min, max)
• Timestamp (source and server)
• Quality status (good, bad, uncertain)
• Relationships to other nodes (e.g., "this temperature sensor belongs to this reactor")

This self-describing model means a client can discover what data is available, what it means, and how it relates to other data — without any external documentation or configuration.

Security

OPC UA has security built into the protocol specification:

• Authentication: X.509 certificates for both client and server, plus optional username/password
• Encryption: AES-128 or AES-256 for message encryption
• Signing: RSA or ECC signatures for message integrity
• Security policies: Configurable combinations of signing and encryption
• Audit logging: Built-in audit trail for security events

When OPC UA Excels

• Connecting to PLCs, CNC machines, and industrial controllers
• Environments that require semantic data modeling (Industry 4.0, digital twins)
• Applications that need discovery — a client can browse the server and learn what is available
• Regulated industries where built-in security and audit capabilities matter
• Interoperability between equipment from different vendors on the factory floor

MQTT: The Lightweight Messaging Protocol

Background

MQTT was created in 1999 by IBM and Arcom (now Cirrus Link) for monitoring oil pipelines over unreliable satellite links. It was designed from the start to be lightweight, bandwidth-efficient, and resilient to intermittent connectivity.

MQTT became an OASIS standard in 2014 and has since become the de facto messaging protocol for IoT. It is used by AWS IoT Core, Azure IoT Hub, Google Cloud IoT, and countless open-source and commercial IoT platforms.

Architecture: Publish-Subscribe with a Broker

MQTT uses a publish-subscribe architecture mediated by a central broker. Devices (clients) publish messages to topics (hierarchical string paths like factory/line1/sensor42/weight). Other clients subscribe to topics and receive messages when they are published.

The broker handles all routing. Publishers and subscribers are completely decoupled — they do not need to know about each other, be online at the same time, or even speak the same data format.

Data Model: Bring Your Own

MQTT deliberately has no data model. A message payload is an opaque byte array. You can send JSON, Protobuf, Avro, SenML, CBOR, or raw binary. This flexibility is both a strength and a weakness:

• Strength: You can use whatever format best suits your application
• Weakness: There is no built-in way for a subscriber to discover what data is available or what a payload means without external documentation

Sparkplug B (an open specification from the Eclipse Foundation) adds a standardized data model on top of MQTT, addressing this gap for industrial applications.

Quality of Service

MQTT defines three QoS levels:

• QoS 0 (at most once): Fire and forget. Fast, no overhead, but messages can be lost.
• QoS 1 (at least once): Acknowledged delivery. Messages are guaranteed to arrive but may be duplicated.
• QoS 2 (exactly once): Four-step handshake ensures exactly-once delivery. Highest overhead.

This lets applications trade off reliability against bandwidth and latency based on the criticality of each message.

Security

MQTT relies on transport-layer security rather than application-layer security:

• TLS/SSL for encryption and server authentication
• Username/password or X.509 client certificates for client authentication
• ACLs (access control lists) on the broker for topic-level authorization

MQTT 5.0 added enhanced authentication with challenge-response flows, but the protocol itself does not define signing or encryption at the message level.

When MQTT Excels

• Large-scale sensor deployments (thousands or millions of devices)
• Bandwidth-constrained or high-latency networks (cellular, satellite, LoRaWAN)
• Edge-to-cloud data ingestion where simplicity and throughput matter
• Applications that need decoupled, event-driven communication
• Environments where devices connect and disconnect frequently

Side-by-Side Comparison

Choosing the Right Protocol

Use OPC UA When:

• You need to connect to PLCs or industrial controllers. If the equipment already speaks OPC UA (and most modern PLCs do), using OPC UA avoids the need for custom protocol adapters.
• Semantic data modeling matters. If your application benefits from self-describing data with types, units, and relationships (e.g., digital twins, MES integration), OPC UA's information model is a significant advantage.
• Security requirements are strict. OPC UA's application-layer security with mutual certificate authentication is stronger than MQTT's transport-layer approach, particularly in environments where the broker is a potential attack surface.
• You are building within the factory floor. For machine-to-machine communication within a plant network, OPC UA's client-server model with subscriptions provides efficient, real-time data exchange.

Use MQTT When:

• You are building edge-to-cloud data pipelines. MQTT's lightweight protocol and publish-subscribe model are ideal for moving sensor data from the factory floor to cloud platforms at scale.
• Bandwidth is limited. For cellular, satellite, or other constrained networks, MQTT's minimal overhead is a significant advantage.
• You have many heterogeneous devices. MQTT's simplicity means almost any device with a network stack can publish data — from a microcontroller to a full industrial gateway.
• You need high fan-out. When many consumers need to receive the same data (dashboards, analytics, alerting, archiving), MQTT's broker-based pub-sub model handles this naturally.

Use Both When:

Many modern IIoT architectures use both protocols in a complementary pattern:

1. OPC UA at the edge — An OPC UA client (connector) reads data from PLCs and automation systems on the factory floor.
2. Protocol translation at the gateway — The connector converts OPC UA data into a standardized payload format (e.g., SenML JSON) and publishes it to an MQTT broker or cloud message queue.
3. MQTT/cloud messaging for ingestion — The cloud platform receives the data via MQTT (or a cloud-native equivalent like Google Cloud Pub/Sub) for storage, processing, and analytics.

This pattern leverages OPC UA's strength in machine connectivity and MQTT's strength in scalable cloud ingestion. The gateway acts as a protocol bridge, and the cloud platform does not need to understand OPC UA at all.

Implementation Considerations

OPC UA Implementation

• SDK selection matters. OPC UA is a complex specification (14+ parts). Using a mature SDK (open62541, Eclipse Milo, Prosys, Unified Automation) is strongly recommended over implementing from scratch.
• Certificate management. Plan for certificate generation, distribution, renewal, and revocation. In production environments, this is often the most operationally challenging aspect.
• Subscription tuning. Publishing intervals, queue sizes, and sampling rates need to be tuned based on the data change rate and network capacity.

MQTT Implementation

• Topic design. A well-designed topic hierarchy (site/area/device/measurement) simplifies filtering, ACLs, and data routing. Plan this carefully before deployment.
• Payload standardization. Since MQTT does not enforce a data format, choose one early and stick with it. SenML, Sparkplug B, and custom JSON schemas are common choices.
• Broker sizing. The broker is a single point of throughput. Plan for the expected message rate, connection count, and retention requirements.
• QoS selection. Use QoS 0 for high-frequency, non-critical data (e.g., vibration samples). Use QoS 1 for measurements that must not be lost (e.g., batch weights). QoS 2 is rarely needed in practice.

How Relay Analytics Handles Protocol Diversity

Relay Analytics takes the complementary approach described above. The platform supports OPC UA connectivity through an edge connector that reads data from PLCs and automation systems, converts it to SenML format, signs the payload with HMAC for integrity verification, and publishes it to Google Cloud Pub/Sub for cloud ingestion.

From the platform's perspective, data arriving via an OPC UA connector is identical to data from a direct sensor hub — the cloud backend does not need to know or care which protocol was used at the edge. This means teams can mix OPC UA-connected machines and direct sensor hubs in the same deployment, viewing all data on the same dashboards and running the same analytics.

The approach also means the protocol choice is made at the edge, per device, without affecting the rest of the architecture. If you add a new PLC that speaks OPC UA, you deploy a connector. If you add a simple load cell with a serial output, you deploy a sensor hub. Both produce the same data format in the cloud.

Frequently Asked Questions

Can MQTT replace OPC UA entirely?

For edge-to-cloud data transport, yes — MQTT (or cloud-native messaging like Pub/Sub) is often a better fit. But MQTT cannot replace OPC UA for connecting to PLCs and automation systems that natively expose OPC UA servers. You would need a custom protocol adapter for each device type, which is exactly the problem OPC UA was designed to solve.

Is Sparkplug B a third option?

Sparkplug B is not a separate protocol — it is a specification layered on top of MQTT that adds a standardized topic namespace, payload encoding (using Protobuf), birth/death certificates for state management, and a defined data model. It brings some of OPC UA's data modeling strengths to the MQTT world, particularly for SCADA-like applications.

Which protocol has lower latency?

For raw message delivery, MQTT QoS 0 has the lowest latency — it is essentially a single TCP write. OPC UA subscriptions add session management overhead but can achieve sub-100ms publish intervals in well-tuned deployments. For most IIoT monitoring applications (sample rates of 1-60 seconds), both protocols deliver data faster than the display refresh rate.

Do I need a broker for MQTT?

Yes. Unlike OPC UA's client-server model where clients connect directly to servers, MQTT requires a broker to route messages between publishers and subscribers. Popular brokers include Mosquitto (open source), HiveMQ, EMQX, and VerneMQ. Cloud providers also offer managed MQTT endpoints (AWS IoT Core, Azure IoT Hub).

How do I handle security when using both protocols?

Each layer should handle its own security. OPC UA connections between the connector and PLCs use OPC UA's built-in certificate-based security. The connector-to-cloud link uses TLS for transport encryption plus application-level message signing (e.g., HMAC) for payload integrity. The cloud platform adds its own authentication and authorization layer. This defense-in-depth approach ensures no single layer failure compromises the entire system.

Next Steps

The protocol question is important, but it is ultimately a means to an end. The goal is to get reliable, well-structured sensor data from the factory floor into a platform where it can be visualized, analyzed, and acted upon. Whether that data travels over OPC UA, MQTT, or both, the value comes from what you do with it once it arrives.