OPC DA was the workhorse of industrial communication for over two decades. It connected PLCs to SCADA systems, HMIs to historians, and control rooms to the factory floor. It worked.
But the world changed. Linux grew. Cloud computing arrived. Cybersecurity became critical. And OPC DA — locked to Windows, with no encryption, dependent on a technology Microsoft has abandoned — couldn’t keep up.
OPC UA was built to replace it. Not just as an upgrade, but as a complete redesign.
This article gives you the full comparison — every technical difference, the practical impact on your systems, and clear guidance on when to use each one.
Table of Contents
Quick Comparison Table
| Feature | OPC DA | OPC UA |
|---|---|---|
| Standard | OPC Data Access (1996) | IEC 62541 (2006, updated continuously) |
| Platform | Windows only | Any OS (Windows, Linux, macOS, embedded) |
| Technology base | Microsoft COM/DCOM | Independent TCP/IP stack |
| Data model | Flat tag hierarchy (Server/Group/Item) | Object-oriented with types and inheritance |
| Data exchanged | Value, Quality, Timestamp (VQT) | Full semantic model with metadata |
| Security | None built-in (relies on DCOM) | Encryption, certificates, access control, audit |
| Scope | Real-time data only | Real-time + historical + alarms + events + methods |
| Transport | DCOM (dynamic ports) | TCP port 4840, HTTPS, WebSockets |
| Firewall friendly | No | Yes (single port) |
| Discovery | Limited | Automatic server and endpoint discovery |
| Communication model | Client-server only | Client-server + Pub/Sub |
| Cloud support | No | Yes (via MQTT, AMQP, HTTPS) |
| Companion specs | None | 60+ industry-specific models |
| Status | Maintenance mode (legacy) | Active development |
What Is OPC DA?
OPC DA (Data Access) was the first and most widely used OPC Classic specification. Released in 1996 by the OPC Foundation, it defined a standard way for software applications to read and write real-time data from industrial hardware — PLCs, RTUs, DCS controllers, and sensors.
OPC DA introduced three core concepts. A Server connects to hardware devices and exposes their data. A Group organizes data items and defines update rates. An Item represents a single data point — a tag with a Value, Quality, and Timestamp (VQT).
OPC DA was revolutionary for its time. Before it, every SCADA vendor had to write custom drivers for every PLC brand. OPC DA created a standard interface that any SCADA could use to connect to any OPC DA server.
How OPC DA works under the hood
OPC DA is built on Microsoft’s COM (Component Object Model) and DCOM (Distributed COM) technology. COM handles local communication between software components on the same machine. DCOM extends this to communicate between machines on a network.
This architecture means OPC DA only works on Windows. The server must run on Windows. The client must run on Windows. Cross-platform communication isn’t possible without third-party bridging tools.
The DCOM problem
Anyone who’s configured DCOM for OPC knows the pain. You have to configure DCOM permissions on both client and server machines, set up Windows user accounts with the right privileges, open multiple firewall ports (DCOM uses dynamic port allocation), troubleshoot cryptic “Access Denied” errors that have dozens of possible causes, and deal with connection drops that require restarting services.
DCOM was designed for enterprise software communication in the 1990s — not for industrial control systems. It’s fragile, hard to debug, and a constant source of headaches for automation engineers.
Microsoft has also steadily reduced DCOM functionality in newer Windows versions. Recent Windows updates have tightened DCOM security defaults, breaking some existing OPC DA installations. The writing is on the wall.
What Is OPC UA?
OPC UA (Unified Architecture) was released in 2006 and became the international standard IEC 62541 in 2016. It was designed from scratch to solve every limitation of OPC DA — while keeping the core purpose of vendor-independent data exchange.
OPC UA isn’t just “OPC DA version 2.” It’s a completely different architecture that combines all the separate OPC Classic specifications (DA, HDA, A&E) into a single unified framework with modern security, cross-platform support, and rich data modeling.
The Key Differences Explained
1. Platform independence
OPC DA: Windows only. Period. The COM/DCOM dependency makes it impossible to run on Linux, embedded systems, or cloud platforms without wrappers.
OPC UA: Runs on anything. The OPC Foundation provides reference implementations in ANSI C, Java, and .NET. Open-source stacks exist for Python, JavaScript, Rust, and Go. Servers run on microcontrollers with 15 KB of RAM up to enterprise cloud platforms.
Why it matters: Modern industrial architecture includes Linux-based edge devices, container environments like Docker, and cloud platforms. OPC DA can’t reach any of them natively.
2. Security
This is the most critical difference.
OPC DA: Has no security of its own. DCOM provides basic Windows authentication, but there’s no encryption, no message signing, no certificate management, and no audit trail. Data travels in plain text across the network. Anyone sniffing traffic can read it.
OPC UA: Security is built into every layer. Application authentication through X.509 certificates. Message encryption using AES-256. Message signing to detect tampering. User-level authentication with username/password or certificates. Fine-grained authorization down to individual nodes. Audit logging for compliance and forensics. Multiple security policies (Basic256Sha256, Aes256_Sha256_RsaPss, etc.) that can be updated as cryptographic standards evolve.
The German Federal Office for Information Security (BSI) analyzed OPC UA’s security and found no systematic errors. OPC DA has never undergone comparable scrutiny because there’s nothing to analyze — it has no security architecture.
Why it matters: Cyberattacks on industrial systems are increasing every year. Running unencrypted OPC DA on your control network is a liability. Regulatory frameworks like IEC 62443 and NIS2 increasingly require encrypted industrial communication.
3. Data model
OPC DA: Uses a flat hierarchy — Server → Group → Item. Each item has three attributes: Value, Quality, and Timestamp (VQT). That’s it. There’s no way to describe what the value means, what its engineering units are, what alarm limits apply, or how it relates to other data. You need external documentation for all of that.
OPC UA: Uses an object-oriented model with types, inheritance, references, and metadata. A temperature reading doesn’t come as a raw number — it comes as a typed variable with engineering units (°C), alarm limits (High: 80, Low: 10), quality status, relationships to its parent object (Tank_01), and type information (AnalogItemType). Clients can discover all of this at runtime without external documentation.
Why it matters: In OPC DA, integrating a new device means mapping tags manually with a spreadsheet. In OPC UA, the device describes itself. This cuts integration time from weeks to hours, especially when companion specifications are used.
4. Scope and functionality
OPC DA: Handles real-time data only — current values of tags. If you need historical data, you need a separate OPC HDA server. If you need alarms, you need OPC A&E. Each requires its own server, its own connection, and its own API.
OPC UA: Combines everything into one framework. A single OPC UA server can provide real-time data (equivalent to OPC DA), historical data (equivalent to OPC HDA), alarms and events (equivalent to OPC A&E), callable methods (no OPC Classic equivalent), and complex structured data types. One connection, one API, one address space.
Why it matters: Fewer servers to manage, fewer connections to maintain, fewer failure points. And the unified Browse service means you explore everything — data, history, alarms, methods — through the same interface.
5. Communication model
OPC DA: Client-server only. A client connects directly to a server. If you need data from 50 servers, you maintain 50 connections.
OPC UA: Supports both client-server and publish-subscribe (Pub/Sub). Pub/Sub allows one-to-many data distribution without direct connections — essential for cloud integration, large-scale data collection, and scenarios where multiple consumers need the same data. OPC UA Pub/Sub can run over MQTT, AMQP, or UDP.
6. Network and firewall behavior
OPC DA: DCOM uses dynamic port allocation. When a client connects to a server, DCOM negotiates a random port for the data channel. This means you either open a wide range of ports in your firewall (bad security) or use DCOM tunneling software (added complexity and cost).
OPC UA: Uses a single TCP port — 4840 by default (IANA registered). One firewall rule. Works cleanly through NAT and proxies. No tunneling needed.
7. Discovery
OPC DA: Limited. Clients can browse a machine for registered OPC servers using the OPCEnum utility, but there’s no standardized way to discover servers across a network or learn their security requirements before connecting.
OPC UA: Full automatic discovery. FindServers discovers servers on the network. GetEndpoints returns each server’s available endpoints with their security policies. Dedicated Discovery Servers maintain a registry of all servers in a system. Clients can find, evaluate, and connect to any server without prior configuration.
8. Future and industry support
OPC DA: In maintenance mode. The OPC Foundation has stopped all new development on OPC Classic specifications. Major automation vendors support OPC DA for backward compatibility but market OPC UA as the strategic standard. Microsoft’s declining investment in COM/DCOM technology means the underlying platform is deteriorating.
OPC UA: Under active development. The specification is continuously updated (current version 1.05). New companion specifications are being released regularly. Every major PLC vendor (Siemens, Rockwell, Beckhoff, Schneider, ABB, Omron) now ships PLCs with built-in OPC UA servers. The RAMI 4.0 reference architecture requires OPC UA for the communication layer.
When OPC DA Still Makes Sense
Despite its limitations, OPC DA isn’t disappearing overnight. It still makes sense when your entire infrastructure is Windows-based and will remain so, your existing OPC DA installations are working reliably, migration budget isn’t available yet, and your security requirements can be met with network-level protections (VPNs, firewalls, segmented networks).
But even in these cases, plan for eventual migration. Every year, the gap widens as OPC UA gains features and OPC DA’s underlying technology erodes.
When to Choose OPC UA
For any new project, the answer is simple: OPC UA. Specifically, choose OPC UA when you need cross-platform support, security is a requirement (and it always should be), you’re integrating with cloud platforms or IIoT systems, you need more than just real-time data (history, alarms, methods), your Industry 4.0 or smart manufacturing initiative requires it, and you want vendor independence and future-proofing.
Bridging the Gap: Running Both
Most real-world sites run both OPC DA and OPC UA during transition. OPC UA wrappers and gateways (from vendors like Matrikon, Kepware, and Software Toolbox) let OPC UA clients access data from existing OPC DA servers. This means you can start using OPC UA immediately on the client side while gradually replacing OPC DA servers as equipment is upgraded.
The key is to make OPC UA your standard for all new connections, and use wrappers to bridge legacy OPC DA systems until they’re replaced.
Conclusion
OPC DA served the industry well for over 25 years. It proved that vendor-independent data exchange was possible and valuable. But its foundation — Windows, COM/DCOM, no security, flat data models — belongs to a different era.
OPC UA carries the same mission forward with a modern architecture: platform-independent, secure by design, semantically rich, and built for the connected, cloud-integrated industrial world we live in now.
The question isn’t whether to move to OPC UA. It’s when and how. For new installations, the answer is now. For existing systems, plan a phased migration aligned with your equipment refresh cycles. And for everything in between, use wrappers to bridge the gap.
The longer you wait, the harder migration becomes — and the more exposed your systems are to security risks that OPC DA simply cannot address.