OPC UA (Unified Architecture) is the industrial communication standard meant to replace OPC DA (Data Access) and the other OPC Classic specifications. It has been part of every Industry 4.0, interoperability and IT/OT convergence discussion for years. But between the OPC Foundation documentation and the reality of plants in production, there is a gap worth examining.
Anyone who works on real plants knows that adopting a protocol is never just about enabling a feature. It affects network architecture, firewall rules, certificate management, firmware compatibility, PLC CPU load and the ability of maintenance staff to manage everything over time.
OPC DA vs OPC UA: what actually changes
OPC DA was born in the 1990s, built on Microsoft's COM/DCOM. For years it has been the de facto standard for connecting SCADA, historians and supervisory systems to PLCs and field gateways. It works, it is ubiquitous, and it is still present in the vast majority of existing plants.
The limitations of OPC DA are well known:
- dependency on Windows and DCOM, with all that implies for configuration, dynamic ports, authentication and troubleshooting;
- no native security mechanism: protection depends entirely on DCOM settings and Windows policies;
- difficulty traversing firewalls and segmented networks, because DCOM uses dynamic ports and callbacks;
- no support for non-Windows platforms;
- flat data model with no hierarchical structure or semantic metadata.
OPC UA was designed to address these issues. It is platform-independent, does not rely on DCOM, has a rich hierarchical data model, and integrates security at the protocol level. Transport can run over binary TCP (opc.tcp) or HTTPS, using fixed, configurable ports, which simplifies firewall management.
On paper that looks like a clear step forward. And in many respects it is. But the transition is never linear, and the coexistence of OPC DA and OPC UA is the normal condition on almost every plant that was not designed from scratch in the last few years.
Client/server model: the foundation
The fundamental communication model of OPC UA is client/server. An OPC UA server exposes an address space, a tree structure of nodes representing variables, objects, methods, types and relationships. The client connects, browses the address space, reads and writes variables, and subscribes to changes through subscriptions and monitored items.
In practice, on a plant this means the PLC (or gateway) acts as the server, while SCADA, historian or MES systems act as clients. The connection is point-to-point, the client always initiates communication, and the server responds or pushes subscribed changes.
Compared to OPC DA, the OPC UA client/server model has concrete operational advantages:
- the listening port is fixed and configurable (default 4840/tcp), making firewall rules predictable;
- the connection is always initiated by the client, with no server-to-client callbacks as happened with DCOM;
- the protocol natively handles sessions, timeouts and keep-alive, so connection stability is more controllable;
- the structured address space allows exposing data with context, engineering units, ranges and relationships, not just raw values.
The downside is that an OPC UA server is heavier to run than an OPC DA server. On PLCs with limited resources, the impact on CPU and memory is not negligible, especially if the number of connected clients grows or the address space is very large.
Pub/Sub: a different communication model
Beyond client/server, the OPC UA specification includes a Publish/Subscribe (Pub/Sub) model, defined in Part 14 of the specification. The concept is different: the publisher sends data over a network transport (UDP multicast, MQTT, AMQP) without maintaining a direct connection to each subscriber. Subscribers receive messages based on the group or topic they have subscribed to.
The implications are significant:
- one-to-many communication without multiplying point-to-point connections;
- lightweight transports such as UDP for low-latency applications;
- natural integration with MQTT brokers, useful for architectures where OT data needs to reach cloud or edge platforms;
- decoupling between data producers and consumers.
In practice, Pub/Sub support in field devices is still limited. Many PLCs and gateways that claim OPC UA compatibility only support the client/server model. Pub/Sub requires more recent stacks, and implementation on embedded devices is not straightforward. Additionally, Pub/Sub over UDP multicast has significant network implications: it requires IGMP configuration on switches, can generate broadcast traffic if misconfigured, and security is handled differently compared to client/server.
Anyone evaluating OPC UA Pub/Sub for a plant should verify case by case what the device firmware actually supports, and not assume that "OPC UA" automatically means "Pub/Sub available".
Security model: certificates, endpoints and policies
One of the most cited strengths of OPC UA is the security model integrated into the protocol. Unlike OPC DA, where security was delegated to DCOM and the operating system, OPC UA defines three levels of protection directly in the specification:
Each OPC UA server exposes one or more endpoints, each with a combination of security mode (None, Sign, SignAndEncrypt) and security policy (which determines the cryptographic algorithms). On connection, the client selects an endpoint and establishes a SecureChannel. If the server requires certificates, the client must present its own, and the server must have the client's certificate in its trust list.
On paper it is a solid model. In practice, certificate management is where most implementations struggle.
Real-world certificate challenges
An X.509 certificate has an expiry date. When it expires, the OPC UA connection drops. If nobody planned the renewal, the result is a communication outage that can have operational impact.
On a plant with dozens of OPC UA servers (PLCs, gateways, edge devices) and just as many clients (SCADA, historian, MES), managing the certificate lifecycle becomes a non-trivial task. The questions to ask are practical:
- who generates the certificates? Self-signed or from an internal CA?
- where are private keys stored?
- who handles renewal before expiry?
- how are renewed certificates distributed to all peers?
- what happens when a device is replaced and the new one has a different certificate?
Many plants take the simplest route: disable security, set the endpoint to "None" and auto-accept self-signed certificates. This works, but it completely negates the security advantage of OPC UA over OPC DA. At that point, the protocol carries data in clear text without application authentication, exactly like DCOM did, just with a fixed port.
Anyone who wants to use OPC UA with security enabled must plan a sustainable certificate management process. Some SCADA platforms and PLC vendors offer tools to simplify distribution and renewal, but this is not a universal feature, and in many cases it remains a manual activity.
Firewall and network segmentation implications
One of the most concrete advantages of OPC UA over OPC DA is predictable firewall rules. With OPC DA on DCOM, ports were dynamic (range 1024-65535 or custom configurations), callbacks required bidirectional openings, and troubleshooting was often frustrating.
OPC UA uses a fixed port (default 4840/tcp for opc.tcp, 443 for HTTPS). The connection is always initiated by the client towards the server. There are no callbacks. This means firewall rules can be precise and unidirectional: open the server port, allow traffic from the client, and that is it.
For anyone designing or managing industrial networks segmented according to IEC 62443 or Purdue models, this is a real improvement. It allows placing OPC UA servers in the field zone or industrial DMZ with clear rules, without opening wide port ranges or allowing uncontrolled return traffic.
Watch out for real-world cases
The simplification holds for the client/server model. With Pub/Sub over UDP multicast, the rules change: multicast traffic must be managed at the switch and routing level, and the firewall must allow multicast flows towards subscribers. If MQTT is used as transport, there is an added dependency on a broker, which becomes a critical component to place, protect and keep available.
Another aspect not to overlook: if the firewall allows OPC UA on port 4840, it allows all OPC UA traffic, including read, write, method call and address space browse. The network firewall does not inspect OPC UA protocol content. For more granular control, an industrial application-layer firewall (OPC UA DPI) is needed, or a restrictive server-side configuration that limits accessible nodes, write permissions and callable methods for each client or user.
In other words: the fixed port simplifies the firewall, but does not eliminate the need to configure permissions correctly at the application level.
Coexistence with OPC DA: the most common scenario
Most existing plants do not migrate from OPC DA to OPC UA in one go. Coexistence is the norm, and it can last years.
The reasons vary:
- older PLCs and controllers do not support OPC UA, or only support it with firmware updates that require validation;
- the SCADA in use may not have a mature OPC UA client, or may have one only in the most recent versions;
- maintenance contracts and plant procedures are built around the existing architecture;
- maintenance staff know OPC DA and DCOM, not necessarily OPC UA and certificate management;
- the risk of stopping production for a protocol migration is hard to justify without immediate operational benefit.
The most common solution is an OPC DA-to-UA wrapper or gateway: a software component that exposes OPC DA server data as an OPC UA server. Commercial products and open-source libraries exist for this purpose. The wrapper adds an intermediate layer, with its dependencies, latency and failure points, but it allows integrating legacy systems into an OPC UA architecture without touching existing PLCs or SCADA servers.
When using a wrapper, keep in mind that:
- the wrapper typically runs on Windows (because it needs to access the OPC DA server via COM/DCOM);
- it adds a communication hop and a component to monitor;
- OPC UA security on the wrapper does not protect the OPC DA segment underneath;
- address space mapping is not always automatic and may require manual configuration.
Real adoption limits
OPC UA is a mature, well-documented standard supported by a broad base of vendors. But adoption on existing plants has limits worth acknowledging plainly.
Hardware resources
An OPC UA server requires more resources than an OPC DA server. On entry-level PLCs or embedded controllers with limited RAM and CPU, enabling OPC UA can reduce the performance margin available for the control programme. Some vendors limit the number of simultaneous OPC UA sessions for exactly this reason. Before enabling OPC UA on a PLC in production, it is worth checking the actual performance impact, not just the datasheet.
Configuration complexity
Properly configuring an OPC UA endpoint with security enabled is not the same as setting up an OPC DA tag. It requires certificates, trust lists, security policies, per-node or per-user permissions. Many PLC engineering tools have simplified interfaces, but full configuration demands specific expertise. If maintenance personnel are not trained, the risk is that security gets disabled to make the problem go away.
Real-world interoperability
The OPC UA standard defines Compliance Profiles specifying which features a product must support. But not all products support the same profiles, and not all implementations are equivalent. Interoperability issues between clients and servers from different vendors exist, especially for advanced features like Pub/Sub, Historical Access or Alarms & Conditions. The OPC Foundation runs a certification programme, but coverage levels vary.
Ongoing maintenance
Expiring certificates, firmware updates to fix OPC UA stack bugs, trust lists to synchronise, configurations to realign after hardware replacement: maintaining an OPC UA infrastructure with security enabled is a recurring activity that must be planned. On plants where maintenance is already stretched, adding a more complex protocol without dedicated resources risks making things worse rather than better.
OPC UA and IEC 62443: a link not to overstate
OPC UA is often described as "aligned" with IEC 62443. The link exists, in the sense that the OPC UA security model (authentication, encryption, certificate management) provides mechanisms consistent with IEC 62443 requirements for secure communication between components. But OPC UA alone does not make a plant IEC 62443 compliant, and IEC 62443 does not mandate OPC UA as a protocol.
The distinction matters: using OPC UA with security enabled is a good practice that contributes to the plant's security posture. But IEC 62443 compliance involves zones, conduits, system requirements, risk management, lifecycle processes and much more. The communication protocol is just one piece.
When OPC UA adoption makes sense
Not every plant needs to migrate to OPC UA tomorrow. There are contexts where adoption makes immediate sense, and others where waiting is reasonable.
The decision should be driven by real needs: interoperability, security, maintainability, regulatory requirements or integration demands. Not by the notion that "OPC UA is the future and must be adopted". Migration has a cost, a risk and requires skills. If there is no clear operational benefit, it is legitimate to plan it for the medium term rather than force it.
Final considerations
OPC UA is a well-designed protocol, with a solid security model and a much richer data structure than OPC DA. For new plants or cross-platform integration projects, it is the natural choice. But it is not a silver bullet: security only works if certificates are managed, permissions are configured, and staff know what they are doing.
On existing plants, the transition requires planning, resources and an honest assessment of complexity. OPC DA/UA coexistence is normal and manageable, provided the wrapper is not treated as a permanent solution and security is not disabled for convenience.
As with any infrastructure decision in OT, the point is not to adopt the latest technology, but to adopt the right one in the right way, with the resources to maintain it over time.
Evaluating OPC UA adoption on an existing plant or a new line?
We can help you define architecture, security, firewall rules and migration path taking into account the real constraints of your plant.