Modbus, MQTT, OPC-UA: Which Industrial Protocol Should You Choose in 2026?

· 14 min read
14 min read
Eziwan Team
Eziwan Team
IoT Infrastructure

The question “Which protocol should I use for my industrial IoT project?” comes up time and again in factory modernization projects. Modbus, MQTT, and OPC-UA are the three most commonly mentioned protocols—but they are not direct alternatives. They operate at different layers, address different needs, and often complement rather than compete with one another.

This article explains their fundamental differences, strengths, and limitations, and provides a decision-making guide to help you choose the right protocol for your use case.

First, let's understand: protocols of different types​

Before making a comparison, it is important to understand that Modbus, MQTT, and OPC-UA do not operate at the same level:

Modbus is a data read protocol: it allows you to query a device to read its registers (measurements, statuses). It is a field protocol—master/slave—designed for data acquisition from industrial equipment.

MQTT is a messaging protocol: it allows users to publish and subscribe to data streams through a centralized broker. It is a message transport protocol, not a protocol for direct data acquisition from a device.

OPC-UA is a service architecture: it combines data acquisition, data model access, security, alarms, and history into a single, unified industry standard. It is the most comprehensive—and the most complex—solution.

In practice: Most modern industrial IoT architectures use all three: Modbus to read field devices, MQTT to transmit data to the cloud, and OPC-UA for interoperability between complex systems.

Modbus RTU and Modbus TCP​

What is Modbus?​

Modbus was created in 1979 by Modicon (now Schneider Electric). It is the oldest industrial protocol still in active use—and by far the most widely used in the French industrial sector.

Modbus RTU operates over an RS-485 (or RS-232) serial connection. It is asynchronous, master/slave, with a linear (multidrop) bus topology. Up to 247 slaves can be connected to a single RS-485 bus.

Modbus TCP is Modbus encapsulated in TCP/IP packets. It operates over Ethernet on port 502. It retains the master/slave model but allows for arbitrary network topologies (star, tree). There is no strict limit on the number of slaves on the network.

What Modbus Allows You to Read​

Modbus exposes 4 types of data:

  • Coils (0x): read/write digital outputs (Booleans)
  • Discrete Inputs (1x): read-only digital inputs (Booleans)
  • Input Registers (3x): 16-bit read-only registers (sensor measurements)
  • Holding Registers (4x): 16-bit read/write registers (setpoints, parameters)

To read a temperature measurement from a sensor: the master sends a request to "read registers 3x01 through 3x02," and the slave responds with the two registers containing the value (typically a 32-bit float spread across two contiguous registers).

Strengths of Modbus​

Absolute universality: If you have industrial equipment with an RS-485 port or an Ethernet port and don't know which protocol it uses, start by testing Modbus. It is highly likely that it supports Modbus.

Simplicity: The protocol is simple—numbered registers, standard read/write functions. Any developer can implement a Modbus client in a matter of hours.

Resilience: No dependence on a broker or a central server. The master polls each slave directly. A failure of the master does not affect the slaves' communication with each other.

Maturity: 45 years of industrial deployment. Modbus libraries are available in all programming languages (Python, C, Java, JavaScript, etc.).

Limitations of Modbus​

Pull-only architecture: The master must proactively poll each slave. The devices do not send data on their own. On a bus with 50 slaves polled every second, the actual polling interval per slave can drop to 20 seconds.

No built-in security: Modbus RTU and Modbus TCP have no authentication or encryption mechanisms. Any device on the network can read or write the registers of an exposed Modbus device. Security must be implemented at the network level (VPN, segmentation).

No automatic discovery: There is no mechanism for discovering Modbus devices on a bus. You must know the slave address and register addresses for each device.

No semantic naming: Registry entry 40001 does not indicate what it contains—you need the manufacturer's documentation to know that it is "water inlet temperature." No self-description.

When to Use Modbus​

  • Reading data from field devices (energy meters, pressure sensors, variable-speed drives, PLCs)
  • Existing field networks with RS-485 cabling already in place
  • Projects involving heterogeneous equipment from different manufacturers (Modbus is the most widely used)
  • Limited budgets or teams without specialized expertise

MQTT (Message Queuing Telemetry Transport)​

What is MQTT?​

MQTT was created in 1999 by IBM for telemetry over low-bandwidth satellite links. It was standardized by OASIS in 2014 (MQTT 3.1.1) and 2019 (MQTT 5.0).

MQTT is a publish/subscribe protocol: publishers send messages to topics, and subscribers receive messages on the topics they are subscribed to. A central MQTT broker routes messages between publishers and subscribers.

MQTT Architecture​

The broker is at the heart of the MQTT architecture. Clients (publishers and subscribers) connect to the broker—they never communicate directly with each other.

Strengths of MQTT​

Push architecture: Publishers send data when they have something to say. No polling—the subscriber receives the data immediately upon publication. Typical latency: 10–50 ms end-to-end.

Lightweight: The protocol was designed for resource-constrained devices (microcontrollers, 2G modems). An MQTT message can fit into 2 bytes (minimum header). Very bandwidth-efficient.

Configurable QoS: Three levels of quality of service: QoS 0 (at most once), QoS 1 (at least once), QoS 2 (exactly once). For mission-critical applications, QoS 2 guarantees delivery exactly once.

Cloud interoperability: All major cloud providers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) offer a native MQTT broker. MQTT is the de facto protocol for cloud-based IoT architectures.

Native TLS: MQTT natively supports TLS 1.3. Security is built into the protocol; it is not an add-on.

Limitations of MQTT​

Cannot read devices directly: A Modbus RTU device does not natively support MQTT. A gateway is required to read the Modbus data and publish it via MQTT. This is why Modbus and MQTT are often used together in industrial IoT architectures.

Dependence on the broker: If the MQTT broker goes down, the entire messaging architecture fails. The broker's resilience is critical. Managed brokers (AWS IoT, HiveMQ Cloud) are very reliable, but create a dependency on an external service.

No standardized data model: MQTT does not define the message format or the structure of topics. Each implementation is free to choose its own approach—which hinders interoperability. Two MQTT systems from different vendors may not be able to communicate without some adaptation.

No native request/response: MQTT is designed for unidirectional events. To implement a request/response pattern (e.g., requesting a parameter from a device), you must use MQTT 5.0 with correlated response topics—this is possible but more complex.

When to Use MQTT​

  • Data transmission from the field to the cloud (Modbus → Gateway → MQTT → Cloud)
  • Event-driven architectures where data changes irregularly
  • Embedded IoT deployments on microcontrollers or resource-constrained devices
  • Integration with cloud-native brokers (AWS IoT, Azure IoT Hub)

OPC-UA (OPC Unified Architecture)​

What is OPC-UA?​

OPC-UA (IEC 62541) was developed by the OPC Foundation beginning in 2006 as the successor to OPC Classic (based on Windows COM/DCOM). It is the most comprehensive industry standard: it combines data acquisition, a semantic model, security, history, alarms, and method access into a single protocol.

OPC-UA is now the preferred protocol among PLC manufacturers for Industry 4.0 architectures: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, and B&R Automation—all of which have supported OPC-UA natively for the past 5 to 10 years.

OPC-UA Capabilities​

Semantic data model: Unlike Modbus (which uses anonymous, numbered registers), OPC-UA exposes a tree of named and typed objects. The node "ns=2;i=1001" can be named "Machine1/MainMotor/BearingTemperature" and include metadata (unit, range, description). Self-description is built-in.

Built-in security: Authentication, authorization, encryption, message integrity—it's all built into the protocol. OPC-UA supports several security profiles (None, Sign, SignAndEncrypt) using modern algorithms (AES-256, RSA-2048+).

Publish/Subscribe via OPC-UA PubSub (2017): OPC-UA can now operate in asynchronous (push) publication mode, not just in request/response (pull) mode. It can publish to MQTT brokers, making OPC-UA and MQTT complementary rather than competing technologies.

Access to Methods: OPC-UA allows you to call methods on devices—not just read values. Whether it's actuating a valve or issuing a motor start command, everything is modeled as an OPC-UA object.

Semantics and Interoperability: The OPC-UA "Companion Specifications" define industry-standardized models: OPC-UA for Plastics, for Robotics, for PackML (packaging), for Mining... SCADA software that supports OPC-UA for PackML can connect to any compliant packaging line without requiring any specific configuration.

Limitations of OPC-UA​

Complexity: OPC-UA is the most complex protocol to implement and configure. The specifications are over 1,000 pages long. The learning curve is significant for teams with no prior OPC-UA experience.

Required resources: A full-featured OPC-UA server requires more resources than a Modbus slave. Older PLCs or resource-constrained microcontrollers cannot run a full OPC-UA stack (although there are lightweight "nano" profiles available).

Not universally used in the field: Older equipment (manufactured before 2010–2015) does not support OPC-UA. In a heterogeneous industrial environment, you will encounter Modbus much more frequently than OPC-UA on existing field equipment.

Network overhead: OPC-UA messages are larger than Modbus messages (XML or binary, depending on the transport). On low-bandwidth 4G connections, this can be a factor.

When to Use OPC-UA​

  • Recent Siemens S7-1200/1500 PLCs with TIA Portal (native OPC-UA)
  • Industry 4.0 architectures with SCADA/MES/ERP interoperability
  • Projects requiring strong security and traceability for access
  • Multi-vendor environments requiring semantic interoperability

Decision Guide: Which Combination Is Right for Your Project?​

A Simple, Typical Industrial IoT Architecture​

Usage: Process monitoring, alerts, historical data. 80% of French industrial IoT projects follow this model.

Architecture with a Cloud Integration Bus​

Usage: Projects with multiple data consumers (SCADA + ERP + BI). MQTT as an integration bus.

Industry 4.0 Architecture with OPC-UA​

Applications: Factories with modern PLCs, Industry 4.0 projects, MES integration.

Decision Matrix​

RequirementModbus RTUModbus TCPMQTTOPC-UA
Read RS-485 field sensors✓✓———
Read PLCs on the network✓✓✓—✓
Send data to the cloud——✓✓✓
SCADA/MES Interoperability✗✗Partial✓✓
Built-in Security✗✗TLS✓✓
Legacy equipment✓✓✓—✗
Recent PLCs (>2015)✓✓—✓✓
Cloud-native architectures✗✗✓✓✓
SMEs without protocol expertise✓✓✓✓✓✗

How Eziwan Handles the Three Protocols​

The Eziwan gateway is agnostic to field-side protocols:

  • Modbus RTU: native RS-485 port, master mode, up to 247 slaves per bus, configurable polling interval from 1 second to 15 minutes
  • Modbus TCP: Modbus TCP client, simultaneous connections to multiple Modbus servers
  • MQTT: MQTT publisher (publishes collected data), subscriber support available for commands
  • OPC-UA: OPC-UA client (reads nodes, subscribes to value changes) — available upon request for OPC-UA deployments

On the cloud side, data is standardized internally and exposed via:

  • REST API (JSON) for cloud applications
  • Webhooks for real-time events
  • Outbound MQTT for message bus integrations

You can combine Modbus RTU on field devices with MQTT to your AWS/Azure cloud without changing anything—the gateway handles the translation.

Conclusion​

In 2026, the answer to "Modbus, MQTT, or OPC-UA?" is generally "all three":

  • Modbus to read your field devices (that's the language they use)
  • MQTT to transmit data to your cloud and distribute it to multiple applications
  • OPC-UA if you have recent Siemens/Rockwell/Beckhoff PLCs and need SCADA/MES interoperability

This isn't a competition—it's a layered architecture. The choice isn't "which protocol," but "which protocol at which layer for which device."

FAQ — Modbus, MQTT, and OPC-UA​

Can Modbus and MQTT be used simultaneously on the same gateway?

Yes, and that’s the most common architecture in IIoT. The gateway collects data from PLCs via Modbus TCP or RTU (field layer) and publishes it via MQTT to the cloud (transport layer). Modbus stops at the gateway—it is never exposed to the Internet. MQTT takes over for transport to the cloud, using TLS 1.3 and authentication.

Can OPC-UA replace Modbus on existing PLCs (S7-1200, M340)?

On Siemens S7-1200 controllers, the OPC-UA server is only available starting with firmware version 4.4 and requires explicit configuration in TIA Portal. On S7-1500 controllers, it has been supported natively since firmware version 2.0. On Schneider M340 controllers, OPC-UA is not built-in—an additional module is required. In practice, for existing installations, Modbus TCP remains the universal solution; OPC-UA is primarily relevant for new projects using recent PLCs.

MQTT with QoS 0 vs. QoS 1 vs. QoS 2 — Which Should You Choose for Industrial Monitoring?

For monitoring process data (temperatures, pressures), QoS 1 (At Least Once) strikes the right balance: delivery is guaranteed even after reconnection, at the risk of a few duplicates (which are acceptable for monitoring data). QoS 2 (Exactly Once) is more resource-intensive due to the round-trip confirmation and is rarely necessary for measurements. QoS 0 (At Most Once) is suitable for very frequent data (> 1/s) where occasional loss is acceptable.

Is a public MQTT broker (HiveMQ, EMQX Cloud) sufficient for industrial applications?

For pilot projects or non-critical applications, yes. But for a production environment with confidentiality requirements (process data, equipment identifiers), a private broker hosted in France is preferable. MQTT data passing through U.S. public brokers is potentially subject to the CLOUD Act—this should be evaluated based on the sensitivity of the data and the industry.

Does OPC-UA affect the PLC's performance compared to Modbus?

OPC-UA places significantly greater demands on CPU and memory than Modbus TCP. On an S7-1500 CPU 1511 with an active OPC-UA server and 50 client connections, the cycle time can increase by 5 to 15 percent. On an S7-1200, resources are more limited—always test the impact using the complete production program before deploying OPC-UA in production.

Further Reading​

Additional Resources​