Modbus RTU vs Modbus TCP vs MQTT: Where Each Belongs

They are not competitors — they are layers

The question we hear most often when scoping a plant is some version of "should we use Modbus or MQTT?" — and it is the wrong question. It assumes the three protocols are interchangeable options competing for the same slot. They are not. Modbus RTU, Modbus TCP, and MQTT sit at three different layers of a single industrial data path, and a well-built system uses all three at once.

Picture one reading's journey. A flow meter exposes its value as a Modbus register. That register is read over Modbus RTU on an RS485 field bus. The reading might travel across the plant as Modbus TCP to reach a controller or a gateway with an Ethernet port. And to leave the site for a dashboard, a historian, or a cloud analytics stack, it is published over MQTT with TLS. Three protocols, three layers, one path — bridged by a gateway that is the seam between them.

The reason teams pick the wrong one is that they map "protocol" to "decision" instead of mapping protocol to layer. Below, each protocol gets its layer, the field failure it prevents — or causes when misused — and the place where the three meet.

Modbus RTU: the field bus

Modbus RTU over RS485 is the lingua franca of the field: a half-duplex, multi-drop, two-wire differential bus with one master and addressed slaves, speaking a compact binary frame protected by a CRC. Energy meters, VFDs, temperature controllers, and countless sensors expose their data as Modbus holding and input registers, and RTU is how you read them at the bus level. It is cheap to wire, runs long distances, and drops a dozen devices onto a single twisted pair.

The failure RTU prevents is complexity at the edge. You do not need a switch, an IP address, or a DHCP lease to read a meter ten metres away — you need two wires and a transceiver. That simplicity is exactly why RTU is everywhere and why it will not go away.

The failures RTU causes when mishandled are physical, not logical. The first is electrical noise and ground loops: long runs routed past motors and contactors, each end referencing a different ground, will produce CRC errors and dropped frames on an unisolated transceiver — and in the bad cases, a dead UART. The fix is an isolated RS485 transceiver, 120 Ω termination at both ends of the trunk, and proper biasing so the idle line sits at a defined level. The second is bus contention: RTU is half-duplex, so the master must drive the transmit-enable line precisely around each frame and never speak while a slave is responding. One outstanding transaction at a time, a sane inter-frame gap, a per-register timeout. Treat RTU as a disciplined master, not a UART you spray bytes at.

What RTU is not is a transport you can secure or route. It has no authentication, no encryption, and no notion of identity. That is fine — it was never meant to leave the bus.

Modbus TCP: the plant network

Modbus TCP is the same register model — the same holding and input registers, the same function codes — carried inside a TCP/IP packet instead of a serial frame. (It even drops the CRC, because TCP already guarantees delivery.) When a device has an Ethernet port and lives on the plant LAN, Modbus TCP lets a controller, SCADA node, or gateway read its registers over the network rather than over a dedicated serial trunk.

The failure Modbus TCP prevents is the limits of a single serial bus. One RS485 trunk has finite length, a single master, and modest throughput. On a plant network you can have multiple masters polling concurrently, far higher throughput, and structured cabling you already maintain. For a device that is natively Ethernet — many newer PLCs and power meters are — Modbus TCP is simply less wiring and less turnaround discipline than bridging it back to serial.

The dangerous misunderstanding here is treating "TCP" as "secure." It is not. Modbus TCP inherits every security weakness of RTU and adds the reach of an IP network. There is still no authentication and no encryption — anyone who can route a packet to the device's port can read a register or write one. On an isolated, trusted plant LAN that is acceptable, the same way RTU on a bus is acceptable. The failure it causes is exposing that port beyond the trusted network, which we will come back to, because it is the single most common and most expensive mistake in this whole topic.

So: Modbus TCP belongs on the plant network, inside the trust boundary, talking to controllers and gateways. It does not belong on a public interface.

MQTT: the road to the cloud

MQTT is where the model changes shape entirely. It is not a register protocol — it knows nothing about holding registers or function codes. It is a lightweight publish/subscribe transport designed for moving messages over unreliable, high-latency networks to a central broker, and it is the right tool for the one job neither Modbus dialect can do: getting data off-site, securely, over links that drop.

The failures MQTT prevents are the ones that only appear once data leaves the plant. Its pub/sub topology decouples producers from consumers — the gateway publishes to a topic and knows nothing about the dashboard, historian, or analytics sink that consume it, so you add destinations without touching firmware. Its session features survive bad links: a Last Will and Testament lets the broker announce a gateway as offline the moment it drops ungracefully, instead of a dashboard showing the last good reading forever; QoS 1 ("at least once") gives you broker-acknowledged delivery with retry for telemetry you bill or alarm against. And crucially, MQTT runs over TLS with per-device certificates, so every connection is encrypted and cryptographically identified.

That last property is the whole reason MQTT sits at the top of the path. Modbus has no identity; MQTT, done correctly, gives every gateway a unique X.509 certificate, so a compromised unit is revoked individually and can never impersonate the fleet. MQTT is the layer where "who is this device and can I trust the link" finally has an answer.

The layer comparison, side by side

Read this table top to bottom and the division of labour is obvious — each protocol owns a layer, and the columns that matter (security, determinism, topology) line up with that layer, not against each other.

The pattern is the point. Modbus RTU and TCP are strong exactly where MQTT is weak — deterministic, register-level access to physical devices — and MQTT is strong exactly where both Modbus dialects are catastrophically weak: identity, encryption, and surviving the open internet. You do not choose between them. You stack them.

The gateway: where the three layers meet

Everything above converges on one component. The gateway is the device that speaks all three protocols and is the trust boundary between the plant and the world. It does three jobs at once:

1. It acts as the Modbus RTU master on the RS485 field bus (and/or a Modbus TCP client on the plant LAN), polling the registers you care about with proper turnaround discipline and timeouts.
2. It translates raw 16-bit register values into engineering units, stamps each with its capture time, and buffers them to non-volatile storage so an outage never punches a hole in the dataset.
3. It opens an outbound MQTT-over-TLS session to the broker, authenticates with its own per-device certificate, and publishes telemetry to its own namespaced topic — nothing inbound, nothing unauthenticated.

The failure the gateway prevents is the one that ties this whole article together: letting raw Modbus reach the internet. Because Modbus TCP runs over IP, it is trivially tempting to port-forward it through the firewall so a remote dashboard can poll the device directly. Do that and you have published an unauthenticated read/write interface to live industrial equipment on the open internet — anyone who finds the port can read your production data or write a setpoint on a running motor, with no credential and no log. Internet-wide scanners find exposed Modbus ports constantly; it is a documented, recurring source of industrial compromise.

The gateway closes that path by construction. Modbus — RTU or TCP — stays inside the trusted network. The only thing that crosses the boundary is an outbound, TLS-encrypted, certificate-authenticated MQTT connection that opens no inbound port at all. The plant initiates the link; the internet can never initiate a link into the plant.

Choosing the right layer, in practice

Map the decision to the layer, not to a popularity contest:

• At the device, you rarely choose at all — you use whatever the equipment speaks. Serial-only meters and sensors give you Modbus RTU; native-Ethernet PLCs and power meters give you Modbus TCP. Read them where they live.
• On the plant network, prefer Modbus TCP when devices are already on the LAN and you need concurrency or throughput a single serial trunk cannot give; keep Modbus RTU for the multi-drop sensor buses where two wires beat a switch port. Either way, both stay inside the trust boundary.
• Leaving the site, the answer is always MQTT over TLS — never Modbus. The moment data must cross an untrusted network, you need identity, encryption, and resilience to dropped links, and only MQTT (done with per-device certificates) provides them.

The three mistakes that recur are all layer confusion. Teams ask "Modbus or MQTT" as if it were one slot, and pick one when they needed all three. They trust Modbus TCP because it says TCP, and forget it has zero security. And they expose a Modbus port to the internet to save a gateway, turning a convenience into an unauthenticated control path into the plant.

Where to get help

GizanTech builds the layer that makes the stack coherent: the gateway. We design the gateway hardware — isolated RS485 for the RTU bus, Ethernet for the TCP side — write the firmware that masters Modbus, buffers locally, and publishes mutual-TLS MQTT, and stand up the cloud side with per-device certificates and least-privilege topic policies. The result is a single industrial data path where Modbus RTU owns the field bus, Modbus TCP owns the plant network, and MQTT owns the cloud uplink — each in its place, none of them exposed where it does not belong. If you are scoping a plant and want the protocol boundaries and the trust boundary validated before anyone forwards a port, talk to our engineering team.

Frequently asked questions

Is MQTT a replacement for Modbus in an industrial system?

No. MQTT and Modbus solve different problems at different layers. Modbus is a register-level protocol for reading and writing data on field devices — meters, VFDs, PLCs — over a serial bus or a LAN. MQTT is a lightweight pub/sub transport for moving that data off-site to a cloud or central broker over an authenticated, encrypted link. A real system uses both: Modbus at the bus, MQTT to the cloud, with a gateway translating between them. MQTT has no idea how to poll a holding register, and Modbus has no idea how to authenticate to a cloud broker.

Can I connect a Modbus RTU (RS485) device directly to the cloud?

Not directly, and you should not try. Modbus RTU is a half-duplex serial protocol with no IP stack, no authentication, and no encryption — there is nothing to plug into the internet. You need a gateway that acts as the Modbus RTU master on the RS485 bus, reads the registers you care about, and re-emits that data over an authenticated transport such as MQTT with TLS. The gateway is the trust boundary: Modbus stays on the bus, and only encrypted, identified traffic leaves the site.

When should I use Modbus TCP instead of Modbus RTU?

Use Modbus TCP when the device already has an Ethernet port and lives on a plant LAN, when you need higher throughput or more concurrent masters than a single RS485 trunk allows, or when wiring a long differential bus is impractical. Use Modbus RTU when the device is serial-only, when you are on a multi-drop bus of meters and sensors, or when you want the simplest, cheapest field wiring. They carry the same register model, so the choice is about the physical medium and the network you already have, not about the data.

Why not just expose Modbus TCP over the internet instead of using MQTT?

Because Modbus TCP has no authentication and no encryption — it is the same unprotected register model as RTU, just wrapped in TCP/IP. Expose it to the internet and anyone who can reach the port can read your data or write a register on live equipment, with no credential required. MQTT over TLS with per-device certificates gives you an identified, encrypted, outbound link that survives flaky networks and never opens an inbound control path into the plant. The gateway terminates Modbus inside the trusted network and only speaks authenticated MQTT outward.