Most plants we walk into have the same problem. The controllers on the floor work, some of them for decades, and nobody wants to touch them. Meanwhile the business wants that data in the cloud for dashboards, maintenance planning and AI. The question that usually comes next is OPC UA vs MQTT: which one should we standardize on?
It’s the wrong question, but it’s an understandable one. The two solve different problems, and the best architectures use both. Here’s how we think about it when we design plant-floor connectivity for manufacturers, utilities and the controls integrators who serve them.
What is OPC UA?
OPC UA is an industrial interoperability standard from the OPC Foundation. Its classic mode is client/server: an OPC UA server runs on or next to a PLC, and clients such as SCADA, historians or gateways browse it and read, write or subscribe to values.
What makes the OPC UA protocol valuable isn’t the transport. It’s the information model. A tag isn’t just a number at an address; it’s a node with a type, engineering units, relationships and metadata, and companion specifications define standard models for whole classes of equipment. A client can discover what a machine is, not just what register 40001 holds.
The tradeoffs: client/server is a point-to-point, poll-or-subscribe pattern that works best inside a plant network. Pointing cloud services directly at OPC UA servers on the floor means opening inbound paths to OT, which is exactly what you don’t want.
What is MQTT, and what does an MQTT broker do?
MQTT is a lightweight publish/subscribe transport. Devices don’t talk to each other; they publish messages to topics on an MQTT broker (also called an MQTT server), and anything interested subscribes. Publishers and consumers never need to know about each other.
That decoupling is why MQTT dominates edge-to-cloud links. Connections are initiated outbound from the site, it tolerates flaky cellular and satellite links, and one published value can feed a historian, a cloud service and an analytics team at once.
The catch is that plain MQTT says nothing about what the payload means. Topic names and JSON shapes are whatever someone decided, and across a few plants and integrators that turns into chaos.
Common brokers include Eclipse Mosquitto (the usual choice when people search for a small, open-source mosquitto mqtt broker), EMQX and HiveMQ, which add clustering, enterprise authentication and management at scale. All three implement the standard; the choice comes down to scale, high availability, support model and how you operate it.
OPC UA vs MQTT: when to use which
| Need | Better fit | Why |
|---|---|---|
| Rich, self-describing machine data inside the plant | OPC UA client/server | Information models, browsing, standard equipment types |
| Reading many PLCs from SCADA or a historian on the OT network | OPC UA client/server | Mature, widely supported by controllers and HMIs |
| Moving data from many sites to the cloud | MQTT | Outbound connections, low bandwidth, one-to-many |
| Unreliable links (cellular, satellite, remote assets) | MQTT | Session persistence, QoS, small overhead |
| Standard semantics over a pub/sub transport | OPC UA PubSub over MQTT or Sparkplug B | Meaning plus decoupling |
| Writing setpoints or commands to equipment | OPC UA (on-site), carefully gated | Typed methods, access control, stays inside OT |
| Plant-wide event backbone shared by many apps | MQTT broker as a Unified Namespace | Single source of current state, consumers subscribe |
The short version: OPC UA is the language, MQTT is the delivery route. Inside the fence, OPC UA client/server is usually right. Crossing the fence, MQTT is usually right.
OPC UA PubSub over MQTT and Sparkplug B
You don’t have to choose between semantics and transport. Two approaches carry structure over MQTT.
OPC UA PubSub is part of the OPC UA specification and defines how OPC UA data, with its information model, is published over brokers including MQTT. It fits well when your equipment and software already speak OPC UA and you want to keep that richness end to end.
Sparkplug B is an Eclipse Foundation specification that defines MQTT topic structure, payload encoding and state management, including birth and death messages so consumers know when an edge node or device goes offline. It’s popular with SCADA-centric teams that want plug-and-play MQTT without designing their own conventions.
We pick based on the systems already in place and who will maintain it. Mixing both is fine as long as each topic tree has one owner and one convention.
Where Unified Namespace fits
Unified Namespace (UNS) is an architecture pattern, not a product: an MQTT broker becomes the single place where the current state of the business is published, organized by a hierarchy such as enterprise, site, area, line and cell. ERP, MES, historians, dashboards and AI models subscribe instead of building point-to-point integrations with each PLC.
A UNS succeeds or fails on governance: naming, payload conventions, who can publish where, and versioning. The broker is the easy part. If you’re evaluating a UNS, spend your first weeks on the namespace design and access rules, not on broker benchmarks.
The edge gateway pattern: keep your PLCs, add a gateway
This is how most plants get data to the cloud without ripping anything out. An industrial IoT gateway sits at the boundary between the controls network and the outside world:
- Southbound, it reads from what’s already there: OPC UA servers, and legacy Modbus TCP, Modbus RTU and serial devices that will never speak OPC UA. Modbus to MQTT translation, with mapping into a proper model, happens here.
- Northbound, it publishes over MQTT with TLS to a site or cloud broker.
- Outbound-only. The gateway initiates every connection. No inbound firewall ports into OT, no VPN from the cloud into the plant.
- Store-and-forward. When the WAN drops, the gateway buffers locally and replays in order once the link returns, so you don’t get gaps in the historian.
- Read-only by default. Writes to equipment are a separate, deliberately designed path with its own approvals, if they exist at all.
The OPC Foundation’s timing here is useful. In September 2026 it released an open-source Cloud Initiative Reference Solution under the MIT license. It turns the Foundation’s cloud reference architecture into a deployable stack that combines OPC UA Client/Server, OPC UA PubSub, MQTT and REST, with components such as UA Edge Translator for connecting devices that don’t natively support OPC UA and UA Cloud Publisher for data transport. The Foundation says it can run on standard Linux systems, industrial PCs or low-cost industrial edge gateways. It’s a good, vendor-neutral starting point for prototyping exactly this pattern.
Separately, on Sept. 30 the OPC Foundation and Avnu Alliance announced a collaboration on testing and certification of OPC UA FX over Time-Sensitive Networking. That’s about deterministic communication at the field level rather than cloud links, but it’s another sign that OPC UA is extending from the controller down to the network, while MQTT carries data out of the plant.
Security: certificates, no inbound ports, and the new NIST draft
Connecting OT to the cloud is a security architecture decision first. The baseline we design to:
- Mutual TLS with per-device certificates for every gateway-to-broker connection, plus OPC UA’s own application certificates and signed, encrypted sessions on the plant side. No shared passwords baked into images.
- No inbound ports into OT. Gateways sit in a DMZ or conduit and dial out.
- Least-privilege topic access. Each gateway can publish only to its own branch of the namespace and subscribe to nothing it doesn’t need.
- Zones and conduits as described in ISA/IEC 62443, so the gateway is a defined, monitored crossing point.
- Certificate lifecycle planned up front: issuance, rotation and revocation across hundreds of devices.
NIST published the initial public draft of SP 800-82 Rev. 4, Guide to Operational Technology Security, on Sept. 21, 2026, with comments due Nov. 30, 2026. The revision expands its coverage to include IIoT and cloud convergence, restructures around the NIST Cybersecurity Framework 2.0, and adds security architecture guidance focused on protecting system management functions and applying zero trust principles. If you’re designing an edge-to-cloud path now, it’s worth reading the draft alongside 62443, and commenting if your environment isn’t well represented.
Landing the data in the cloud
Once data flows over MQTT, the cloud side is about modeling and storage, not protocols.
- AWS IoT SiteWise collects, organizes and models industrial equipment data at scale, with asset models that map well to an OPC UA or UNS hierarchy.
- Azure IoT Operations runs at the edge on Kubernetes with an MQTT broker and OPC UA connectivity, then sends data to Azure services.
Whichever you choose, keep your namespace and models portable. If your topic tree and asset models are your own, switching clouds or adding a second one is a data pipeline change, not a re-instrumenting project.
How we’d approach it
When a plant or integrator brings us in, we typically start with a short assessment: inventory the controllers and protocols, decide where OPC UA, Sparkplug B or plain MQTT fits, design the namespace, and stand up one line or one site with an outbound-only gateway, store-and-forward and certificate-based security. Then we scale it out.
That’s the core of our IoT product development work. For remote assets on cellular or satellite links, see our connectivity practice and our post on same-SIM satellite IoT. If the goal is vision or AI at the line, our edge AI and computer vision team works from the same gateway foundation. When you’d rather bring in a specialist team than staff up, we wrote about when that makes sense.
Keep the PLCs. Add a gateway. Let OPC UA describe the data and MQTT move it.
If you’re working out how to get plant-floor data into the cloud, book a call and we’ll walk through your controllers, network and goals.
