OPC UA vs MQTT vs Modbus: which protocol should carry your plant data?

OPC UA vs MQTT vs Modbus is not really a contest: each protocol does a different job. Modbus is the simple register-based protocol most legacy PLCs, drives and meters speak; OPC UA is the secure, self-describing standard for machine-to-machine data at the line; and MQTT is the lightweight publish/subscribe protocol best suited to moving that data from the plant to the cloud. Most real plants use two or all three together.

This guide compares the three for industrial IoT (IIoT) work, explains where HTTPS/REST fits, and gives you a short checklist for choosing how to get data from a PLC to the people and systems that need it.

What is Modbus and how does it work?

Modbus dates from the late 1970s and is still one of the most widely supported protocols on industrial devices. If a PLC, energy meter, VFD or temperature controller has a communications port, there is a good chance it speaks Modbus.

It comes in two common forms:

• Modbus RTU runs over serial lines, usually RS-485, with a compact binary frame and a CRC check. Several devices share one bus, each with its own address.
• Modbus TCP carries the same requests over Ethernet. The default TCP port is 502.

Modbus is a polling protocol. A master (now called the client) asks a slave (the server) for data, and the server replies. Nothing is sent unless it is asked for. Data lives in four simple tables: coils and discrete inputs (single bits), and input registers and holding registers (16-bit words).

That simplicity is both the strength and the weakness. Modbus has no built-in data model: register 40010 is just a number. Whether it is a temperature in tenths of a degree, half of a 32-bit float, or a status bitmask is only known from the device manual. Word order for 32-bit values differs between vendors, which is a common source of wrong readings. And standard Modbus has no authentication or encryption: any device that can reach the server can read, and usually write, its registers.

What is OPC UA and why do automation engineers use it?

OPC UA (Open Platform Communications Unified Architecture, standardised as IEC 62541) was designed to replace the older Windows-only OPC Classic. It is platform-independent and increasingly built directly into modern PLCs, CNC controllers and SCADA systems.

Its main pattern is client/server. A client browses the server's address space, reads and writes values, and creates subscriptions so the server only reports values when they change. OPC UA also defines a PubSub model, where data is published over UDP or through brokers such as MQTT, for one-to-many distribution.

What sets OPC UA apart is its information model. Data is organised as a tree of nodes with names, data types, engineering units, timestamps and quality codes. A client can browse the server and discover what is available instead of relying on a register map. Industry groups publish companion specifications that define standard models for particular machine types, so machines from different vendors can describe themselves in the same way.

Security is part of the specification, not an add-on:

• Application authentication using X.509 certificates, so client and server each decide which other applications to trust.
• Message signing and encryption through the Sign and SignAndEncrypt security modes.
• User authentication by username and password, certificate or token, with access rights set per user.

The default port for the binary opc.tcp transport is 4840. The trade-offs are complexity and weight: OPC UA stacks are larger, certificate management takes real effort, and a badly configured server running with security mode None gives up most of the benefit.

What is MQTT and why is it popular for IIoT?

MQTT is a lightweight publish/subscribe protocol. Devices and gateways publish messages to named topics on a central broker, and any number of applications subscribe to the topics they care about. Publishers and subscribers never talk to each other directly.

Key features for plant data:

• Quality of Service: QoS 0 (at most once), QoS 1 (at least once) and QoS 2 (exactly once). Higher QoS costs more round trips.
• Retained messages: the broker keeps the last value on a topic, so a new subscriber gets the current state straight away.
• Last Will: the broker announces when a client disconnects unexpectedly, which helps detect a dead gateway.
• Small overhead: a minimal header and persistent connections make it a good fit for cellular links and constrained networks.

MQTT normally runs over TCP on port 1883, or over TLS on port 8883, which is what you should use for anything leaving the plant. Clients connect out to the broker, so a plant gateway needs no inbound firewall ports.

The catch is that MQTT says nothing about the payload. One team publishes JSON, another publishes raw numbers, and topic names drift. Sparkplug B, an open specification from the Eclipse Foundation, addresses this by defining a topic namespace, a compact binary payload and birth and death messages that tell every consumer which edge nodes and devices are online and what metrics they carry. If you are adopting MQTT across a plant or a fleet, agree on Sparkplug B or your own documented topic and payload convention before the first gateway goes live.

Where does HTTPS/REST fit?

HTTPS with a REST API is not an industrial protocol, but it is often the simplest way to send data from an edge device or historian to a cloud service. It is universally supported, passes through corporate firewalls and proxies, and uses the same TLS security as the rest of the web. It suits batched uploads and periodic readings well. For high-frequency streams from many devices, a persistent MQTT connection is usually more efficient than a new HTTP request per reading.

OPC UA vs MQTT vs Modbus: side-by-side comparison

Which protocol should you use to get data from a PLC?

Start with what the PLC already offers, not with the protocol you would like to use. Changing controller firmware or adding communication modules on a running line is rarely worth it just to collect data.

• Use Modbus when the device only supports Modbus, which is common with meters, drives, older PLCs and small controllers. Keep polling rates sensible and read contiguous blocks of registers rather than single values.
• Use OPC UA when the PLC or SCADA system has a built-in OPC UA server, when you need the context that comes with each value, or when several systems at the line need to exchange data securely.
• Use MQTT to move data off the plant floor, to connect many sites or machines to one platform, or when links are slow or intermittent.
• Use HTTPS when an existing historian, edge device or script can post data to an API and you want the simplest possible path.

Common real-world combinations

Very few plants pick one protocol. These patterns come up again and again:

1. Modbus devices → edge gateway → MQTT or OPC UA. The gateway polls the registers, applies scaling and names, and publishes clean values upstream. This is how most older equipment is brought online.
2. OPC UA at the line, MQTT to the cloud. OPC UA handles secure, structured exchange between PLCs, SCADA and MES inside the plant. An edge application subscribes to the OPC UA server and republishes selected tags over MQTT with TLS.
3. Historian → HTTPS or MQTT. Where a historian already collects everything, it is often easier to forward from the historian than to connect to each PLC again.
4. OEM fleets over MQTT. Machine builders put a gateway in each machine that publishes to a central broker, so they can monitor installed machines across many customer sites without inbound access to any of them.

Once the data is flowing, the usual next step is turning it into measures people act on, such as availability, performance and quality. Our guide on how to calculate OEE from machine data covers that.

Security considerations for OT networks

Whatever protocol you choose, the network design matters more than the protocol's feature list.

• Never expose Modbus or OPC UA servers directly to the internet. Port 502 in particular gives an attacker read and write access to your equipment with no password.
• Use outbound-only connections. A gateway on the plant network should connect out to a broker or API over TLS. No inbound ports should be opened on the plant firewall for data collection.
• Segment the network. Keep control networks separate from office IT, with a controlled zone (often called a DMZ) between them. Gateways should sit where they can reach the PLCs they read and the outbound path they need, and nothing more.
• Read, don't write. A monitoring gateway rarely needs write access. Where the protocol allows it, use read-only accounts or read-only register ranges.
• Turn security on in OPC UA. Use SignAndEncrypt, reject untrusted certificates and switch off anonymous access.
• Authenticate every MQTT client. Use TLS on 8883, per-device credentials or certificates, and topic-level permissions so one gateway cannot publish as another.
• Validate what arrives. The receiving system should only accept data from known devices and known tags, and should log what it rejects.

A short decision checklist

1. What does each device already support: Modbus RTU, Modbus TCP, OPC UA, or something else?
2. Do you need context with the data (units, types, quality), or only raw values you can map once?
3. Is the data staying inside the plant, or going to the cloud or another company?
4. How many consumers need the same data? One-to-many favours MQTT or OPC UA PubSub.
5. What is the network like: stable Ethernet, or cellular and intermittent links?
6. Can every connection leaving the plant be outbound-only and encrypted?
7. Who will own the tag names, topic structure and certificates over time?

If you answer these honestly, the protocol choice usually becomes obvious, and in most plants the answer is a gateway that reads Modbus or OPC UA locally and sends data out over MQTT or HTTPS.

Using the protocols you already have with MIE

You do not need to standardise on one protocol before getting value from plant data. MIE, our Manufacturing Intelligence Engine, takes the readings you already have over HTTPS, MQTT, OPC-UA or Modbus, from your PLC, gateway, historian or edge device. The plant-side gateway stays on your network, and data from a machine you have not registered is rejected and written to a rejected-data log with the reason, so it never reaches a chart, a trend or an alert. Our security and data protection page covers encryption and deployment options.

For machine builders, remote monitoring for OEMs shows how the same approach works across machines installed at many customer sites, with each customer kept separate.