OPC UA Protocol: The Complete 2026 Technical Guide

Last Updated: 2026-06-03

The OPC UA protocol is the open, ISO-standardised industrial interoperability backbone that, by 2026, has effectively won the war for vendor-neutral OT semantics. If you are designing a greenfield line, retrofitting a brownfield plant, or wiring a digital twin to a fleet of PLCs, the question is no longer “should we use OPC UA?” but “which transport binding, which companion specification, and which security profile?” The 2026 answer is a stack: OPC UA Part 1–22 core + UA FX for field-level + PubSub over MQTT or UDP for north-south and lateral data flow + TSN where determinism matters + GDS-driven X.509 for trust. This guide walks through every layer of that stack with specification-level precision, refreshed CVE posture, and updated stack/SDK recommendations for 2026.

OPC UA is published as the IEC 62541 series and maintained by the OPC Foundation. Unlike its DCOM-bound ancestor OPC Classic, OPC UA is platform-neutral, transport-flexible, semantically rich, and built around modern cryptography. It is the protocol most cited in ISA-95 Level 2-3 integration tenders globally, and the only industrial protocol that simultaneously addresses information modelling, security, and transport in one normative family.

What OPC UA is and why it exists

OPC UA — Open Platform Communications Unified Architecture — replaced the COM/DCOM-tethered Classic OPC stack (DA, HDA, A&E) starting with the IEC 62541 publication in 2008. The motivation was blunt: DCOM was unroutable through firewalls, Windows-only, fragile across Microsoft service-pack changes, and had no native security model worthy of an industrial network in the post-Stuxnet era.

OPC UA delivers four things Classic OPC could not:

1. Platform independence — the wire protocol is a binary encoding (or JSON, or XML) over TCP, HTTPS, UDP, MQTT, or AMQP. There is no Microsoft dependency.
2. Built-in security — X.509 certificate-based mutual authentication, signed and encrypted messages, configurable security policies (Basic256Sha256, Aes128_Sha256_RsaOaep, Aes256_Sha256_RsaPss), user identity tokens, and the Global Discovery Server (GDS) for certificate lifecycle.
3. Object-oriented information modelling — instead of flat tag lists, OPC UA exposes a typed, browsable address space with inheritance, references, methods, events, and historical data.
4. Companion-spec extensibility — domain consortia (VDMA, MTConnect, Euromap, AutomationML, IEC TC65) publish OPC UA companion specifications that bolt a standard information model onto the core stack.

The protocol is normative across 22 parts of IEC 62541. The most relevant for engineers: Part 1 (overview), Part 3 (address-space model), Part 4 (services), Part 5 (information model), Part 6 (mappings — TCP/HTTPS), Part 8 (DA), Part 11 (HA), Part 12 (discovery and GDS), Part 14 (PubSub), Part 18 (role-based security), Part 21 (PubSub over MQTT — added in the 1.05 series), and Part 22 (Pub/Sub for Field eXchange — UA FX) finalised in 2024.

The OPC UA information model (nodes, references, types)

The address space is a directed graph, not a tree. Every entity is a Node, every Node has a NodeId, and every relationship between nodes is a Reference of a defined ReferenceType. There are eight NodeClasses defined in Part 3: Object, Variable, Method, ObjectType, VariableType, ReferenceType, DataType, View.

A typical pump asset in an OPC UA address space looks like this:

• Pump_017 (Object, type PumpType)
• HasComponent -> FlowRate (Variable, type Double, EU m3/h)
• HasComponent -> Status (Variable, type PumpStatusEnum)
• HasComponent -> Start (Method)
• HasComponent -> Stop (Method)
• GeneratesEvent -> PumpFaultEventType
• HasHistoricalConfiguration -> historical access node for FlowRate

The combination of typed nodes plus standard references means a client can browse a server it has never seen before and discover not just what tags exist but what they mean. That is the semantic layer that allows a digital twin platform to ingest data from a Siemens, Rockwell, Beckhoff, and B&R controller without a per-vendor mapping table — provided each vendor implements the relevant companion spec.

Each variable carries a DataValue containing the value, a StatusCode, a source timestamp, and a server timestamp. Subscriptions deliver MonitoredItem notifications using either DataChangeFilter or EventFilter, with configurable sampling intervals, queue sizes, and deadband logic. This is materially richer than a Modbus poll or an MQTT topic, and it is what justifies the heavier on-the-wire footprint.

Companion specifications — Robotics, Machinery, MTConnect, Energy, Process Automation

Companion specifications are the killer app of OPC UA. The core spec gives you the modelling tools; companion specs use those tools to define standardised information models per domain. By 2026 the OPC Foundation catalogue lists over 75 ratified companion specs. The most consequential:

• OPC UA for Robotics (VDMA + OPC Foundation, Part 40010-1) — standard MotionDevice, Axis, SafetyState, TaskControl nodes. Adopted by ABB, KUKA, Fanuc, Yaskawa, Universal Robots.
• OPC UA for Machinery (VDMA 40001-x) — the umbrella for sector specifications: MachineIdentification, MachineMonitoring, JobManagement, Notification. The base brick everyone composes against.
• MTConnect / OPC UA Companion Specification — bridges the CNC-machining world’s MTConnect XML model into OPC UA nodes, ratified in 2022 and widely deployed across Mazak, DMG MORI, Okuma controllers.
• OPC UA for IEC 61850 / Energy — bridges substation automation and DER fleets.
• OPC UA for Process Automation (NAMUR / NOA) — the open architecture’s data-plane choice, increasingly displacing HART-IP for second-channel diagnostics.
• OPC UA for Injection Moulding (Euromap 77/79/83) and OPC UA for Plastics.

If you are building a digital twin or PLM connector, your first design move in 2026 is to map your platform’s canonical model to the relevant companion spec rather than invent a bespoke schema. The semantic interoperability win is enormous.

OPC UA over TCP vs PubSub (UDP and MQTT) — when each wins

OPC UA originally shipped with one transport: the binary protocol over a single TCP socket per session (opc.tcp://). Part 6 also defines HTTPS and WebSocket bindings, used mostly for browser-side dashboards and where corporate firewalls force TLS-443.

Part 14, introduced in the 1.04 series and substantially expanded in 1.05, defines PubSub — a publisher-subscriber pattern decoupled from the session model. Publishers emit NetworkMessages containing one or more DataSetMessages. The transport is pluggable: UDP unicast, UDP multicast, MQTT, AMQP. Two encodings are supported: UADP (binary, compact) and JSON (introspectable, broker-friendly).

When does each transport make sense?

• Client-Server over OPC UA TCP — request/response semantics, method calls, browsing the address space, configuration writes, historical reads. The right choice for engineering tools, SCADA HMI workstations, and anywhere you need acknowledged writes.
• PubSub over UDP multicast — high-frequency cyclic telemetry on a controlled LAN, especially with TSN. Sub-millisecond cycle times achievable. The right choice for controller-to-controller and field-level data.
• PubSub over MQTT — north-south telemetry across plants, sites, and cloud. Lets you reuse an existing Sparkplug or fleet MQTT broker. The right choice when you already have an MQTT backbone and want OPC UA’s semantic richness on top.
• PubSub over AMQP — enterprise message-bus integration with Azure Service Bus, RabbitMQ, ActiveMQ. The right choice for SAP and ERP-adjacent pipelines.

The 2026 architectural pattern at most plants we audit looks like this: OPC UA TCP for engineering and SCADA, PubSub over MQTT to the line edge broker, and (where TSN is available) PubSub over UDP for FX-level cyclic data. For a deeper dive on the MQTT side of that stack, see MQTT Protocol: The Complete Technical Guide.

OPC UA FX (field-level extensions) — what changed in 2024-2026

OPC UA FX (Field eXchange) is the most significant addition to the OPC UA family this decade. Released as a coordinated set of specifications (Parts 80-83, plus the FX 1.05 profile) by the OPC Foundation FLC initiative in 2024 and refined through 2025, UA FX extends OPC UA down to the sensor-actuator field level — territory previously owned by Profinet, EtherNet/IP, EtherCAT, and Powerlink.

UA FX defines:

• UAFX Asset — the standard runtime model for any field-level participant (PLC, drive, smart I/O block, sensor).
• FX Connections — typed, configured publisher-subscriber relationships between two assets, with a ConnectionEndpoint on each side carrying QoS, security, and timing.
• Offline Engineering — UAFX descriptors are exportable as XML so connections can be commissioned in an engineering tool, then loaded onto devices.
• Controller-to-Controller — the headline FX use case: two PLCs exchanging cyclic state without a SCADA intermediary, replacing proprietary CC-Link / X-bus / Profinet RT links with a vendor-neutral channel.
• TSN integration — UA FX is designed to be carried over TSN-capable Ethernet for deterministic cyclic traffic.

What changed between 2024 and mid-2026? Three things matter:

1. Profile certification — the OPC Foundation’s UA FX Compliance Programme went live in late 2024. By Q1 2026 there are over 30 certified field devices and a handful of certified controllers from Siemens, Beckhoff, B&R, Bosch Rexroth, Phoenix Contact, and Wago. Buy certified.
2. open62541 FX support — the leading open-source stack added FX 1.05 profile support in the 1.4 release line, making FX accessible to anyone willing to compile C99. Eclipse Milo’s roadmap targets FX in its 1.0 release.
3. TSN convergence — the IEC/IEEE 60802 industrial TSN profile published in 2025 codifies the bridge-side configuration UA FX expects. The two specs now compose cleanly.

For greenfield 2026 cell designs aiming at sub-millisecond cyclic determinism on an open stack, the UA FX + TSN + open62541 combination is now a credible answer where the only previous option was a proprietary fieldbus.

OPC UA over TSN for deterministic control

Time-Sensitive Networking is the IEEE 802.1 set of amendments — chiefly 802.1AS-Rev (time sync), 802.1Qbv (time-aware shaping), 802.1Qbu (frame preemption), and 802.1CB (frame replication) — that turn standard Ethernet into a deterministic medium. The IEC/IEEE 60802 profile, ratified in 2025, narrows the configuration space for industrial use.

OPC UA layers on top of TSN cleanly because PubSub UADP messages can be bin-packed into TSN’s protected traffic class. The result: cyclic times of 250 µs and jitter under 1 µs at the network layer, which is competitive with EtherCAT and faster than legacy Profinet RT.

The catch in 2026 remains commissioning. TSN configuration is non-trivial — every bridge has to be told its Qbv gate-control list, every endpoint has to be in sync, and a fully centralised network configuration (CNC) tool is still maturing. Plan for an integrator-led commissioning phase, and prefer single-vendor switch fabric for the first cell.

Security model (X.509, certificates, security policies, GDS)

Security in OPC UA is built into the stack, not bolted on. The relevant parts are Part 2 (security model overview), Part 4 (services include security parameters), Part 6 (channel-layer encryption), Part 12 (Global Discovery Server), and Part 18 (role-based access control).

The four pillars:

• Channel security — every secure channel uses asymmetric handshake (RSA or ECC) to negotiate symmetric session keys (AES-128 or AES-256). Messages are signed, optionally encrypted. Security policies in active use as of 2026: Aes128_Sha256_RsaOaep, Aes256_Sha256_RsaPss. Legacy Basic128Rsa15 and Basic256 are deprecated and SHOULD be refused.
• Certificate-based identity — both server and client present X.509 certificates. Servers maintain a trust list and an issuer list; clients do the same. The protocol does not depend on a public CA — most plants run a private PKI.
• User identity tokens — anonymous, username/password, or X.509 user certificates, plus the increasingly common JWT token (introduced in Part 4 amendment, widely supported by 2024).
• GDS — the Global Discovery Server (Part 12) provides certificate enrolment, renewal, and revocation list distribution. Treat it as the OT equivalent of an internal ACME endpoint. 2026 best practice is to deploy GDS on every site network and automate cert rotation on a 12-month cycle.

Role-based access (Part 18) lets you grant a Operator role read/subscribe access while reserving Engineer role for method calls and writes. Mature SDKs map roles to address-space nodes directly.

CVEs and security posture in 2026

OPC UA’s security model is sound; the implementations have, predictably, been the soft underbelly. The 2026 picture:

• CVE-2022-25304 (open62541, fixed in 1.3.4) — heap overflow in decoding crafted secure channel messages. Long since patched but still found in unpatched embedded controllers.
• CVE-2023-31048, CVE-2023-31049 (Unified Automation .NET SDK) — path-traversal in the configuration tool. Patched in 3.2.x.
• CVE-2024-28833 (Eclipse Milo, fixed in 0.6.12) — XML External Entity in nodeset parsing. Patched.
• CVE-2024-42330 (Siemens SIMATIC S7-1500 OPC UA server) — DoS via malformed session activation. Patched in firmware 3.1.5 onwards.
• CVE-2025-1135 (open62541, fixed in 1.4.6) — improper validation of MonitoredItem parameters leading to integer overflow.
• CVE-2025-30214 (Beckhoff TwinCAT OPC UA Server) — authentication bypass when GDS push management is misconfigured.
• CVE-2026-1148 (Kepware KEPServerEX 6) — TLS downgrade due to allowed Basic128Rsa15 policy in default config. Mitigation: explicitly disable deprecated policies.

The pattern is consistent: parsing bugs in core stacks, configuration mistakes in vendor servers, and legacy security-policy bleed-through. Defensive posture for 2026:

1. Pin SDK versions and patch on a defined cadence; subscribe to the OPC Foundation security bulletins.
2. Disable None, Basic128Rsa15, and Basic256 security policies at every endpoint.
3. Reject anonymous identity tokens on production servers.
4. Deploy GDS and rotate certificates at least annually.
5. Segment OPC UA traffic onto dedicated VLANs and apply deep packet inspection where possible — Claroty, Nozomi, Dragos, and Tenable OT now ship OPC UA-aware decoders.
6. For internet-exposed UA endpoints (rare and discouraged), enforce mutual TLS via a UA gateway or a reverse proxy with cert pinning.

There is no widely exploited OPC UA worm in 2026, and the protocol itself has held up better than DNP3, Modbus TCP, or S7 in red-team engagements. The discipline is keeping implementations patched.

SDKs and stacks

By 2026 the SDK landscape has settled into a clear tier of options:

• open62541 — the dominant open-source C99 stack. BSD-licensed, embeds on Cortex-M4 and up, used by Siemens, Beckhoff, and dozens of OEMs internally. UA FX 1.05 profile support landed in 1.4. The reference choice for embedded and Linux edge.
• Eclipse Milo — Java/Kotlin stack, EPL-2.0 licensed. Solid client and server, used by enterprise Java integrators and Apache Camel pipelines. 1.0 release is targeting full FX support.
• OPC Foundation .NET Standard Stack — official .NET reference stack on GitHub (GPL with a commercial alternative). The right choice for Windows-side servers, gateway products, and tools.
• OPC Foundation UA-.NET Sample Code — bundled clients, GDS server, certificate tooling.
• Unified Automation .NET / C++ / Java SDKs — commercial, fully featured, GDS-included, the de facto choice for product vendors who want documented support contracts. UaExpert (free) remains the industry-standard test client.
• Prosys OPC UA SDK for Java — commercial Java SDK with strong companion-spec tooling.
• FreeOpcUa / asyncua (Python) — the dominant Python client library, MIT-licensed. Excellent for digital-twin ingestion scripts, MES connectors, and anything where you want OPC UA in a Jupyter notebook. Not aimed at high-throughput servers.
• node-opcua — the Node.js stack. Used in many edge gateway products and OT-to-cloud bridges.
• Matrikon OPC UA Tunneller / Kepware KEPServerEX / Cogent DataHub — commercial connectivity products if you need polyglot protocol bridging more than raw SDK control.
• ASP.NET-based UA web servers — increasingly common for browser-side dashboards; Microsoft’s Azure Industrial IoT reference uses ASP.NET hosts for its UA gateway.

For a 2026 greenfield digital twin connector targeting Linux edge nodes, the canonical choice is open62541 server-side and asyncua client-side for the Python data pipeline. For a Windows-hosted SCADA-tier integration, Unified Automation .NET. For Java enterprise stacks, Milo.

Performance and capacity planning

Realistic 2026 numbers from production deployments:

• Client-Server over OPC UA TCP — a well-tuned open62541 server on a quad-core Cortex-A53 sustains 50,000–80,000 monitored items at 100 ms sampling, with subscription delivery latency under 50 ms. A Xeon-class Windows host with Unified Automation .NET handles 500,000+ monitored items.
• PubSub UADP over UDP — cycle times down to 250 µs achievable with TSN; without TSN, 1 ms is realistic on a quiet LAN, 10 ms on a shared one.
• PubSub JSON over MQTT — broker becomes the bottleneck. EMQX or HiveMQ sustain 100k+ messages/sec of typical UADP payloads; JSON encoding adds 2-4x overhead.
• Address space size — open62541 happily holds 1M nodes in RAM at roughly 500 bytes per node.
• Secure channel handshake — RSA-2048 handshake ~30 ms on modern x86, ~150 ms on Cortex-A53. ECC-based policies cut that roughly in half — prefer them on embedded.

Capacity-plan against the harder of: monitored items × sampling rate, write rate × secure-channel throughput, and number of concurrent sessions. Most failures we see in production are concurrent-session-count limits in vendor servers being silently capped at 16 or 32.

Migration from OPC Classic (DA/HDA/AE)

Brownfield plants still run DCOM-based OPC DA, HDA, and AE servers — and will for years. The migration playbook in 2026:

1. Deploy a UA wrapper / tunneller in front of each Classic server. Matrikon UA Tunneller, Kepware ClientAce, Cogent DataHub, and Unified Automation’s UA Gateway all do this.
2. Map Classic tag namespaces into a flat UA address space at first — do not over-engineer the information model on day one.
3. Layer a companion-spec view above the flat namespace once the line stabilises. This is where you earn the semantic interoperability win.
4. Retire Classic links plant-by-plant as controllers reach end-of-life. The economics rarely justify forcing migration before that.
5. Push DCOM off the OT network with firewall rules as soon as the tunneller is proven. DCOM remains a top exploit vector in legacy plants.

The OPC Foundation’s UaClassicWrapper reference implementation is a useful starting point, though most plants will use a vendor product for support reasons.

OPC UA vs MQTT — when each wins

The most common 2026 architecture debate is OPC UA vs MQTT for IIoT north-south flows. The honest answer is they solve different problems and modern stacks use both.

• OPC UA wins when you need semantic richness, browsable address space, method calls, role-based security, historical access, and standardised companion-spec models. Engineering and SCADA traffic is OPC UA-shaped.
• MQTT wins when you need lightweight pub-sub at massive fan-out, broker-mediated decoupling, simple firewall traversal, and a thriving ecosystem of brokers and ingestion endpoints. Sparkplug B closes much of OPC UA’s semantic gap for telemetry.
• The hybrid — OPC UA address space at the edge, PubSub over MQTT as the wire format, Sparkplug B as the topic and payload convention where you do not need full UA modelling. This is the 2026 plant-floor default.

For Modbus-era brownfield estates considering an UA-first modernisation, our companion piece Modbus Protocol: The Complete Guide covers the wrapper patterns that get Modbus tags into a UA address space cleanly.

Trade-offs and gotchas

• Implementation complexity — OPC UA is not a weekend protocol. Expect a multi-week ramp even for senior engineers.
• Embedded footprint — open62541 compiles to roughly 250 KB on Cortex-M, but a full server with PubSub and security pushes 500 KB+. Plan flash and RAM accordingly.
• Discovery server pitfalls — many vendor servers ship Local Discovery Server (LDS) enabled by default with weak certificates. Audit and harden.
• Certificate management is the operational pain — without GDS automation, certs expire and lines stop. Treat cert rotation as a first-class runbook.
• Companion-spec drift — vendors often implement an old draft of a companion spec. Always check the version namespace URI.
• PubSub JSON verbosity — JSON UADP is 2-4x larger on the wire than binary UADP. Use binary unless human introspection is a hard requirement.
• TSN commissioning cost — TSN is genuinely deterministic, but plan an integrator-led cell-level commissioning sprint.

Practical recommendations

For a 2026 plant-floor or digital-twin programme:

1. Start from a companion spec. If one exists for your domain, do not reinvent the model.
2. Pick open62541 for embedded, Milo for Java, asyncua for Python pipelines, Unified Automation for Windows products.
3. Plan PubSub over MQTT as your default north-south transport unless you have a hard determinism requirement that justifies UDP + TSN.
4. Pilot UA FX for one new cell in 2026. Get the engineering team familiar before it becomes the default in 2027.
5. Deploy GDS from day one even if you only have ten endpoints. The operational habit matters more than the scale.
6. Disable deprecated security policies in every server config.
7. Subscribe to OPC Foundation security advisories and patch SDKs on a quarterly cadence at minimum.
8. Run UaExpert as the canonical test client in every commissioning kit.
9. Wrap Classic OPC behind UA rather than forcing migration on still-supported lines.
10. Document the address-space model in your PLM/digital-twin platform so engineering changes flow forward, not backward.

FAQ

1. Is OPC UA the same as OPC Classic?
No. OPC Classic was DCOM-based and Windows-only. OPC UA is a different, platform-neutral protocol family standardised as IEC 62541. They share the OPC brand and conceptual lineage but are not wire-compatible.

2. Do I need a broker for OPC UA?
For Client-Server (opc.tcp://), no — clients connect directly to servers. For PubSub over MQTT or AMQP, yes, you need the respective broker. PubSub over UDP needs no broker, just multicast-capable network gear.

3. What is OPC UA FX and do I need it now?
UA FX (Field eXchange) extends OPC UA to deterministic field-level controller-to-controller and controller-to-device communication. You need it if you are designing new cells in 2026 and want to retire proprietary fieldbus links on an open stack. For existing Profinet/EtherNet/IP plants, no urgency yet.

4. Is OPC UA secure enough for internet-exposed endpoints?
The protocol’s security model is sound. Practically, do not expose OPC UA endpoints to the internet directly. Run them behind a UA gateway or reverse proxy with mutual TLS and network-layer access controls.

5. How does OPC UA compare with MQTT and Sparkplug B?
OPC UA carries richer semantics — typed nodes, methods, browsable address space — whereas MQTT is a transport with topic strings. Sparkplug B adds a semantic layer over MQTT that approaches but does not equal full UA modelling. Many 2026 plants run both: UA at the edge, PubSub over MQTT to the cloud.

6. Which SDK should I use for a Python data pipeline?
asyncua (the FreeOpcUa successor) is the established choice. It is MIT-licensed, async-first, and supports modern security policies. For server-side high-throughput work, prefer open62541 with a thin Python binding rather than asyncua server mode.

7. How often should I rotate OPC UA certificates?
Default to 12 months for endpoint certificates and rotate via GDS push management. If you cannot automate rotation, 24 months is the maximum we would recommend; anything longer creates an avoidable outage risk when a cert eventually expires.

Last updated: 2026-06-03

This guide was refreshed on 2026-06-03 to cover OPC UA FX (Parts 80-83), PubSub over MQTT (Part 21), the IEC/IEEE 60802 TSN profile, 2024-2026 CVEs across the major stacks, and current SDK release notes. The next refresh is scheduled for Q4 2026 after the OPC Foundation’s planned 1.06 specification release.

Further reading

1. OPC Foundation — OPC UA Online Reference (Parts 1–22). https://reference.opcfoundation.org/
2. IEC 62541 series — Industrial communication networks — OPC Unified Architecture. International Electrotechnical Commission, 2008–2025.
3. OPC Foundation — OPC UA Field eXchange (UA FX) Specification, version 1.05. 2024.
4. OPC Foundation — Part 14: PubSub, including JSON and MQTT mappings (Part 21). 2024 amendment.
5. IEC/IEEE 60802 — Time-Sensitive Networking Profile for Industrial Automation. 2025.
6. VDMA — OPC UA Companion Specification for Machinery, Robotics, and Domain Models. https://www.vdma.org/opc-ua
7. open62541 documentation and release notes — https://www.open62541.org/
8. Eclipse Milo — OPC UA Java Stack documentation. https://github.com/eclipse/milo
9. FreeOpcUa / asyncua — Python OPC UA Library Documentation. https://github.com/FreeOpcUa/opcua-asyncio
10. OPC Foundation — Security Bulletins and Patch Advisories Archive. https://opcfoundation.org/security
11. NIST National Vulnerability Database — OPC UA CVE search results. https://nvd.nist.gov/
12. IoT Digital Twin PLM — MQTT Protocol: The Complete Technical Guide and Modbus Protocol: The Complete Guide.