Every infrastructure IoT project eventually arrives at the same crossroads: MQTT or OPC UA? The two are the dominant industrial communication protocols of the 2020s — and they were not designed for the same job. MQTT was authored in 1999 by Andy Stanford-Clark at IBM and Arlen Nipper at Eurotech, specifically to monitor oil pipelines via satellite link inside a SCADA control system. The goal was bandwidth efficiency, lightweight code, and minimal battery drain — and that lineage is still visible in every MQTT deployment today. OPC UA emerged seven years later from the OPC Foundation as the IEC 62541 international standard, designed to deliver cross-platform, secure, semantically rich data exchange from sensors all the way to ERP-level enterprise applications, with standardised information models for over 60 types of industrial equipment. Engineers asking "which one" are usually asking the wrong question — the right one is "which one for which layer". For a wind-farm telemetry feed running over 4G to a cloud platform, MQTT wins on every metric that matters. For a controlled, type-safe data exchange between a refinery DCS and an enterprise asset-management system, OPC UA wins by a wider margin. Infrastructure architects that schedule a demo are finding the modern answer is increasingly both: MQTT at the edge, OPC UA at the control layer, bridged through a converged platform. This article walks through the real technical differences — latency, security, semantics, scalability, deployment cost — and shows when each protocol is the right answer for an infrastructure IoT project.
Stop Forcing One Protocol on Every Sensor.
iFactory bridges MQTT and OPC UA into a unified infrastructure data fabric — purpose-built for transport authorities, utility operators, manufacturing plants, and smart-city programmes running mixed-protocol estates.
1999
MQTT Authored at IBM for SCADA Pipeline Monitoring Over Satellite
IEC 62541
OPC UA's International Standard for Cross-Platform Industrial Data
60+ Models
Standardised Equipment Information Models in OPC UA Companion Specs
Pub/Sub
Native Messaging Pattern Shared by Both Protocols in Modern Versions
1. Why Both Protocols Exist — They Were Built for Different Problems
MQTT was created in 1999 to solve a single, specific problem: how to push telemetry data from oil-pipeline sensors over an extremely expensive satellite link into a SCADA control system. The protocol's design priorities followed from that constraint — small code footprint, minimal bytes on the wire, low battery consumption, tolerance of intermittent connectivity. Every modern MQTT design decision still bears the fingerprint of that pipeline use case. It is a thin publish-subscribe layer on top of TCP/IP, requires a message broker, and assumes the application above it knows what the data means.
OPC UA emerged from a different lineage. The OPC Foundation built it as the successor to the Windows-only OPC Classic stack — designed not just to move data but to describe what the data is. OPC UA carries an information model with every transaction, defining whether a value is a temperature in degrees Celsius, a flow rate in litres per second, or a vibration spectrum from a specific motor type. It is platform-independent, runs on Windows and Linux, supports both client-server and publish-subscribe patterns, and is mappable to TCP/IP, UDP/IP, WebSockets, AMQP, and even MQTT itself. Infrastructure architects that book a demonstration see both protocols running in a converged dataflow on their own estate.
2. The Honest Head-to-Head — Eight Dimensions That Actually Matter
Each protocol has a sweet spot. The matrix below compares them head-to-head on the parameters infrastructure architects actually weigh — without marketing spin.
Origin & Lineage
IBM & Eurotech, 1999. SCADA over satellite.
OPC Foundation, 2006. IEC 62541.
Message Pattern
Publish-subscribe via broker.
Client-server & pub-sub native.
Transport
TCP/IP. Small footprint.
TCP/IP, UDP/IP, WebSockets, AMQP, MQTT.
Data Semantics
Raw payload — application defines meaning.
Built-in information model — self-describing.
Equipment Models
None — bring your own JSON schema.
60+ standardised Companion Specifications.
Security
TLS + auth at broker. Topic-level ACL.
X.509, tokens, encryption, auth, audit.
Resource Footprint
Tiny — runs on 8-bit MCUs.
Heavier — gateway-class hardware.
Ideal Use
Edge telemetry, cellular, scale.
Control-layer interop, plant-to-ERP.
3. Where MQTT Genuinely Wins on an Infrastructure Project
MQTT's lineage in pipeline telemetry is not a historical footnote — it is exactly why MQTT dominates in any infrastructure scenario shaped by similar constraints. Bandwidth-limited links (cellular, LoRaWAN, satellite). Battery-powered or low-power sensors. Many endpoints to one broker. Intermittent connectivity. Tolerance of small lossy data. The published-and-forgotten payload model. In all of these, MQTT is faster to develop, cheaper to operate, and easier to scale than OPC UA. A single MQTT broker routinely handles tens of thousands of concurrent edge devices on commodity infrastructure — a scale that OPC UA, designed for richer per-message semantics, was simply not optimised to deliver.
A
Edge sensor networks at scale
Smart-city street furniture, water-meter networks, fleet telematics, wind-farm turbine monitoring. Thousands of low-power endpoints reporting to a central broker over cellular or LoRaWAN.
B
Cellular & satellite-backed deployments
Remote substations, pipeline pressure sensors, offshore platforms. MQTT's tiny per-message overhead translates directly into lower data-plan costs and longer battery life.
C
Cloud-bound telemetry pipelines
AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ, EMQX — every major cloud platform speaks MQTT natively. The default protocol for sensor-to-cloud architectures.
D
Greenfield infrastructure IoT
New asset classes (EV chargers, micro-mobility, smart bins) with no legacy OT installed base. Faster MVP, smaller team, lower licensing cost, well-trodden cloud integration path.
4. Where OPC UA Genuinely Wins on an Infrastructure Project
OPC UA's strength is exactly what MQTT lacks: semantics, security, and the standardised data models that make plant-floor-to-enterprise interoperability possible without writing custom translators for every device. OPC UA's information model means a temperature reading from a Siemens PLC, a Rockwell PLC, and a Schneider PLC arrive at the receiver with consistent type, unit, range, and engineering metadata attached. The OPC Foundation's Companion Specifications cover 60+ classes of industrial equipment, from injection-moulding machines to weighing scales to building HVAC. That depth of standardisation is why OPC UA is the dominant protocol when the requirement is interoperability across vendors, not just data movement.
A
Plant-floor multi-vendor interop
PLCs, RTUs, DCS, drives, and instruments from different vendors exchanging data with consistent semantics. The reason most discrete and process manufacturers adopt OPC UA at the control layer.
B
Plant-to-MES and plant-to-ERP
Lifting operational data from PLC/SCADA layer into MES, ERP, and asset-management systems with full type information. Production data arrives at SAP or Maximo ready for analytics, not a parsing project.
C
Security-critical industrial estate
X.509 certificates, configurable security profiles, encryption, authentication, authorisation, message-level auditing. The expected baseline for substations, refineries, and water-treatment OT networks.
D
Asset registers requiring strict typing
Where downstream analytics, digital twins, or compliance audits need provably-typed, vendor-neutral data. OPC UA Companion Specifications carry that typing without custom code.
5. The Modern Answer — A Hybrid Architecture, Not a Single Choice
Production infrastructure deployments increasingly run both protocols in a layered stack. Edge sensors and remote endpoints publish over MQTT to a regional broker. The broker's payloads are normalised against OPC UA Companion Specifications by a gateway, then exposed to enterprise applications as type-safe OPC UA data. The same pattern works in reverse: an OPC UA server in a plant exports selected data to an MQTT bridge for cloud analytics. Modern OPC UA's native publish-subscribe binding can even ride directly on top of MQTT, blending OPC UA's semantics with MQTT's transport efficiency — the protocol mappings are part of the IEC 62541 specification.
L1
Sensor Layer (MQTT)
Battery-powered field sensors, cellular endpoints, LoRaWAN devices. Publish-only, lightweight, tiny code footprint. JSON or MessagePack payloads.
L2
Aggregation Broker (MQTT)
EMQX, HiveMQ, AWS IoT Core, or Azure IoT Hub. Topic-based routing. TLS encryption. Topic-level access control for tenant separation.
L3
Semantic Gateway
Normalises MQTT payloads against OPC UA Companion Specifications. Adds engineering units, type information, and asset-identifier metadata.
L4
Control Layer (OPC UA)
PLCs, DCS, RTUs, and SCADA platforms exposing data over OPC UA. X.509 certificate-based authentication. Vendor-neutral information models.
L5
Enterprise Layer (OPC UA)
MES, ERP, EAM, and analytics platforms consume the typed data. SAP PM, IBM Maximo, Bentley AssetWise — all increasingly speaking OPC UA natively.
L6
Cloud Analytics (MQTT)
High-volume historised data bridged back to cloud MQTT for fleet-wide analytics, ML training, and dashboarding — bandwidth-efficient at scale.
6. Choosing the Right Protocol for the Job — Decision Guide
The right choice depends on what the data is for, where it's coming from, and what consumes it. The decision table below maps common infrastructure IoT scenarios to the protocol that wins on practical operational metrics.
| Infrastructure Scenario |
Network Profile |
Best-Fit Protocol |
Why |
| Remote pipeline telemetry |
Cellular / satellite |
MQTT |
Bandwidth-efficient by design |
| Substation control interop |
Wired industrial LAN |
OPC UA |
Strong typing & certificates |
| Smart water meter network |
LoRaWAN / cellular |
MQTT |
Low-power, broker-based scale |
| Refinery DCS to ERP |
Wired plant network |
OPC UA |
Self-describing semantics |
| Wind farm SCADA |
Mixed wired + cellular |
Both — layered |
OPC UA in plant, MQTT to cloud |
| Smart-city street furniture |
Cellular / NB-IoT |
MQTT |
Tiny payload, massive fan-in |
| Building HVAC & energy |
Wired BMS network |
OPC UA |
BACnet-OPC UA mappings standardised |
| Fleet telematics |
Cellular |
MQTT |
Cloud-native, mobility-friendly |
7. Five Deployment Realities Every Infrastructure Architect Hits
01
"Which one" is the wrong question
Mature infrastructure platforms run both. MQTT at the edge for telemetry scale and cellular efficiency; OPC UA at the control and enterprise layers for type safety and interoperability. The bridge between them is where most real architecture work happens.
02
Security model matters more than protocol choice
Both protocols can be deployed securely or insecurely. MQTT over TLS with proper broker authentication is solid; MQTT on port 1883 with no auth is an attack surface. OPC UA with proper X.509 certificate management is excellent; OPC UA in "None" security mode is dangerous. The configuration is more important than the protocol.
03
OPC UA's information model is the unique differentiator
Anyone can push bytes over either protocol. What OPC UA's 60+ Companion Specifications give you that MQTT does not is a vendor-neutral standard for what those bytes mean — at the type, unit, range, and engineering-metadata level. That is what enables true multi-vendor interoperability.
04
Brokers and gateways are the real architecture decisions
Which MQTT broker (EMQX, HiveMQ, Mosquitto, AWS IoT Core), which OPC UA stack (Unified Automation, Prosys, open62541, vendor-bundled), and which bridge between them — these choices dominate operational cost and reliability far more than the protocol-versus-protocol question.
05
OPC UA over MQTT is the converging future
The IEC 62541 specification already includes mappings of OPC UA's publish-subscribe binding onto MQTT transport. This combines OPC UA's semantics with MQTT's lightweight delivery — and is increasingly adopted for cross-domain industrial-cloud architectures. Plan for it; don't bet against it.
MQTT vs OPC UA for Infrastructure IoT — Frequently Asked Questions
Tap any question to reveal the answer.
Is MQTT secure enough for critical infrastructure?+
Yes, when deployed correctly. MQTT itself does not define security primitives, but the standard pattern — TLS-encrypted connections on port 8883, broker-level username and password or client certificate authentication, and topic-level access control lists — is well established in production deployments across utilities, transport, and manufacturing. The risks come from misconfiguration: brokers exposed on unencrypted port 1883, missing authentication, or wide-open topic ACLs. The protocol is widely used in critical industries (it was originally designed for SCADA pipeline monitoring), but the deployment configuration determines whether a given system is actually secure.
Book a demo to see hardened MQTT and OPC UA deployment patterns on a representative architecture.
Why does OPC UA seem heavier and more complex than MQTT?+
Because it does more. MQTT moves opaque payloads — the application above the protocol decides what the bytes mean. OPC UA carries an information model with every transaction, describing the type, unit, range, and engineering semantics of the data. Add certificate-based authentication, message-level signing and encryption, 60+ standardised equipment Companion Specifications, address-space navigation, and historical access, and the protocol layer is genuinely heavier than MQTT — because the functionality is broader. The trade-off is real: OPC UA needs gateway-class hardware where MQTT runs on 8-bit microcontrollers, but in exchange you get standards-based interoperability that MQTT does not natively provide.
Can a single project use both protocols?+
Yes — and most mature deployments do. The standard architecture runs MQTT at the edge (where bandwidth, battery, and scale matter most), OPC UA at the control and enterprise layers (where type safety and multi-vendor interoperability matter most), and a semantic gateway between them. Modern OPC UA can also ride directly on top of MQTT transport — the IEC 62541 specification includes a publish-subscribe binding that maps OPC UA data onto MQTT messages, blending OPC UA's semantics with MQTT's lightweight delivery. The "which protocol" debate is steadily resolving into "both, layered correctly".
Which protocol do major cloud platforms support natively?+
Every major cloud IoT platform supports MQTT natively — AWS IoT Core, Azure IoT Hub, Google Cloud IoT, IBM Watson IoT, HiveMQ Cloud, EMQX Cloud. This is the default protocol for sensor-to-cloud architectures, and it is the dominant reason MQTT has displaced legacy protocols in greenfield IoT projects. OPC UA cloud support is growing but more often runs as an OPC UA Server inside the plant exposing data to a gateway that bridges to the cloud's MQTT or HTTPS ingestion endpoint. For pure cloud-bound telemetry, MQTT is the path of least resistance. For plant-to-cloud architectures that need typed industrial semantics, OPC UA at the plant plus a bridge to MQTT for cloud transport is the standard pattern.
What about latency — which one is faster?+
For raw payload delivery on a lightly loaded network, both protocols can deliver messages in single-digit milliseconds. MQTT has lower per-message overhead and is typically faster for high-volume telemetry at scale. OPC UA in client-server mode introduces additional handshakes for session management, certificate exchange, and address-space lookups — useful features that cost milliseconds. For control-loop applications requiring deterministic sub-millisecond response, neither protocol is the right answer — those scenarios need EtherCAT, PROFINET IRT, or OPC UA over TSN (Time-Sensitive Networking), a specialised industrial deterministic stack. For typical infrastructure telemetry and monitoring, both protocols are operationally fast enough; the protocol choice is driven by semantics, security, and scale — not raw latency.
How does iFactory bridge MQTT and OPC UA across our existing estate?+
iFactory acts as the converged data fabric between both protocols, eliminating the need to standardise prematurely on either one. The platform ingests MQTT topics from edge brokers (EMQX, HiveMQ, AWS IoT Core, Azure IoT Hub, Google Cloud IoT) and OPC UA from plant servers (Siemens, Rockwell, Schneider, ABB, vendor-bundled stacks), normalises the data against OPC UA Companion Specifications, and exposes a unified API to downstream EAM, ERP, MES, and analytics platforms via standard REST and OPC UA endpoints. Existing brokers, PLCs, and OPC UA servers continue to operate untouched — iFactory layers on top of your existing IoT and OT stack, with typical integration completed in 4–8 weeks.
Bridge MQTT and OPC UA Into One Infrastructure Data Fabric.
iFactory normalises edge MQTT telemetry and plant OPC UA data into a unified, typed, secure information layer — feeding EAM, ERP, MES, and analytics platforms across multi-protocol estates.
