IIoT · 7 min read · Updated June 2026
OPC UA vs MQTT: Getting Plant Data to IT Without Regret
The two protocols dominating IIoT data movement solve different problems. When to use each, when to use both, and the architecture that keeps OT secure while IT gets the data it wants.
Every IIoT project reaches the same fork: push plant data with MQTT, or expose it with OPC UA? The honest answer is that they solve different problems, and most mature architectures use both.
OPC UA: the structured, request-driven standard
OPC UA is a client/server (and, with PubSub, publish/subscribe) standard with a rich information model: every variable has a data type, engineering units, ranges and a place in a browsable address space. Security — authentication, signing, encryption — is built in. Modern PLCs run an OPC UA server natively: the S7-1200 from firmware V4.4, S7-1500, Omron NJ/NX, and CODESYS controllers such as the WAGO PFC200. SCADA, MES and historians read from it directly.
Strengths: self-describing data, standard semantics (companion specifications for machines, pumps, vision), strong security, no broker to operate. Weaknesses: heavier on small devices, request/response does not scale to thousands of publishers over unreliable WAN links.
MQTT: the lightweight, event-driven transport
MQTT is a tiny publish/subscribe protocol: devices publish messages to topics on a broker; consumers subscribe. It is designed for unreliable, low-bandwidth links, supports store-and-forward at the client, and a single broker fans data out to any number of consumers without touching the PLC. Edge devices such as the Moxa UC-2112 and the PFC200 publish Modbus or OPC UA data to MQTT with little configuration.
Strengths: minimal overhead, decouples producers from consumers, works over cellular. Weaknesses: MQTT itself says nothing about payload meaning — "temperature" could be a string, a JSON object or a float — unless you adopt a payload specification such as Sparkplug B.
When to use which
| Need | Use |
|---|---|
| SCADA/MES reading PLC data on the plant LAN | OPC UA directly from the PLC |
| Many sites or machines sending data to a central platform | MQTT via edge gateway, Sparkplug B payloads |
| Remote sites over cellular | MQTT with store-and-forward |
| Vendor machine with a standard information model | OPC UA (companion spec) |
| Cloud analytics platform | MQTT into the platform's broker |
| Both of the above | OPC UA on the plant floor, MQTT northbound from the edge |
The architecture that avoids regret
- Keep OPC UA inside the OT zone. PLCs expose data; an edge gateway or OPC server in the supervisory network reads it.
- Publish northbound with MQTT from the edge, through the DMZ, to a broker you control. The PLC never talks to the internet.
- Adopt a payload standard on day one (Sparkplug B or your own documented JSON schema with units and timestamps). Retrofitting meaning onto two years of unlabeled topics is painful.
- Store-and-forward at the edge, so a link outage does not create gaps in the historian.
- Secure both: certificates on OPC UA, TLS and client certificates on MQTT, and segmentation as described in OT network segmentation.
We design and commission edge architectures end to end — PLC OPC UA configuration, edge gateway, broker and dashboards — see engineering services. Related: IIoT edge gateway basics.
Need engineering help with this?
Our engineers apply this to real projects every week — selection, specification, commissioning. Send your question or a part number.
Quick answers
Which PLCs have an OPC UA server built in?
Siemens S7-1200 (firmware V4.4+) and S7-1500, Rockwell ControlLogix 5580 and CompactLogix 5380 (recent firmware), Omron NJ/NX, Schneider M262/M580 and most CODESYS controllers such as the WAGO PFC200. Older CPUs need an edge gateway or an OPC server PC.
Is MQTT secure enough for plant data?
With TLS, client certificates and a broker inside your DMZ or private cloud, yes. Plain MQTT on port 1883 with no authentication is not — treat it like Modbus and keep it inside the OT zone.