OPC UA vs MQTT: Protocols for IIoT Gateways and Industrial Data

OPC UA vs MQTT is one of the most common protocol questions in industrial data integration, and the honest answer is that the two do different jobs. OPC UA is an industrial interoperability standard that describes machine data, with its meaning, types and structure, and lets software browse, read, write and call it securely. MQTT is a lightweight publish and subscribe messaging protocol that moves messages through a broker, with no opinion about what those messages contain.

That difference is why most connected plants end up using both. OPC UA sits close to the machines, where controllers and equipment from different makers need a common, self-describing model. MQTT carries the data north, from the IIoT gateway at the cabinet to plant systems and the cloud, often with the Sparkplug B specification adding the structure that plain MQTT leaves out. The point where the two meet is usually an edge computer that also has to talk Modbus, PROFINET or EtherNet/IP to older equipment.

This guide is the reference view. It explains how each protocol works, compares them row by row, shows where each sits between IT and OT, sets out the common gateway architectures and the security model, and sizes the hardware that runs them. For the wider picture of connected industry, start with our explainer on the industrial internet of things.

OPC UA (Open Platform Communications Unified Architecture) is published by the OPC Foundation and standardised as IEC 62541. It was first released in 2008 to replace OPC Classic, whose Data Access specification depended on Microsoft COM/DCOM and therefore on Windows. OPC UA runs on any operating system, from a small Arm gateway to a server, and its native binary protocol uses TCP port 4840 by default.

Client/server and the address space

In its classic form OPC UA is client/server. A server, often built into a PLC or running on a gateway, exposes an address space: a structured graph of nodes for objects, variables, methods and the references between them. A client connects, browses that graph and reads, writes or subscribes to what it needs. Variables carry metadata such as data type, engineering range, scaling and timestamps, so a value arrives with its meaning attached.

Information models and companion specifications

The real strength of OPC UA is information modelling. Types can be defined once and reused, so every pump, robot or packaging machine of a given kind can present the same structure. Industry groups publish these as companion specifications: OPC UA for Machinery, PackML, EUROMAP for plastics and rubber machinery, robotics, process automation devices and many more. A client written against a companion specification can, in principle, work with any conforming machine without a custom mapping. This is also what makes OPC UA a common foundation for a digital twin of an asset.

Beyond client/server: PubSub and FX

OPC UA is not only client/server. Part 14 of the specification, PubSub, lets a publisher send datasets to many subscribers without sessions, either over UDP (often on Time-Sensitive Networking for deterministic traffic between controllers) or through a broker using MQTT or AMQP, with a compact binary (UADP) or JSON encoding. Reverse Connect lets a server inside a protected network open the connection outwards to a client, which helps with firewalls. The OPC UA FX (Field eXchange) extensions take OPC UA towards controller-to-controller and field-level communication; adoption there is still early, and most deployments today use classic client/server.

Security built into the protocol

Every OPC UA application has its own X.509 application instance certificate. When a connection opens, client and server agree a security policy (for example Basic256Sha256 or the newer Aes256_Sha256_RsaPss) and a message security mode of None, Sign or SignAndEncrypt, then authenticate the user by anonymous login, user name and password, certificate or token. Certificates are trusted per application, and a Global Discovery Server can manage them across a site. The protocol defines all of this, so a correctly configured system is secure without extra layers; the catch is that certificate management has to be planned.

MQTT was designed in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper for monitoring oil pipelines over satellite links, where bandwidth was expensive and connections dropped. It is now an OASIS standard: version 3.1.1 (2014, also published as ISO/IEC 20922) and version 5.0 (2019). It runs over TCP/IP, on port 1883, or 8883 with TLS, and its smallest packet header is 2 bytes.

Broker, topics and publish/subscribe

Every MQTT client connects to a broker. A publisher sends a message to a topic, a text path such as site1/packing/line2/filler/temperature, and the broker forwards it to every client subscribed to that topic. Subscribers can use wildcards: + matches one level and # matches everything below. Publishers and subscribers never connect to each other and need not know each other exists, which is why adding a new consumer of plant data does not mean touching the machines.

Quality of service

MQTT offers three delivery levels, set per message. QoS applies to each hop, publisher to broker and broker to subscriber, and a subscriber can ask for a lower level than the publisher used.

Retained messages, last will and sessions

Three features matter in industrial use. A retained message is stored by the broker as the last known value on a topic and delivered to any new subscriber straight away. A last will and testament is a message the broker publishes on a client’s behalf if that client disconnects unexpectedly, which is how other systems learn that a gateway has gone offline. A persistent session keeps a client’s subscriptions and queued QoS 1 and 2 messages while it is disconnected, so it can pick up where it left off.

MQTT 5.0 added user properties (key and value metadata on each message), shared subscriptions for load balancing, message and session expiry, reason codes, topic aliases and a request and response pattern. What MQTT still does not define is the payload. A message can be JSON, a binary blob or a plain number, and two publishers can describe the same temperature in different ways. That gap is what Sparkplug B fills.

Sparkplug is an open specification, now run by the Eclipse Foundation, that defines how industrial devices and applications should use MQTT. Version 3.0 was published in 2022 and has since been adopted as the international standard ISO/IEC 20237. “Sparkplug B” refers to its payload format, which is the one in use today.

Sparkplug fixes three things that plain MQTT leaves open. The topic namespace is defined as spBv1.0/group_id/message_type/edge_node_id/device_id. The payload is encoded with Google Protocol Buffers, with each metric carrying a name, data type, timestamp and optional properties, and an alias so repeated messages stay small. And state is managed: every edge node announces itself with a birth certificate, registers a death certificate as its MQTT last will, and numbers its messages so a host can spot a gap and ask for a rebirth.

The result is MQTT that a SCADA host or historian can consume without a custom mapping for each device: it discovers metrics from the birth messages, knows when data is stale and can send commands back. The trade-off is that Sparkplug models are flatter than OPC UA information models, and both ends must support the specification.

The table compares OPC UA in its usual client/server form with MQTT, noting where Sparkplug B changes the picture. Both are mature, open and secure when configured properly; they differ in where they put the intelligence.

Read across the rows and a pattern appears. OPC UA puts the intelligence in the server: the data model, the security and the history live with the machine, and any client can ask for what it needs. MQTT puts it in the broker and the topic design: the protocol stays small, and the system around it decides what the data means. Neither is faster or more secure in every case. On a plant LAN both deliver values in milliseconds, and both can be locked down, or left open, by configuration.

Most sites describe their networks with the Purdue model, which the ISA-95 and IEC 62443 standards build on. Mapping the protocols onto it shows why they are complementary: OPC UA is strongest in the middle levels, where equipment has to be understood, and MQTT where data has to reach many consumers across a boundary.

The levels are a reference, not a rule. Many PLCs now publish MQTT directly, and OPC UA is used up to the cloud through PubSub. But the boundary between level 2 and level 3, where an edge computer collects from the controllers and passes data upwards, is still where most of the protocol conversion happens. Our comparison of HMI and SCADA covers the supervisory layer in more detail.

Does the system that reads the data need to understand the machine, or only receive its values? That question settles most protocol decisions. Make it per data flow, not once for the whole site.

Choose OPC UA when

Systems need a shared, self-describing model of the equipment: a SCADA or MES that must read and write set points, call methods, acknowledge alarms or pull history. OPC UA also suits equipment that already ships with an OPC UA server, machines covered by a companion specification, and controller-to-controller exchange where PubSub over TSN gives deterministic timing.

Choose MQTT when

Many consumers need the same data, links are limited or intermittent, or data has to cross from the plant to business systems or the cloud. Over 4G or 5G, the small packets, outbound connection and persistent sessions of MQTT are a good fit, and our guide to 5G at the edge covers the network side. Add Sparkplug B when the consumers are SCADA or historian software that should discover metrics and track device state on their own.

Why most sites use both

A typical pattern reads the PLC and machine servers over OPC UA, and the older equipment over Modbus or a fieldbus, at an edge gateway. The gateway normalises the data, adds context and publishes it over MQTT, usually with Sparkplug B, to a site broker. SCADA, the historian, MES, maintenance tools such as AI predictive maintenance and the cloud all subscribe from there. OPC UA keeps its role for tasks that need a session with the machine, such as writing recipes or acknowledging alarms.

The unified namespace

That broker-centred pattern is often called a unified namespace (UNS): a single, event-driven hub where every system publishes its current state into a topic tree organised along ISA-95 lines (enterprise, site, area, line, cell) and every other system subscribes to what it needs. A UNS is an architecture, not a standard or a product. It replaces many point-to-point links with one hub, but it does not remove the need for OPC UA at the machines or for an agreed data model in the topics, which is where Sparkplug B or a site’s own naming rules come in.

In practice the gateway is where protocols meet, and five patterns cover most deployments. Larger sites often combine them: protocol converters at the cabinets, an aggregation server or bridge per line, and an edge broker per site.

Protocol conversion from the fieldbus

Much of the data still comes from equipment that speaks neither OPC UA nor MQTT. Meters, drives and older PLCs often use Modbus RTU and Modbus TCP, with the serial version over RS-485; Siemens lines use PROFINET or S7, and Rockwell lines EtherNet/IP. A gateway reads these with polled drivers, so the poll rate and the number of registers per request set both the data freshness and the load on the device. Where a cabinet has no network-ready device at all, serial I/O modules and digital or analogue I/O bring the signals in.

Store and forward

A gateway that loses its uplink should not lose data. Store and forward means the gateway keeps publishing into a local queue on disk, with the original timestamps, and drains it in order when the connection returns. Sparkplug B supports this through the STATE message, which tells edge nodes when the primary host is offline so they can start buffering. OPC UA clients can instead backfill from a server’s historical access. Either way, size the local storage for the longest outage you plan to ride through.

Timestamps only help if the clocks agree. Synchronise gateways with NTP as a minimum, and with IEEE 1588 PTP where sequence of events matters across machines.

The IEC 62443 series is the reference for industrial cyber security. Its system-level parts group assets into zones with the same security needs and control the conduits between them; component requirements (IEC 62443-4-2) and the supplier’s development process (IEC 62443-4-1) apply to the equipment itself. Choosing protocols and hardware with the right security features can support that work, but compliance depends on the whole system and how it is operated.

OPC UA: use the security that is already there

OPC UA security fails most often by being switched off. Disable the None security mode and anonymous access on production servers, use current policies such as Basic256Sha256 or Aes256_Sha256_RsaPss, and decide before go-live who issues and trusts application certificates and how they are renewed. On larger sites a Global Discovery Server takes much of that work off individual devices.

MQTT: secure the broker and the connection

An MQTT deployment is as secure as its broker configuration. Require TLS on port 8883, authenticate every client by certificate or strong credentials, and give each client access only to the topics it needs, with publish and subscribe rights set separately. Because MQTT clients always connect outwards to the broker, a gateway in the OT zone needs no inbound firewall openings, which makes MQTT straightforward to route through a DMZ.

Hardware and network measures

Certificates and private keys are safer in a TPM 2.0 module than in a file on disk, and Secure Boot stops modified firmware or operating systems from starting. Two LAN ports let a gateway sit on separate OT and IT networks, but dual-homing is not segmentation on its own: disable IP forwarding, firewall both interfaces and keep VLANs and access lists on managed switches in the design. Our guide to managed vs unmanaged industrial switches covers the switching side. Remote sites benefit from out-of-band management so a gateway can be recovered without a site visit.

Protocol software is light compared with vision or AI, so most gateways are sized by tag count, update rate, local storage and the number of services they run, not by raw processing power. The table gives typical starting points; the right build depends on your devices, software stack and site.

A worked storage example

Say a gateway collects 2,000 tags that each change once a second, and stores each value with its timestamp and quality in about 50 bytes. That is 100 kB a second, or about 8.6 GB a day if the uplink is down. A week of buffering needs about 60 GB, which is beyond the eMMC on most small Arm gateways but comfortable on an NVMe SSD. Report by exception and deadbands usually cut the real figure a long way, so measure your own change rates before you size storage.

What else to check

Memory matters more than cores for a broker with many retained topics, persistent sessions or a local historian. Check the ports: enough isolated serial ports for Modbus RTU, two or more LAN ports for separate networks, and 4G or 5G where there is no wired uplink (our guide to 4G and 5G cellular computers covers modules and antennas). Check the environment: the industrial temperature range at the worst-case cabinet ambient, a wide DC input that matches the cabinet supply, and SSDs with power loss protection where power can drop without warning. Our articles on DIO vs GPIO and fog and edge computing go further on I/O and on where processing belongs, and our IoT edge gateway case study shows fanless gateways relaying machine data to a maintenance service.

Our wider ranges of industrial IoT gateways and data acquisition and I/O modules cover more processor, port and cellular combinations, and managed industrial switches handle the network segmentation. We configure every gateway with the operating system, protocol software, certificates and any cellular module you specify, then test it before it ships.