OPC UA vs MQTT: How to Bridge the Plant Floor and the Cloud

OPC UAOProtocolOPC UAInteroperability standard for industrial automationView profile vs MQTTProtocolMQTTThe standard pub/sub protocol of IoTView profile is the wrong framing for most plants: OPC UA describes what the data means, MQTT moves it, and most cloud projects end up needing both.

The question still comes up in almost every industrial IoTITermIoT (Internet of Things)The IoT (Internet of Things) is the network of physical objects with sensors, software and connectivity that collect and exchange data and act autonomously.View profile project. The automation team has OPC UA servers on its PLCs and its SCADA, and it trusts them. The IT or cloud team wants MQTT because it crosses firewalls easily and scales to thousands of sites. Both are right about their own half of the problem, and the arguments start when one protocol is asked to do the other's job.

This guide compares the two where it matters for a real project: data model, transport, security, bandwidth, and what happens at the boundary between the plant network and the internet. Then it walks through three architectures that work in production and a short set of questions to choose between them. It is written for integrators and plant engineers who already know what a SCADA system does and need to get its data somewhere else without breaking anything.

OPC UA vs MQTT: The Short Answer

If you only read one section, read this one.

OPC UA (Open Platform Communications Unified Architecture, standardized as IEC 62541) is an industrial interoperability framework. It defines how a machine exposes its data as a structured model: a pump is an object with a speed, a status, an alarm, and a method to start it, each with its type, units, and engineering range. A client can browse that model without knowing anything in advance.

MQTT (Message Queuing Telemetry Transport, an OASIS standard) is a lightweight publish/subscribe transport. Devices publish messages to topics on a broker, and anyone subscribed receives them. MQTT does not care what is inside the message. That is its strength and its limitation.

So the honest comparison is not "which one is better". It is:

• Inside the plant, between PLCs, SCADA, and historians, OPC UA usually wins. The model and the vendor support are already there.
• From the plant to the cloud, and across many sites, MQTT usually wins. The connection is outbound, light, and tolerant of bad links.
• At the boundary, something has to translate one into the other without losing the meaning on the way. That translation is where most projects succeed or fail.

What OPC UA Does Well

OPC UA replaced classic OPC, which depended on Windows DCOM and was painful to run across networks. The unified architecture is platform-independent and runs on anything from a PLC to a cloud server.

A Model, Not Just Values

The address space is the core idea. Every data point is a node with a name, a data type, a unit, and relationships to other nodes. Companion specifications go further: industry groups publish standard models for machine tools, robotics, packaging lines, and other equipment, so two vendors' machines can describe themselves the same way.

For a plant engineer this means a new SCADA screen or historian can discover what a machine offers instead of reading a spreadsheet of register addresses. That alone saves days of commissioning on a medium-sized line.

Subscriptions, Methods, and History

An OPC UA client does not have to poll. It creates a subscription with monitored items, a sampling interval, and a deadband, and the server sends only the changes. The same session can call methods on the machine, read historical data, and receive alarms and conditions with their state. MQTT has none of this built in.

Security Designed In

Every OPC UA application has an X.509 certificate. Connections can run with no security, signed messages, or signed and encrypted messages, and users authenticate on top of that. Done properly, it is strong security. Done badly, someone sets the mode to None during commissioning and nobody changes it back.

Where OPC UA Struggles

The classic client/server model is connection-oriented: the client opens a session to a server that listens, usually on port 4840. For a cloud service that means reaching *into* the plant network, which most OT security teams refuse, and rightly so. The specification added reverse connect so the server can dial out, but support across the installed base is uneven.

The stacks are also heavier than MQTT, and certificate management across dozens of sites is real operational work. Every certificate expires, and an expired certificate looks exactly like a network failure at three in the morning.

What MQTT Does Well

MQTT was designed for unreliable, low-bandwidth links, and it shows. The fixed header is two bytes. A device opens one outbound TCP connection to a broker, keeps it alive, and publishes when it has something to say.

Built for the Plant-to-Cloud Leg

Because the plant opens the connection, there is no inbound port to open on the OT firewall. With TLS on port 8883, the traffic looks like any other encrypted outbound session. This one property explains most of MQTT's popularity in industrial IoT.

The protocol also handles bad links gracefully:

• Quality of service levels 0, 1, and 2 let you trade overhead for delivery guarantees per message.
• Persistent sessions keep subscriptions and queued messages when a client drops and reconnects.
• Retained messages give a new subscriber the last known value immediately.
• Last will tells everyone when a publisher disappears without saying goodbye.

Version 3.1.1 is still the most deployed, and MQTT 5.0 adds user properties, reason codes, message expiry, and shared subscriptions. The details of brokers, sessions, and sizing are covered in our MQTT broker guide.

Where MQTT Struggles

MQTT moves bytes. It does not say that `line2/press4/temp` is in degrees Celsius, sampled every second, with an alarm at 85. Every project invents its topic tree and its payload format, and two integrators will invent different ones.

That is why conventions exist on top of MQTT. The Eclipse Sparkplug specification defines a topic namespace, a binary payload, and birth and death messages so a subscriber knows which devices are online and what metrics they publish. Other teams use plain JSON with a written naming convention. Either way, the semantics have to come from somewhere, and in a plant that already runs OPC UA, the obvious source is the OPC UA model itself.

For a wider comparison of MQTT against other transports, see MQTT vs CoAP vs HTTP.

OPC UA vs MQTT Side by Side

The table below sums up the differences that matter when you design the bridge.

One line deserves more attention than the others. The OPC Foundation's Part 14 PubSub specification lets OPC UA itself publish over MQTT, keeping the OPC UA data model inside the messages. On paper this closes the OPC UA vs MQTT debate. In practice, few installed PLCs and SCADA servers support it today, so most projects still need a gateway.

Three Architectures That Work in Practice

There are many ways to draw the diagram, but three cover nearly every real project. They differ in where the translation happens and who has to open what on the network.

1. Edge Gateway: OPC UA In, MQTT Out

A small software gateway runs on an industrial PC or a server in the plant. It acts as an OPC UA client toward the PLCs or the SCADA server, subscribes to the tags that matter, maps them to MQTT topics, and publishes outbound over TLS to the cloud broker.

This is the most common pattern because it asks nothing of the existing equipment. The PLCs keep running as they are, the OT firewall only allows one outbound connection, and the gateway can buffer data when the internet link drops.

The work is in the mapping. A useful rule: carry the OPC UA metadata with the value. The engineering unit, the range, and the quality code should travel in the payload or in a published description, not live only in someone's head.

The gateway is also where you control bandwidth. Polling 1,800 tags every second produces 1,800 values per second. If you publish by exception, with a sensible deadband per tag, and only one value in ten changes meaningfully each second, the stream falls to about 180 values per second. The cloud bill and the dashboards both notice.

This is how Cloud Studio IoT connects OPC UA, ModbusMProtocolModbusThe most widespread industrial fieldbusView profile, and other industrial protocols: a software module installed at the edge acts as the gateway and sends the data securely to the platform over MQTT. The platform's MQTT server runs per instance with TLS on port 8883, so the plant only needs that one outbound path.

2. Native OPC UA PubSub over MQTT

Newer controllers and some SCADA products can publish OPC UA PubSub messages straight to an MQTT brokerMTermMQTT brokerAn MQTT broker is the central server that receives messages from publishers and distributes them to subscribers by topic. Examples: Mosquitto, EMQX, HiveMQ.View profile. The gateway disappears and the data model travels intact.

It is the cleanest design when the equipment supports it. Check three things before you count on it: whether every device on the line supports PubSub over MQTT (not just over UDP), which message encoding it uses (JSON or the binary UADP format), and whether the platform receiving the data can decode it. A mixed fleet usually ends up with a gateway anyway for the older machines.

3. Direct OPC UA Client over a VPN

The cloud application acts as an OPC UA client and connects to the plant's OPC UA server through a site-to-site VPN. Nothing is translated.

It works for a single site with an existing VPN and a team that already manages certificates. It scales badly. Every new site adds a tunnel, the cloud holds a session per server, and a VPN outage means a data gap with nothing buffered at the edge. Most projects that start this way move to an edge gateway at the third or fourth site.

A Note on the Unified Namespace

You will hear "unified namespace" in the same conversations. The idea is to put one MQTT broker at the centre of the company and have every system publish its current state into a single, well-structured topic tree organized by site, area, line, and machine. It is an architectural principle more than a product, and it depends entirely on the discipline of the topic and payload conventions. OPC UA models are a good source for that structure; MQTT is the usual transport.

Security on Both Sides of the Bridge

The bridge between OPC UA and MQTT is also the bridge between the OT network and the internet. Security decisions here matter more than the protocol choice.

On the plant side:

• Never leave OPC UA security on None in production. Use signed and encrypted connections and give the gateway its own certificate and its own user with read-only rights, unless it has to write.
• Limit what the gateway can see. It should subscribe to the tags the project needs, not browse the whole address space of every PLC.
• Plan certificate renewal before the first one expires. Write down who renews them and when.

On the cloud side:

• Outbound only. The gateway connects to the broker; nothing on the internet connects to the plant.
• TLS on every MQTT connection, with credentials per site, so one compromised gateway can be revoked without touching the others.
• Writes are a separate decision. Sending setpoints or commands from the cloud back to a PLC is possible, but it should be explicit, limited to specific tags, and logged.

The reference framework for industrial control system security is ISA/IEC 62443, which organizes the plant into zones and conduits. The gateway is, in its terms, a conduit, and it deserves the same scrutiny as any other. For the wider OT threat picture, see our article on OT cybersecurity.

How to Choose for Your Project

The OPC UA vs MQTT decision turns into a short list of questions once you know your installed base.

1. What does the equipment already speak? If the PLCs and SCADA expose OPC UA, use it inside the plant. Do not replace a working OPC UA layer to "standardize on MQTT".
2. How many sites, and how will that grow? One site can live with a VPN and a direct client. Five or more almost always justify an edge gateway and MQTT.
3. What does the OT security team allow? If inbound connections to the plant are forbidden, and they usually are, the transport to the cloud is outbound MQTT.
4. Who defines the meaning of the data? Decide early whether you carry the OPC UA model into the payload, adopt a convention such as Sparkplug, or write your own topic standard. Changing it after 20 sites are live is expensive.
5. Do you need to write back to the plant? Reading is easy with any architecture. Writing setpoints from the cloud needs a deliberate design, approvals, and an audit trail.
6. Does the target platform accept what you send? Check the payload format, the topic structure, and the TLS requirements before buying gateways.

For most integrators, the answer is the same: OPC UA on the plant floor, an edge gateway at each site, MQTT over TLS to the cloud, and a written naming convention that survives the first project. The broader rollout, from pilot to several plants, is covered in our industrial IoT implementation guide.

A good test for any proposal is to ask what happens when the internet link drops for four hours. If the answer involves lost data or a technician driving to the plant, the architecture is not finished.

Conclusion

The OPC UA vs MQTT question has a practical answer once you separate meaning from transport. The key points:

• OPC UA is the right protocol inside the plant: it carries the data model, methods, alarms, and strong application security.
• MQTT is the right transport from the plant to the cloud: outbound, light, and tolerant of poor links.
• The edge gateway is where projects succeed or fail. Carry units, ranges, and quality with each value, and publish by exception.
• OPC UA PubSub over MQTT is the cleanest long-term design, but check device support before relying on it.
• Security lives at the bridge: certificates on the OPC UA side, TLS and per-site credentials on the MQTT side, and no inbound connections to the plant.

Once the data reaches the cloud, the work shifts to telemetry: storage, dashboards, and alarms that operators actually read. If you are evaluating where that data should land, our SCADA IoT platform buyer's guide lists what to check, and the SCADA systems solution page shows how the platform handles it. To review a specific plant architecture, talk to the team.

Frequently asked questions

Is OPC UA better than MQTT?

Neither is better, because they do different jobs. OPC UA describes what the data means and MQTT moves it. Inside the plant, between PLCs, SCADA, and historians, OPC UA usually wins. From the plant to the cloud and across many sites, MQTT usually wins.

Can OPC UA and MQTT be used together?

Yes, and it is the most common design. A software gateway at the edge acts as an OPC UA client toward the PLCs or the SCADA server, maps the tags that matter to MQTT topics, and publishes outbound over TLS to the cloud broker.

What is OPC UA PubSub over MQTT?

It is Part 14 of the OPC UA specification, which lets OPC UA publish over MQTT and keep its data model inside the messages. Few installed PLCs and SCADA servers support it today, so check device support, the message encoding (JSON or UADP), and whether the receiving platform can decode it.

Why is MQTT used to send plant data to the cloud?

Because the plant opens the connection, so there is no inbound port to open on the OT firewall. MQTT also tolerates bad links: quality of service levels, persistent sessions, retained messages, and last will cover drops and reconnections.

What is Sparkplug?

Eclipse Sparkplug is a specification on top of MQTT. It defines a topic namespace, a binary payload, and birth and death messages, so a subscriber knows which devices are online and which metrics they publish.

Which ports do OPC UA and MQTT use?

An OPC UA server usually listens on port 4840. MQTT over TLS uses port 8883, opened as an outbound connection from the plant to the broker.