OPC UA vs Modbus: which industrial protocol should you specify in 2026?

The honest reason OPC UA exists is not security, and not Pub/Sub. It is the Information Model.

A Modbus device exposes a list of 16-bit registers. Register 40001 might be motor speed in RPM, or a setpoint scaled by 10, or a packed bitfield of fault flags. The protocol does not know and does not care. Meaning is carried in a vendor PDF, transcribed by hand into the SCADA tag database, and silently breaks every time the firmware revision shifts a register by one. Anyone who has commissioned a fleet of energy meters from three vendors has lived this pain.

An OPC UA server exposes a typed Address Space. Every node has a NodeId (namespace index + identifier), a BrowseName, a DataType, an EngineeringUnit, an EU range, and References that link it to parent objects, type definitions, and historical data. A motor is not "register 40001" — it is an instance of `MotorType` with a `Speed` variable typed as `Double`, unit `rpm`, range 0 to 3600, with a `StartCommand` method and an `Overtemperature` event. A client that has never seen this specific device can browse it at runtime, discover its capabilities, and bind to its variables without a single line of vendor-specific code.

This is why Companion Specifications matter. PA-DIM standardises the model for process instruments so a Yokogawa flow meter looks like an Endress+Hauser flow meter to MES. AutoID does the same for RFID and barcode readers. OPC UA for Robotics lets a Kawasaki cell and a KUKA cell both expose `AxisPosition` and `SafetyState` under the same type. Modbus has no equivalent. It cannot. The wire has no room for it.

Modbus has no security. None. A Modbus TCP packet on port 502 is plain bytes — function code, register address, value, CRC on RTU only. Any host on the network segment can read every register, write to any holding register, and trip any coil. There is no authentication, no authorisation, no integrity check beyond CRC (which guards against line noise, not attackers), and no encryption. The 2018 Modbus Security spec (TCP over TLS, port 802) exists on paper but is essentially unimplemented in shipping hardware in 2026.

OPC UA was designed in the post-Stuxnet world and takes security seriously. Every session opens a SecureChannel that can be `None`, `Sign`, or `SignAndEncrypt`, using cipher suites like `Basic256Sha256` or the newer `Aes256_Sha256_RsaPss`. Endpoints authenticate with X.509 certificates exchanged at first connection (trust-on-first-use, then operator approval — the same pattern as SSH host keys). User authentication is layered on top: anonymous, username/password, or X.509 user certificate, configurable per endpoint. The whole stack is explicitly aligned with IEC 62443-3-3 zone-and-conduit security levels SL1 through SL4.

The practical consequence: dropping a Modbus device on a flat OT network in 2026 is a finding on every credible security audit. Dropping an OPC UA server with `SignAndEncrypt` and proper certificate management is defensible to an ISA/IEC 62443 assessor. This single difference — not Pub/Sub, not the information model — is what is forcing the migration in regulated industries: pharma, energy, water, defence, and anywhere NIS2 or the EU Cyber Resilience Act applies.

Modbus is strictly polled. The SCADA opens a TCP socket, asks for registers 40001 to 40050, waits for the response, asks for the next block, and repeats — typically every 250 ms to 1 s per device. With a hundred devices that is a hundred sequential request/response cycles per scan. Scale breaks: either the poll rate slows to seconds, or the network fills with redundant traffic for values that never changed.

OPC UA supports both modes. Classic OPC UA client/server uses MonitoredItems inside a Subscription with a configurable `publishingInterval` and `samplingInterval` — the server only sends a notification when a value changes (or on keep-alive). This alone removes 80–95% of the traffic of an equivalent Modbus poll loop. Better, OPC UA PubSub (spec 1.04 onwards) decouples publishers from subscribers entirely: a server publishes DataSetMessages to a UDP multicast group, an MQTT broker, or AMQP, and any number of subscribers consume them with no point-to-point session.

The MQTT binding is where this gets architecturally interesting. Sparkplug B — the Eclipse Foundation specification originated by Cirrus Link — added typed, stateful payloads to MQTT, drawing heavily on OPC UA’s modelling ideas, and is now the de-facto Unified Namespace transport. In 2026 a typical greenfield plant looks like: PLCs and gateways publish OPC UA PubSub or Sparkplug to a broker (HiveMQ, EMQX, Inductive Automation’s MQTT Distributor); MES, historians, and cloud platforms (AWS IoT SiteWise, Azure IoT, Siemens Insights Hub) subscribe. Modbus devices are pulled in via an edge gateway — Kepware, Ignition, Node-RED, HMS Anybus — that translates the register map into a typed OPC UA Address Space first.

Modbus wins on cost per node, full stop. A Modbus RTU drive interface is a $0 line item — the silicon is already in the chip. A Modbus TCP energy meter is $40 cheaper than the OPC UA-capable variant. A Modbus client is an afternoon of Python with pymodbus. There is no certificate to manage, no Information Model to design, no companion specification to study, no OPC Foundation membership to consider. For a small system — a dozen drives, a handful of meters, an in-house SCADA — Modbus is genuinely the right answer.

OPC UA has a higher floor and a lower ceiling. The floor is real: you must understand namespaces, NodeIds, ObjectTypes, References, and SecureChannel configuration before you ship a server that anyone else can consume. The reference stacks — open62541 (C, MPLv2), node-opcua (TypeScript), Eclipse Milo (Java), Unified Automation SDKs (C++/.NET, commercial) — all work, but each has its own learning curve. Vendor tooling helps: Siemens TIA Portal ships an OPC UA server you toggle on for an S7-1500; Beckhoff TwinCAT exposes any PLC variable as an OPC UA node with a checkbox; Rockwell FactoryTalk Linx Gateway and Schneider EcoStruxure ship comparable bridges.

The economic case for OPC UA shows up at scale and over time. Kepware KEPServerEX and Inductive Automation Ignition charge per OPC UA server, not per Modbus tag, so the marginal cost of adding the 501st device collapses. Companion specifications eliminate per-vendor integration work: once your MES speaks PA-DIM, the next flow meter is plug-in. And the security posture, frankly, removes a class of audit findings that cost more to remediate than the original integration cost to ship.

Rule of thumb for 2026: under 50 devices and one vendor, Modbus is cheaper. Above 200 devices, multi-vendor, or anything touching MES, an OPC UA layer pays back inside the first audit cycle.