What is OPC UA? The modern industrial interop spec — when it's worth the lift.
If Modbus is the protocol that refuses to die, OPC UA is the protocol everyone agrees is the future and then takes ten years to actually deploy. It's more capable than anything that came before it, much harder to get right, and it's slowly becoming the default for new industrial systems. Here's what it actually is, when it's the right call, and when it's overkill.
The 30-second version
OPC UA (Unified Architecture) is a platform-independent, service-oriented architecture for industrial interoperability. It replaces the older OPC Classic (DA / HDA / A&E) family — which was Windows-only and DCOM-based — with a modern, cross-platform, secure-by-default spec maintained by the OPC Foundation.
Where Modbus is "read register 40001 from slave 5," OPC UA is "subscribe to the namespace node ns=2;s=Tank1/Level on this authenticated, encrypted session, with this data-change filter, and tell me when the engineering-unit value crosses 8.5 meters." Same conceptual job. Wildly different sophistication.
Plain English: OPC UA is Modbus's modern, secure, object-oriented great-grandchild. It does what Modbus does, plus information models, plus security, plus subscriptions, plus discovery — at the cost of being a much more complex spec to implement and operate.
Brief history
The original OPC ("OLE for Process Control") spec was published in 1996 by a Microsoft-led consortium. It rode on DCOM, which made it Windows-only and gave it the security profile of a paper bag. It worked, it spread, every PLC vendor wrote an OPC server, and by the 2000s "OPC" was the de facto bridge between SCADA and HMI products.
By the mid-2000s, the Windows-DCOM dependency was painful (Linux servers, firewall rules, ICS-CERT advisories). The OPC Foundation began work on a clean-slate replacement — OPC UA — published as IEC 62541 in 2008. It removed DCOM, added platform independence, added a security model from the ground up, and added an information-model layer the original spec lacked.
By 2026, OPC UA has been the recommended choice for new industrial deployments for at least a decade. Adoption is still uneven — the older OPC Classic stack is alive in millions of installations and migration paths are messy. But every modern PLC ships with an OPC UA server, every modern SCADA platform has an OPC UA client, and most major industry initiatives (Sparkplug, NAMUR Open Architecture, IT/OT convergence frameworks) assume OPC UA as their interop substrate.
What OPC UA actually does
OPC UA is not one thing. It's a stack of four loosely-coupled capabilities:
Most OPC UA deployments use Layers 1-3 actively and only scratch the surface of Layer 4 (the information model). Realizing the full value of OPC UA — particularly cross-vendor information sharing — requires committing to a companion spec. Most projects don't.
OPC UA vs Modbus — head-to-head
| Dimension | Modbus | OPC UA |
|---|---|---|
| Data model | 4 tables of 16-bit words / bits | Typed object graph (numeric, string, struct, arrays, enums) |
| Discovery | None — you need a device map | Built-in Browse service; servers self-describe |
| Subscriptions | None — poll only | MonitoredItems with deadband, sampling interval, queueing |
| Security | None native (Modbus/Secure exists but rarely deployed) | Mandatory in v1.04+ profiles; mutual TLS-style by default |
| Cross-platform | Yes — trivially | Yes — explicit design goal |
| Spec size | ~100 pages | ~1500 pages across 14 parts |
| Implementation complexity | Trivial — every embedded dev can implement Modbus | Significant — most teams use a vendor SDK |
| Field deployment maturity | 40+ years, near-universal | ~15 years, growing but uneven |
The information model — where OPC UA earns its complexity
The thing OPC UA does that Modbus cannot is describe a device as an object, not as a memory map. A pressure transmitter in Modbus is "registers 40005 through 40008, scaled by 100, in PSI." A pressure transmitter in OPC UA is a node with a typed value (engineering units: kPa), a measurement uncertainty, a calibration timestamp, an alarm-condition reference, and links to the loop and the device it belongs to — all self-describable to any client that walks the namespace.
Companion specs are where this gets powerful. NAMUR's NOA spec defines how a process-automation device exposes its operational data. PA-DIM (Process Automation Device Information Model) standardizes how an Emerson, Endress+Hauser, or Yokogawa transmitter exposes the same parameters via the same node names. In theory, you can walk a multivendor plant's namespace and find every pressure measurement in the same place.
In practice, vendor adoption of the same companion spec is uneven enough that most deployments still hand-map devices. The promise of "plug in any vendor's transmitter and your SCADA reads it automatically" is real in pilots, partial in production.
Security — the model worth understanding
OPC UA's security is the strongest argument for adopting it. Three things to know:
Certificates, not passwords
Each OPC UA client and server has an X.509 certificate. They mutually validate each other's certificate against a configured trust list before the session opens. Once trusted, the session can use any of several encryption suites. Username/password authentication is still available as a user-token, but it sits inside the already-encrypted channel.
Security policy is per-endpoint
An OPC UA server exposes multiple endpoints, each with its own security policy. You can have opc.tcp://server:4840 with no security (for legacy clients only — strongly discouraged) and opc.tcp://server:4843 with Basic256Sha256 + Sign+Encrypt for production. The client picks which endpoint to connect to.
The trust-list management problem
The security only works if certificate trust is managed properly. Most early OPC UA deployments failed at this step — operators clicked "trust" on every certificate, effectively reverting to no security. Modern deployments use a Global Discovery Server (GDS) or PKI tooling to centralize trust management; some run a private CA for OPC UA certificates specifically.
The trap: "We deployed OPC UA, so we're secure." OPC UA gives you the tools for security; it doesn't give you operationally secure systems for free. The deployment quality matters more than the protocol choice.
When OPC UA is worth the lift
- You're building a new plant or doing a major modernization. Greenfield.
- You need cross-vendor interoperability — a heterogeneous plant where multiple brands of PLCs, drives, and instruments need to talk.
- You need secure remote access — for cloud analytics, vendor support, or cross-site monitoring.
- You have an operations team that can manage certificate lifecycle properly.
- You're aiming at IEC 62443 Level 2+ and need protocol-level authentication and integrity.
When it isn't
- You're integrating with a legacy installed base where every device speaks Modbus and ripping it out isn't on the table.
- You have small, embedded devices that lack the compute to implement an OPC UA stack. (The Foundation's "OPC UA Embedded" profile narrows this — but most field devices in 2026 still don't speak OPC UA natively.)
- You don't have certificate-management discipline. Deploying OPC UA without it creates a security theater that's arguably worse than well-segmented Modbus.
- You only need polled telemetry at slow rates — Modbus's simplicity wins on total cost of ownership.
How Aevus uses OPC UA
For customers running OPC UA at the plant or site level, Aevus connects as an OPC UA client with read-only permissions and a deny-write trust policy. Three connection patterns:
- Direct subscribe to plant OPC UA server — Aevus subscribes to the namespace nodes the operations team has selected for export. The customer's IT/OT team issues an X.509 certificate to Aevus's edge collector, scoped to a specific role with read-only permissions on a specific node subset.
- Through a customer OPC UA aggregator — if the customer runs an OPC UA aggregator (Kepware, Matrikon, Cogent, etc.) consolidating multiple devices, Aevus subscribes to the aggregator instead.
- Cloud Pub/Sub mirror — for sites already publishing OPC UA Pub/Sub data into a cloud queue, Aevus subscribes to the queue, never connecting to the plant network directly.
Aevus never writes OPC UA. Our IAM policy at the cloud account boundary denies the protocol-write APIs entirely. The boundary is enforced by IL-9000 — architectural, not procedural.
That's OPC UA.
If your facility is migrating to OPC UA — or running mixed Modbus + OPC UA — and you want predictive intelligence above the protocol layer without writing back to a single device, that's the conversation we'd love.
Related Articles
Function codes, data tables, and the float packing gotcha.
The 5 compute tiers and the cloud-vs-edge decision framework.
SCADA, MES, CMMS, ERP into one decision surface.
Ready to see how this applies to your operation? Start a pilot conversation — no commitment, no field changes.