OPC UA vs OPC DA: Which Protocol Should You Use in 2026?

If you have ever set up an OPC connection between a SCADA system and a PLC and lost an afternoon to DCOM permission errors on a Windows server, you already understand the central problem this article exists to solve. OPC UA (Unified Architecture) is the modern replacement for what we now call OPC DA (Data Access, the original OPC Classic protocol). It removes DCOM, adds proper security, runs on more than Windows, and has been the official IEC standard since 2016. Yet plants across Southeast Asia still run substantial OPC DA traffic in 2026 — some by choice, most by inertia.

This article answers the question every plant engineer eventually asks: for this connection, OPC UA or OPC DA? And the related questions you will hit on the way: can the two run side by side, how do I migrate without disrupting production, what is the real security difference, and how does KEPServerEX serve as the bridge that lets both protocols coexist on the same plant data set.

The short answer

For any new project: OPC UA. For brownfield plants with working OPC DA clients: keep them running on DA, expose the same data over UA in parallel using a server like KEPServerEX, and migrate clients onto UA over the next equipment refresh cycle. Do not rip out working DA infrastructure just to switch protocols — the upgrade only pays off when the new clients actually need what UA gives them.

If you want the reasoning, the table, the security details, and the migration plan, read on.

A 90-second history of OPC

OPC stood for OLE for Process Control when the original specification was published by Microsoft and a small group of industrial automation vendors in 1996. The whole point was to free SCADA and HMI software from writing custom drivers for every PLC vendor. Instead, a PLC vendor or third party would publish an OPC server, and any OPC-compliant client could connect. Three flavours emerged in OPC Classic:

• OPC DA (Data Access): real-time tag values. By far the most common.
• OPC HDA (Historical Data Access): time-series queries for historians.
• OPC A&E (Alarms & Events): alarm propagation.

All three OPC Classic protocols were built on Microsoft’s Component Object Model and DCOM for remote calls. That decision made them work brilliantly inside a single Windows domain in 1996 and badly almost everywhere else.

By 2003 the OPC Foundation began designing a successor — the Unified Architecture — specifically to escape DCOM, support non-Windows platforms, fold DA + HDA + A&E into a single protocol with a richer information model, and bake in real security. The first OPC UA specification parts were published in 2006, with the full Phase I release (v1.01) finalised in 2009. OPC UA was then ratified as IEC 62541 in successive parts starting in 2010, with later parts standardised through 2016. The OPC Foundation has never formally deprecated OPC DA, but every active specification effort since 2010 has been on OPC UA. OPC DA is in maintenance.

What OPC DA is, what it does well, where it bites

OPC DA exposes plant-floor data as a flat list of items (tags), each with a value, a timestamp, and a quality flag (Good / Bad / Uncertain). A client subscribes to the items it wants, and the server sends updates whenever values change. That is essentially it — OPC DA does not describe relationships between tags, units, engineering ranges, or methods.

OPC DA does well:

• Latency is low on a single Windows machine or LAN segment with proper DCOM configuration.
• Mature: every classic SCADA, historian, and DCS supports it. Every major OPC server (KEPServerEX, Matrikon, Top Server, Cogent) ships a DA endpoint.
• Simple: small footprint, no certificate management, no information modelling. For one Windows server polling one PLC and feeding one SCADA, OPC DA gets out of the way.

Where OPC DA bites:

• DCOM is the source of most operational pain. Cross-machine DCOM requires symmetric user accounts (or careful domain trust), opens dynamic RPC ports (not a single configurable port), and is sensitive to Windows update changes that have repeatedly broken known-working setups over the years.
• Windows-only. No Linux, no Mac, no embedded edge boxes, no native cloud. Anything not running Windows needs a tunnel or a bridge.
• No protocol-level security. Authentication is implicit (the Windows user the client process runs as). There is no message signing, no encryption. If the network is hostile, DCOM is hostile.
• Limited information model. Tags are flat. You cannot express “Tank 5 contains Pump A which has Vibration X and Temperature Y” structurally — you have to encode the hierarchy in tag names like Tank5.PumpA.Vibration.
• Maintenance only. No new features are coming. New SCADA / MES / analytics products are increasingly UA-first.

What OPC UA is, what changed, what came along

OPC UA keeps the same conceptual model — servers expose data, clients consume it — but rebuilds everything underneath. The transport is plain TCP (the opc.tcp binary protocol) or HTTPS/SOAP. Security is baked in at the protocol layer. The address space is a structured graph instead of a flat list. And the protocol is OS-independent: there are OPC UA SDKs in C, C++, C#, Java, Python, and Rust, with reference implementations on Linux and embedded RTOSes.

What OPC UA adds:

• Cross-platform transport. Plain TCP on a configurable port (4840 is the IANA-assigned default; KEPServerEX uses 49320 by default). No DCOM. Any OS, any direction across firewalls.
• Built-in security. X.509 certificate-based mutual authentication, message signing, payload encryption. Policies are negotiated between client and server: None, Basic128Rsa15 (deprecated), Basic256 (deprecated), Basic256Sha256, Aes128_Sha256_RsaOaep, Aes256_Sha256_RsaPss. Best practice in 2026 is Basic256Sha256 or stronger.
• Information modelling. The address space is a graph of nodes with types, references, and metadata. A Tank node can have child nodes for Level, Temperature and Pump, with engineering units and ranges attached. Companion specifications standardise the model for specific industries: PackML (packaging), MDIS (subsea oil & gas), AutoID (RFID and barcode readers), OPC UA for FX (machine-to-machine), VDMA (mechanical engineering).
• Unified protocol. The OPC UA Server delivers current values and historical reads and alarm/events through one endpoint and one client SDK. The DA / HDA / A&E split is gone.
• Methods. A client can invoke a server-side method (e.g., “start batch”, “reset counter”) in addition to reading and writing tags. This is closer to a remote procedure call and enables MES-to-PLC orchestration.
• Pub/Sub (added in 2018). OPC UA Pub/Sub adds publish/subscribe semantics over UDP multicast or MQTT/AMQP brokers, so high-fan-out scenarios (one publisher, many subscribers) don’t have to run N parallel client/server sessions. OPC UA Pub/Sub over MQTT is the most common new deployment.
• Field Level Communications (FLC). The OPC Foundation’s effort to extend UA all the way down to the fieldbus, complementing or replacing PROFINET / EtherNet/IP / EtherCAT at Layer 7. Still emerging in 2026 but real silicon ships from Siemens, B&R, Hilscher.

OPC UA vs OPC DA: the side-by-side

Concern	OPC DA (Classic)	OPC UA (IEC 62541)
First published	1996	2006 (Phase I 2009; IEC 62541 from 2010)
Underlying transport	Microsoft DCOM	TCP (opc.tcp) or HTTPS/SOAP
Platform support	Windows only	Windows, Linux, macOS, embedded, browser (HTTPS)
Firewall friendliness	Dynamic RPC ports (135 + ephemeral)	Single configurable TCP port
Authentication	Implicit Windows user identity	X.509 certificate, username/password, or anonymous
Message security	None at the protocol level	Signed and/or encrypted (Basic256Sha256, AES-based)
Information model	Flat tag list with quality flag	Typed, structured address space; companion specs
Historical data	Separate protocol (OPC HDA)	Built into the unified server
Alarms & events	Separate protocol (OPC A&E)	Built into the unified server
Methods (RPC)	Not supported	First-class
Pub/Sub	Not supported	UDP multicast or MQTT/AMQP (added 2018)
Active development	Maintenance only	Ongoing — Pub/Sub, FLC, companion specs
Typical SCADA support	Universal (every classic SCADA)	Universal in modern releases
Default port	RPC dynamic (135 / ephemeral)	4840 (spec), 49320 (KEPServerEX)

The DCOM problem in plain language

Most arguments for migrating off OPC DA come back to DCOM. It is worth spelling out exactly what makes DCOM such a recurring pain on industrial networks:

1. Authentication is implicit. The client process runs as a Windows user; that user must be recognised by the server. Across two non-domain machines, you need matching local accounts on both sides with matching passwords. In a domain, the accounts must have permission on the server’s DCOM application. Mismatched SIDs after a re-image are a classic three-hour debugging session.
2. Dynamic ports. DCOM connects to TCP 135 to negotiate an actual data port (typically in the range 49152–65535). You can constrain this range with Windows Registry settings, but you cannot run DCOM cleanly through a stateful firewall by opening a single port.
3. Windows Updates break it. Microsoft has issued multiple security updates that hardened DCOM authentication (most notoriously the post-CVE-2021-26414 changes), each of which broke some previously working OPC DA setups until vendor updates caught up.
4. No encryption. DCOM traffic between two machines is not encrypted by default. On a hostile OT network, anyone with a SPAN port can read OPC DA values in clear.

OPC UA replaces all four problems with explicit protocol-layer mechanisms: X.509 certificates for authentication, a single configurable port, no Windows-Update dependency, and signed-and-encrypted messages by default.

Real-world scenarios: which to pick

Scenario 1 — New greenfield plant (or major modernization)

Use OPC UA from day one. Stand up KEPServerEX (or any UA-capable server), connect to the PLCs with native drivers, expose a single OPC UA endpoint with Basic256Sha256 and certificate-based authentication, and point every consumer (SCADA, historian, MES, analytics) at it. Do not enable the DA endpoint unless you have a specific legacy client that cannot speak UA.

Scenario 2 — Brownfield plant with working DA infrastructure

Keep what works. Configure your existing OPC server (most likely KEPServerEX or a Matrikon equivalent) to serve both DA and UA endpoints from the same tag database. Legacy clients keep connecting via DCOM; new clients (a new historian, a cloud bridge, an MES) connect via UA. Plan to retire DA clients during normal equipment refresh, not as a forced migration.

Scenario 3 — Cross-network or cross-site link

OPC UA every time. Cross-network OPC DA over DCOM is brittle and a firewall headache. OPC UA’s single-port TCP design (often tunnelled over a site-to-site VPN) is operationally far cleaner, and the certificate-based authentication adds a real security layer the moment you cross a network boundary.

Scenario 4 — Edge device, Linux historian, or cloud bridge

OPC UA is the only option that runs natively. There are commercial OPC DA-to-UA bridges (Cogent DataHub, OPC Router, Matrikon UA Wrapper) for cases where a Windows-only OPC DA server has to be made accessible to a Linux client — but you are paying for and operating a tunnel. If the original server can be reconfigured to expose UA, just do that.

Scenario 5 — High-throughput, many-client telemetry

OPC UA Pub/Sub over MQTT. A single OPC UA publisher pushes plant data to an MQTT broker; any number of analytics, MES, and cloud subscribers consume it without each holding an active client session against the OPC server. This is the pattern behind most Industry 4.0 / IIoT reference architectures in 2026, and the Kepware IoT Gateway plug-in implements it natively over Sparkplug B.

Scenario 6 — Regulatory or safety-critical environment (pharma, F&B, energy)

OPC UA with strict security. Regulators in pharma (FDA 21 CFR Part 11, EU Annex 11) and energy (NIS2, NERC CIP) increasingly require auditable authentication, encrypted communications, and access logs that OPC DA cannot provide at the protocol level. Even if your current SCADA still speaks DA, run UA on top so the security story has an evidence trail.

How KEPServerEX bridges DA and UA

This is where Kepware’s role becomes important. KEPServerEX sits between your PLCs (Siemens, Allen-Bradley, Modbus, Mitsubishi, Omron, GE, Yokogawa, etc.) and your applications. From a single tag database it can simultaneously:

• Serve OPC DA to legacy clients via DCOM
• Serve OPC UA on TCP 49320 with full security
• Publish MQTT and Sparkplug B via the IoT Gateway plug-in
• Expose REST endpoints for HTTP-based consumers

This is exactly the bridge most brownfield plants need: the existing DA clients keep working, new UA clients can be onboarded gradually, and the IoT Gateway lets cloud and analytics consumers tap the same tag set without touching the SCADA path. The cost of running both endpoints is negligible on a properly sized KEPServerEX server.

For a step-by-step example of exposing PLC tags through KEPServerEX, see the Siemens S7-1500 + KEPServerEX tutorial. The procedure is the same for Allen-Bradley, Modbus, and the other 150+ supported PLC families — only the device driver changes.

Security: a closer look

The security gap between OPC DA and OPC UA is bigger than a checkbox in the comparison table suggests. Some practical numbers:

• OPC DA has zero message signing or encryption at the protocol layer. Whatever security exists comes from the Windows authentication boundary and the network’s link-layer protections.
• OPC UA’s Basic256Sha256 policy uses RSA-2048 for handshakes, AES-256 for symmetric encryption, and SHA-256 for signing. It has been the recommended baseline since 2017.
• OPC UA’s newer Aes256_Sha256_RsaPss policy adds RSA-PSS padding (stronger than the older PKCS#1 v1.5 padding) and is the recommended choice for new 2026 deployments.
• The two older policies, Basic128Rsa15 and Basic256, are formally deprecated by the OPC Foundation and should be disabled on any production endpoint. The None policy is for bench testing only and must be disabled before exposing the server beyond the local OT network.

Pair OPC UA security with the broader OT cybersecurity stack — network segmentation, an inline OT firewall (such as OPSWAT OTfuse), USB media control (MetaDefender Kiosk) — and you have a defensible posture for regulated environments.

Performance: which is faster?

For a single Windows server-to-client connection on a fast LAN with well-configured DCOM, OPC DA can be marginally faster than OPC UA at very high tag-update rates, because UA serialises into a more verbose binary structure. In practice the difference is dwarfed by other factors — PLC scan rate, network latency, the OPC server’s own polling cycle — and you will not notice it on any normal SCADA or historian deployment.

OPC UA’s Pub/Sub mode meaningfully outperforms OPC DA in scenarios with many subscribers, because UA Pub/Sub broadcasts updates once instead of replying to each subscribed client individually. For one-to-many telemetry (think: 50 cloud analytics consumers reading the same plant data), OPC UA Pub/Sub is the clear winner.

Migration: an honest plan

Migrating a plant from OPC DA to OPC UA does not need to be a forklift project. The realistic order:

1. Upgrade your OPC server first, if it is not already serving both endpoints. KEPServerEX V6+ exposes UA out of the box.
2. Generate and exchange certificates. Create a long-lived X.509 server certificate on the KEPServerEX side, configure trusted client certificates for each consuming application, and pick a sane security policy (Basic256Sha256 or stronger).
3. Onboard new clients on UA only. Any new historian, MES, analytics tool, or cloud bridge connects via UA. Do not add new DA clients after this point.
4. Migrate existing clients during their next maintenance window. Most modern SCADA, historian, and MES products have UA support. Reconfigure the connection, test in a staging environment, switch over, decommission the DA path on that client.
5. Retire DA when the last client is gone. Disable the DA endpoint on the KEPServerEX server. Audit logs should show zero DA sessions for a sustained period before final shutdown.

In our experience commissioning Kepware deployments across Southeast Asia, a typical plant takes 6–18 months to complete this migration, with most of the time spent waiting for application vendor updates or scheduled maintenance windows. There is rarely a forcing function to compress it.

Common pitfalls when adopting OPC UA

• Leaving the None security policy enabled in production. Default KEPServerEX configurations enable it for first-connection convenience. Disable it before production cutover.
• Self-signed certificates that never expire. Issue a real X.509 certificate with a defined validity period and a rotation plan. Auditors will ask.
• Forgetting that OPC UA clients need their own certificates. The trust is mutual — the server must trust the client’s certificate too. Several “cannot connect” tickets are really “the client certificate is not in the server’s trust list.”
• Confusing the UA endpoint URL. KEPServerEX listens on opc.tcp://host:49320 by default; the standard OPC UA port is 4840. Mismatched ports are a five-minute fix that take five hours when nobody knows about the default.
• Mixing optimized and non-optimized Siemens DB access. Tangential to OPC, but it surfaces here: see the Siemens S7-1500 tutorial for the Siemens-side configuration that makes UA actually work end-to-end.

Frequently asked questions

Is OPC DA officially deprecated?

Not formally. The OPC Foundation continues to publish maintenance updates and certifications for OPC DA. In practice, no new features are being added; all standards work has shifted to OPC UA. New SCADA, historian, and MES products may or may not include a DA client at all.

Can OPC UA and OPC DA run on the same server?

Yes. KEPServerEX and most other major OPC servers (Matrikon, Top Server, Cogent DataHub as a tunnel) serve DA and UA endpoints concurrently from the same tag database. This is the recommended pattern for brownfield migration.

Does OPC UA require an internet connection or cloud service?

No. OPC UA runs entirely on your local network. The cloud connection patterns (Sparkplug B over MQTT, AWS IoT, Azure IoT Hub) are optional layers on top of OPC UA, not required for OPC UA to function.

What is OPC UA Pub/Sub and when should I use it?

OPC UA Pub/Sub is a publish-subscribe transport added to the OPC UA spec in 2018. Instead of a client polling the server, the server publishes data to a broker (MQTT or AMQP) or to UDP multicast, and any number of subscribers consume it. Use it when you have many consumers reading the same data — cloud telemetry, multi-system analytics, fleet-wide reporting. For one-to-one SCADA-to-PLC, traditional client/server OPC UA is simpler.

Can I run OPC UA on Linux or an embedded edge device?

Yes. The OPC Foundation publishes reference SDKs in multiple languages, and there are mature open-source implementations (open62541 in C, node-opcua in JavaScript, FreeOpcUa in Python). Commercial edge gateways from Siemens, Phoenix Contact, B&R, and others ship an OPC UA server out of the box.

Is OPC UA secure enough for regulated environments?

OPC UA with Basic256Sha256 or stronger policies, X.509 certificate authentication, and proper certificate lifecycle management is acceptable to auditors in pharma (FDA 21 CFR Part 11), food & beverage, and energy (NIS2, NERC CIP). The security itself is sufficient; the policy and operational discipline around certificates is what auditors actually examine.

Does OPC UA replace MQTT?

No. OPC UA and MQTT solve different problems. OPC UA describes plant data structurally (tags, types, relationships, methods); MQTT is a lightweight publish-subscribe transport. They combine: OPC UA Pub/Sub uses MQTT as one of its supported transports, and Sparkplug B is a convention layered on MQTT that borrows OPC UA’s information modelling ideas.

If I have one Windows PC, one PLC, and one SCADA, does OPC UA even matter?

Less. On a single-machine setup with no firewalls in between, OPC DA’s DCOM headaches mostly disappear. You can stay on OPC DA happily. The reasons to switch are non-Windows clients, cross-machine deployments, security requirements, or a need for OPC UA’s information modelling.

How does Kepware handle the OPC UA certificate lifecycle?

KEPServerEX includes a built-in certificate manager. On first install it generates a self-signed server certificate that you can later replace with a CA-issued one. Client certificates can be imported into the trust list via the same UI. For production, plan a rotation cycle (typically 1–3 years) and document the renewal procedure — certificate expiry has caused more than one OPC UA outage.

Next steps

1. If you already run KEPServerEX, audit which endpoints you have enabled. Open the OPC UA Configuration Manager and confirm that None is disabled and that you are on Basic256Sha256 or stronger.
2. If you are scoping a new project, default to OPC UA only. Disable OPC DA unless you have a specific legacy client that requires it.
3. If you are running a brownfield plant and want a written migration plan, contact us with your current OPC server, client inventory, and target end-state. We will return a phased migration plan within one business day.
4. For a broader view of where KEPServerEX fits in a plant, read the complete guide to Kepware industrial connectivity.

Allied Solutions Global is an authorized Kepware (PTC) distributor. KEPServerEX and Kepware are products of PTC Inc. OPC UA and OPC DA are specifications of the OPC Foundation.