Both protocols appear on every IIoT architecture diagram. Picking the wrong one costs you in ways that don't show up until you're in commissioning. Here's how to decide.
The OPC-UA vs MQTT question comes up on almost every industrial IoT project. Both are mature, both have strong ecosystem support, and both get recommended by vendors who are selling one of them. The honest answer is that they solve different problems. Choosing between them starts with being specific about what you're actually building and where it will run.
The wrong choice isn't always immediately visible. It typically surfaces during commissioning when the consuming application can't interpret the data structure without documentation that doesn't exist, during the first security audit when the protocol's access control model doesn't match the plant's zone requirements, or during scale-up when broker architecture assumptions that worked at 50 devices fall apart at 500.
Getting this decision right at the start of a project costs nothing. Getting it wrong costs an integration rework during commissioning, which is one of the worst times to discover architectural problems.
What OPC-UA Is Actually For
OPC-UA is a data modeling standard as much as it is a transport protocol. Its strength is semantic richness: you can describe not just values, but what those values mean, including engineering units, data types, quality flags, hierarchical relationships between nodes, and method definitions that allow clients to invoke operations on the server. When a consuming application needs to understand the structure of your data without separate documentation, OPC-UA delivers that by design.
The OPC-UA address space model organizes data into nodes with a hierarchical namespace. Each node carries a NodeId, a browse name, a display name, and a set of attributes depending on its NodeClass. Variable nodes carry a DataType, a ValueRank, an ArrayDimensions attribute, and a Value attribute whose type conforms to the DataType. A conformant client can introspect the server's address space and discover both the structure and the semantics of available data without any out-of-band documentation.
OPC-UA also defines companion specifications: information models for specific domains published by industry consortia. The OPC UA for Machinery companion specification defines how machine tools, forming machines, and robotics expose their data. The PackML companion specification defines how packaging machinery states and modes are represented. The EUROMAP companion specifications cover injection molding and extruder equipment. When your equipment vendor implements these companion specs, integration with a conformant client is substantially simpler than starting from a custom data model.
The security model in OPC-UA is built specifically for plant floor requirements. It uses certificate-based authentication for both client and server, message signing to detect tampering, encryption for confidential data, and node-level access control that restricts which clients can read or write specific process parameters. The session model maintains authenticated state across multiple requests. This matters in environments where the data includes control-critical parameters and the network is not fully isolated from other segments.
The overhead of the OPC-UA security stack is real. Certificate management is more operationally complex than username/password authentication, and the session establishment handshake adds latency compared to MQTT's minimal connect sequence. Both costs are legitimate engineering tradeoffs. The security model exists because the threat model requires it.
What MQTT Is Actually For
MQTT was designed for constrained devices over unreliable networks. The protocol itself is minimal: a two-byte fixed header, a variable header for topic and packet identifier, and a payload that is an opaque byte string. The broker model handles intermittent connectivity cleanly via persistent sessions and the Last Will and Testament mechanism. The publish-subscribe pattern scales horizontally in ways that OPC-UA's client-server model doesn't, because adding a new subscriber doesn't require any configuration change on the publishing device.
If you're collecting telemetry from hundreds of geographically distributed sensors and routing it to a cloud processing platform, MQTT is the natural fit. The lightweight client footprint (the Paho MQTT library is under 50KB), the low protocol overhead, and the broker's built-in fan-out make it well-suited for high-cardinality telemetry collection across heterogeneous devices.
The tradeoff is that MQTT carries no semantic context. Your payload is a byte string. JSON is conventional, Protobuf is common in high-volume pipelines, but the broker neither knows nor cares about the content. If you want structure, you define it yourself, document it separately, and maintain that documentation as the system evolves. For a small system with a stable schema and a single engineering team, this is workable. For large systems with many teams and frequent change, it becomes a maintenance problem.
MQTT's Quality of Service levels provide three delivery semantics: QoS 0 (at-most-once), QoS 1 (at-least-once), and QoS 2 (exactly-once). QoS 2 is rarely used in practice because the two-phase commit handshake it requires adds significant overhead, and most industrial telemetry use cases tolerate occasional message duplication. QoS 1 is the practical default. This has a specific implication for alarm notification systems built over MQTT: at-least-once delivery means deduplication logic has to live in the subscriber, not the broker.
MQTT Sparkplug B addresses the schema problem by defining a standard payload format for industrial data over MQTT. Sparkplug mandates Protobuf payloads with a defined schema, a standardized topic namespace structure, and a birth/death certificate mechanism that lets consumers detect device state changes and reprocess the full state on reconnect. If you're using MQTT in a manufacturing context and building custom schema documentation infrastructure, evaluate Sparkplug B before building another proprietary solution.
Performance and Bandwidth Tradeoffs
OPC-UA offers three transport mappings: UA-Binary, UA-XML, and UA-JSON. UA-Binary is the standard choice for plant-floor communications. It's compact and type-safe, with encoded messages significantly smaller than equivalent JSON representations. The protocol overhead for session establishment is higher than MQTT's minimal connect sequence, but this amortizes across long-lived sessions. OPC-UA subscriptions use a MonitoredItem model where the server notifies the client of value changes, with configurable deadbanding and sampling intervals, rather than requiring continuous polling. For slowly-changing process values, this is efficient.
MQTT's minimal fixed header and broker-based fan-out make it more efficient than OPC-UA at high message rates over constrained links. At very high message volumes across a large broker cluster, the difference is measurable. At the scan rates common in industrial supervision (1 second to 1 minute for most process values), the protocol overhead is not the dominant factor.
Latency is typically similar in practice, dominated by network infrastructure and broker performance rather than protocol overhead. Neither protocol is appropriate for sub-100ms control loops. Those require deterministic fieldbus networks: EtherNet/IP, PROFINET, EtherCAT, or Modbus RTU for legacy equipment. OPC-UA and MQTT are appropriate for telemetry, alarming, and supervision at scan rates of one second or coarser.
Security Model Comparison
The security gap between OPC-UA and MQTT is significant and consistently underestimated during protocol selection.
OPC-UA's security model is defined in Part 2 of the OPC-UA specification and includes three security modes. None disables security entirely and is appropriate only for closed test networks. Sign mode provides message integrity and client/server authentication using certificates without encryption overhead. SignAndEncrypt adds confidentiality via asymmetric key exchange for session key establishment and symmetric encryption for message content. Certificate management requires a PKI infrastructure and operational processes for certificate rotation and revocation. In ISA/IEC 62443-compliant environments, the certificate-based authentication model maps to the credential management requirements at Security Level 2 and above.
MQTT's baseline security model is significantly more limited. The protocol provides username/password authentication and TLS transport encryption, but no message-level signing, no session-level access control, and no built-in certificate-based client authentication in the base MQTT 3.1.1 specification. MQTT 5.0 improved on this with enhanced authentication (supporting SASL-based mechanisms and custom challenge-response flows), but implementation varies significantly across brokers. Many MQTT deployments in industrial environments rely on network isolation as the primary security control rather than protocol-level access control.
This distinction matters when your threat model includes insider threats, compromised vendor access credentials, or network segments that are not fully air-gapped from corporate networks. OPC-UA's protocol-level security provides defense in depth. MQTT's security is primarily perimeter-based.
Where Each Protocol Lives in a Mature IIoT Architecture
Most mature IIoT architectures use both protocols. The boundary is typically the edge gateway, and the split is not arbitrary: it reflects the different requirements on each side of it.
On the plant floor, OPC-UA handles device-to-edge communication. The semantic richness matters for integration with SCADA systems (most modern SCADA platforms including Ignition, Wonderware, and FactoryTalk have native OPC-UA server and client support). The security model is appropriate for the OT network's threat model. The companion specifications reduce custom integration work for equipment that implements them.
From the edge to cloud, MQTT handles aggregation and forwarding. The lightweight protocol fits the aggregation and routing requirements. AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all have native MQTT support with TLS and certificate-based client authentication. The broker architecture scales horizontally to handle large device fleets.
The edge gateway translates between the two: subscribing to OPC-UA data change notifications from plant-floor devices and publishing to MQTT topics for cloud consumers. The engineering work in this layer is doing the translation correctly: preserving OPC-UA's SourceTimestamp rather than substituting the gateway's receive time, handling quality flags across the translation boundary so bad-quality values don't get forwarded as good data, and managing the OPC-UA session lifecycle so that brief network interruptions don't generate unnecessary reconnect overhead.
The Practical Decision Framework
The choice between OPC-UA and MQTT is primarily a question of where in the architecture the data lives and who needs to consume it.
- Use OPC-UA when your consuming application needs to understand data structure without external documentation, when you need node-level access control mapped to security zones, when your equipment vendors have implemented OPC-UA companion specifications, or when you're integrating with SCADA systems that already have native OPC-UA support.
- Use MQTT when you're aggregating telemetry from many lightweight or resource-constrained endpoints, routing data to cloud services with native MQTT support, or operating over intermittent WAN or cellular connections.
- Use Sparkplug B when you choose MQTT but need semantic consistency across teams or device types and want to avoid building a proprietary schema registry.
- Avoid layering semantic abstraction on top of raw MQTT at scale without a standard payload format. It works for small systems. It becomes a maintenance problem for large ones.
The cases that don't fit neatly into this framework are: older PLCs that support neither protocol natively and require a gateway or a communication module; cloud platforms with strong opinions about their preferred protocol; and brownfield integrations where the existing infrastructure has already made the choice. In those cases, the work is adapting to the protocol that's already present, not selecting optimally from scratch.
Common Mistakes in Protocol Selection
Choosing MQTT because it's simpler to start. The initial simplicity of MQTT (a topic, a payload, a broker) makes it attractive for early prototypes. The operational complexity deferred to the schema management, deduplication logic, and reconnect handling ends up being larger than the initial complexity of setting up OPC-UA correctly.
Deploying OPC-UA without PKI infrastructure. OPC-UA without certificates (using SecurityMode: None) is not secure OPC-UA. It's OPC-UA with the transport model but without the security model. If the environment can't support certificate management, the security argument for OPC-UA disappears and MQTT with TLS may be more operationally appropriate.
Assuming MQTT is appropriate for control-critical data. MQTT's at-most-once and at-least-once delivery semantics are not appropriate for applications where message delivery must be guaranteed and duplicate processing is not safe. OPC-UA's session model with its explicit reconnect and subscription recovery behavior is better suited for applications with strict delivery requirements.
Treating protocol selection as a one-time decision. Protocol selection should be revisited when the system's scale, security requirements, or consuming applications change. A protocol choice that was correct for a 20-device pilot system may need to be reconsidered when the deployment reaches 500 devices and three separate consuming teams.
Getting this right early in the project is substantially cheaper than reworking it during commissioning. The decision framework above covers the majority of cases with enough specificity to make a defensible choice based on actual system requirements rather than vendor recommendations.