OPC UA and MQTT: How to Bridge OT Protocols for Scalable Industrial Data

Most industrial teams don't choose between OPC UA and MQTT. They need both and the question is how to connect them without creating a new maintenance problem. OPC UA does what it was built to do: provide structured, secure, semantically rich access to machine data at the source. MQTT does what OPC UA can't: distribute that data at scale, across systems, without polling overhead or point-to-point complexity. The architecture is well understood. The execution is where teams lose time.

This guide covers the architectural gap between OPC UA and MQTT, three proven patterns for bridging them, and the design decisions that determine whether your integration holds up at scale.

Why Does OPC UA Fall Short for Enterprise-Scale Data Distribution?

OPC UA is the backbone of OT communication. It provides a standardized, secure, semantically rich way for machines, PLCs and historians to expose data - and it's earned that role. But its request-response, client-server model creates a ceiling that becomes apparent as consumption demands grow.

Each OPC UA server handles a finite number of simultaneous client connections. As you add more downstream consumers - analytics platforms, MES systems, cloud applications, digital twins - you're adding clients, not capability. The result is data silos, brittle point-to-point connections between the OT layer and IT systems, and middleware sprawl that grows faster than the team managing it.

It's worth briefly noting where OPC UA came from. OPC DA (Data Access), its predecessor, was built on Microsoft's COM/DCOM technology - Windows-only, network-unfriendly and difficult to maintain across modern infrastructure. OPC UA's platform independence was a meaningful step forward when it arrived in 2008. But platform independence didn't solve the distribution problem. The client-server model remained, and so did its inherent scaling constraints.

OPC UA gives you structured access to machine data at the edge. It doesn't give you the fan-out architecture to make that data available everywhere it needs to go.

How Are OPC UA and MQTT Architecturally Different - and Why Does That Make Them a Pair?

The two protocols operate at different layers of the IIoT stack. Understanding that distinction is what makes the architecture click.

OPC UA's unified architecture provides a hierarchical address space and node model that lets machines describe not just their values but the meaning and context of those values. Its subscriptions and monitored items allow clients to receive data when it changes, rather than polling on a fixed interval. Built-in security - certificate-based authentication, TLS encryption, message signing - is native to the spec. The result is a protocol designed to give clients structured, queryable, semantically rich access to machine data at the source. That's what "unified architecture" means in practice: one spec that consolidates what previously required multiple fragmented OPC Classic standards.

MQTT's architecture is built around a broker-mediated publish-subscribe model. Producers publish data to topics; any number of consumers subscribe to those topics and receive data as it arrives. Quality of service levels handle delivery guarantees. Report-by-exception means data moves only when something changes. The protocol is stateless by design and runs efficiently on constrained networks. It was built for scale and reach, not for semantic richness at the source.

The key insight: OPC UA gives you meaning and structure where the data is born. MQTT gives you the distribution infrastructure to make that data available everywhere it needs to go - simultaneously, without polling overhead and without rebuilding pipelines as new consumers come online.

For a full breakdown of how the two protocols compare across scalability, bandwidth efficiency, security and more, read The Key Differences Between OPC UA and MQTT Sparkplug.

What Are the Three Proven Patterns for Bridging OPC UA and MQTT?

There's no single right answer - the correct pattern depends on your infrastructure maturity, engineering capacity, and how much flexibility you need in the translation layer. Here are the three approaches teams use in production.

Pattern 1: Custom OPC UA client publishing to MQTT

You build or buy an OPC UA client application that reads node data from the OPC UA server and publishes it to an MQTT broker. This approach is flexible and works with any OPC UA server regardless of version or vendor.

The trade-off is ownership. You write and maintain the translation logic, error handling, and reconnect behavior. If your team has the engineering capacity and specific data mapping requirements that off-the-shelf tooling can't meet, this is a viable path. If you need a reference implementation for Azure specifically, see Send OPC UA Data to Azure With HiveMQ and MQTT - it walks through the full implementation using KepserverEX, .NET, and HiveMQ.

Pattern 2: Edge gateway with a built-in OPC UA adapter

Deploy a software edge gateway that speaks OPC UA on one side and MQTT on the other. The gateway handles polling, subscriptions, node mapping, and MQTT publishing - no custom code required. HiveMQ Edge includes a native OPC UA protocol adapter that connects directly to OPC UA servers, browses the server's address space and publishes data as MQTT messages without a separate translation layer.

The trade-off here is an additional infrastructure component to manage. For most teams, that's a worthwhile exchange for the reduction in custom code and the speed to production. This is the fastest path for teams standardizing on an edge data platform and the most common implementation pattern in operational environments today.

Pattern 3: OPC UA pub/sub over MQTT

OPC UA version 1.04 introduced a native publish-subscribe model that can use MQTT as its transport. This eliminates the translation layer entirely - OPC UA servers publish directly to an MQTT broker.

The trade-off is equipment compatibility. OPC UA 1.04-compliant servers are not universal in legacy OT environments, and implementations are still maturing. This pattern is the right call for greenfield deployments with modern, compliant equipment. For brownfield environments with older PLCs and historians, Pattern 2 is the more pragmatic choice.

What Should You Decide Before Building Your OPC UA-MQTT Bridge?

The architectural pattern is the first decision. These are the four that determine whether your bridge is maintainable at scale.

Payload format. OPC UA data types are rich and structured. You need a serialization strategy that preserves that richness inside MQTT payloads - otherwise downstream consumers receive raw, unstructured data that needs reprocessing before it's useful. For example, a simple variable type in OPC UA carries more than a value, it includes a data type, source timestamp and quality status code. Package the OPC UA data and metadata into a JSON data structure and distribute it to downstream consumers, as an MQTT payload during publish. Publish the value together with the metadata in a JSON data structure 

Topic structure: The MQTT topic hierarchy is the contract every consumer reads the bridged OPC UA data through, so model your operation in it. An ISA-95-style path (enterprise / site / area / line / cell / device / metric) gives the MQTT topic namespace a predictable shape: a subscriber can tell what a value represents from its topic alone, and can wildcard-subscribe to exactly the slice it needs. A well-designed topic hierarchy gives MES, SCADA, analytics platforms, and cloud applications a consistent, predictable view of your operational data. 

Subscription vs. polling: Use OPC UA monitored items and subscriptions rather than polling wherever possible. Report-by-exception is a core principle that should start at the OPC UA layer, not just at the MQTT layer. Polling creates unnecessary server load, increases latency and generates data volume that doesn't reflect actual operational state.

Security continuity: OPC UA has strong certificate-based authentication built in. Ensure your bridge preserves or extends that security posture. The most common mistake is creating an unprotected MQTT exposure point between the OPC UA and MQTT layers - a gap that leaves factory floor data vulnerable at exactly the point where OT and IT networks meet. With HiveMQ, TLS is enforced end-to-end and no inbound ports need to be opened on the OT network.

Where Is This Architecture Running Today?

The OPC UA-MQTT bridge is deployed across industries where operational data needs to move from the machine layer into enterprise and cloud systems simultaneously.

Smart manufacturing: Machine telemetry from CNC machines, robotic arms, and conveyors routed through MQTT into MES and ERP systems for real-time production visibility - without polling overhead or point-to-point integrations for each consumer.

Energy and utilities: Substation monitoring data reaching both on-premises SCADA and cloud dashboards simultaneously through a single MQTT broker, without duplicating the integration for each destination.

Predictive maintenance: OPC UA sensor streams feeding ML pipelines via MQTT for anomaly detection, with report-by-exception ensuring the pipeline moves only on meaningful data changes rather than fixed-interval polling.

Pharmaceutical and regulated industries: Traceable, auditable OT data pipelines from OPC UA sources to enterprise systems, with security and data integrity maintained end-to-end from the machine layer through to compliance reporting.

OPC UA and MQTT: Complementary Layers, Not Competing Choices

The bridge between OPC UA and MQTT is where modern IIoT deployments are won or lost. Choose the right pattern for your infrastructure maturity, design your topic structure for a Unified Namespace from day one, and ensure your payload format preserves the semantic value OPC UA gives you all the way through to downstream consumers.

OPC UA does what it was built to do at the machine layer. MQTT does what OPC UA can't at the distribution layer. The architecture is proven and the tooling exists.

HiveMQ Edge connects directly to your OPC UA infrastructure and publishes data as MQTT - no custom middleware required. Start HiveMQ free and bridge your first OPC UA server in minutes.