OPC UA Security: The Complete Guide for Industrial Cybersecurity Teams

1. Why OPC UA security matters now

Industrial cybersecurity has moved from a specialist concern to a boardroom priority. The numbers are stark: ransomware attacks on manufacturing increased by over 60% between 2022 and 2024. Critical infrastructure incidents – power grids, water systems, oil and gas pipelines – make headlines with increasing frequency. Regulators in Europe, North America, and the Middle East are responding with mandatory security requirements that carry financial penalties for non-compliance.

In this environment, the communication protocol connecting your PLCs, SCADA systems, historians, and cloud platforms is a critical security decision not just a technical one.

OPC UA was designed for this world. When the OPC Foundation began developing OPC UA in the early 2000s, they made a deliberate decision: security would be part of the specification, not an optional add-on. Every connection, every data exchange, every session in an OPC UA deployment operates within a security framework that is embedded in the protocol itself.

This guide explains that framework in detail and shows why matters for industrial organizations navigating an increasingly complex regulatory and threat landscape.

2. The security problems OPC UA was designed to solve

To understand OPC UA security, we need to go back to what it was designed to replace.

OPC Classic:  the original OPC standard, introduced in 1996, was built on Microsoft’s COM/DCOM (Component Object Model / Distributed Component Object Model) technology. DCOM was a reasonable choice in 1996. It was not a reasonable choice by 2005, and it is a significant security liability today.

The DCOM security problems that OPC Classic inherits include:

• Dynamic port allocation. DCOM assigns ports dynamically from a large range (typically 49152–65535), making it nearly impossible to configure firewalls precisely. Industrial security best practice requires locking down port access tightly. DCOM makes this impractical, which is why many OT environments run with overly permissive firewall rules – a well-documented attack vector.
• Windows attack surface. OPC Classic depends entirely on Windows security mechanisms, including NTLM and Kerberos authentication. Vulnerabilities in these mechanisms, of which there have been many over the decades, directly affect OPC Classic security.

The Windows security mechanisms have made DCOM complex to configure and users ended up allowing everything to make communications work.

• No message-level security. OPC Classic has no built-in mechanism for encrypting or signing individual messages. Security is enforced at the transport level (Windows RPC), but once inside the network, data travels in the clear. An attacker who gains network access can read or potentially inject process data.
• Limited access control. OPC Classic access control is based on Windows user accounts and group permissions. Fine-grained, role-based control of which applications can read or write which data points are not natively supported.
• No cross-platform identity. OPC Classic does not support and consequently cannot authenticate non-Windows systems. As OT environments increasingly include Linux-based edge devices, embedded controllers, and cloud services, this is a fundamental gap.

OPC UA addresses every one of these limitations, not by patching DCOM, but by replacing it entirely with a purpose-built security architecture.

3. Architecture: the three layers

OPC UA implements security at three distinct layers, each building on the one below it.

Layer 1: Transport security (channel security)

The first layer establishes a secure channel between a client and server before any application data is exchanged. The connection itself is encrypted and authenticated before any data flows.

OPC UA defines three security modes for a channel:

The security mode is negotiated during session establishment and applies to all subsequent communication on that channel.

Layer 2: Session security (application authentication)

Once a secure channel is established, OPC UA authenticates the application identity not just the network connection. This is where X.509 certificates come into play (described in detail in Section 5).

Each OPC UA application – whether a client or a server – holds a cryptographic certificate. Before a session is established, the client and server exchange certificates and verify them against their respective trust lists. If either party’s certificate is not trusted, the connection is refused.

This mutual authentication means that even if an attacker gains network access, they cannot connect to an OPC UA server without a certificate that the server trusts – a fundamentally stronger model than network-level access control alone.

Layer 3: User authentication and authorization

After the application session is established, OPC UA authenticates the user or service making requests. OPC UA supports multiple user authentication mechanisms:

• Anonymous: no user identity (appropriate only for public read-only data in isolated networks)
• Username / password: transmitted encrypted over the secure channel
• X.509 user certificate: the highest-assurance method, where the user identity is cryptographically bound to a certificate

Once the user identity is established, authorization (what the user is allowed to do) is enforced through role-based access control.

4. OPC UA encryption in depth

OPC UA encryption is based on well-established cryptographic standards. The specification defines security policies that bundle together specific cryptographic algorithms:

For new deployments in 2026: Use Aes256_Sha256_RsaPss or Aes128_Sha256_RsaOaep. Avoid Basic128Rsa15 and Basic256 – they use deprecated RSA 1024 key lengths that no longer meet NIST or BSI recommendations.

Certificate key lengths: OPC UA certificates use RSA keys. Minimum recommended key length is 2048 bits; 4096-bit keys provide additional margin against future cryptographic advances and are recommended for long-lifetime certificates (5+ years).

Message signing in OPC UA works independently of channel encryption. Even in Sign-only mode (no encryption), every message carries a cryptographic signature that allows the recipient to detect any modification in transit. This protects against man-in-the-middle attacks that might inject false process values.

5. OPC UA authentication and certificates

The OPC UA X.509 certificate model is one of the most important – and most misunderstood – aspects of the protocol’s security architecture.

What is an OPC UA application certificate?

Every OPC UA application instance (a specific server or client installation) should have a unique application instance certificate – an X.509 digital certificate that cryptographically identifies that application. The certificate contains:

• The application’s URI (a unique identifier, e.g., urn:mycompany:opcuaserver:plantA)
• The certificate holder’s public key
• The certificate validity period (start and end dates)
• The issuing authority’s signature (either self-signed or issued by a Certificate Authority)
• Subject Alternative Names (SANs) – typically the hostnames and IP addresses the server is reachable at

The trust model

OPC UA uses a trust list model – each application maintains a list of certificates (or Certificate Authority certificates) that it considers trusted. When two applications connect:

1. Each presents its certificate to the other
2. Each checks whether the other’s certificate is in its trust list (or signed by a trusted CA)
3. If both trust each other → session proceeds
4. If either does not trust the other → connection refused

This model means that certificate management is a real operational responsibility in OPC UA deployments. Certificates expire. New devices are deployed. Certificates need to be revoked when a device is decommissioned or compromised.

Self-signed vs CA-issued certificates

• Self-signed certificates are generated by the application itself. They are easy to set up for development and testing but require each trusting application to explicitly add the certificate to its trust list. In large deployments with many OPC UA applications, this quickly becomes unmanageable.
• CA-issued certificates are signed by a Certificate Authority – either an enterprise PKI or the OPC Foundation’s recommended Global Discovery Server (GDS). Applications that trust the CA automatically trust any certificate the CA issues. This scales far better for enterprise deployments.
• Recommendation: Use CA-issued certificates in all production deployments. Implement a GDS for deployments with more than a handful of OPC UA applications.

6. Role-based access control (RBAC) in OPC UA

OPC UA’s access control model allows administrators to define precisely what each authenticated user or application is permitted to do within the OPC UA server’s address space.

Access control in OPC UA operates at the node level – individual data points, folders, objects, or methods can have independent access rules. This granularity enables configurations like:

• Operators can read all process values but can only write setpoints for their assigned equipment
• Maintenance engineers can invoke diagnostic methods but cannot modify configuration parameters
• Cloud analytics services can read historical data but have no write access
• MES applications can read and write production order data but cannot access safety system data

OPC UA 1.04 and later formalizes RBAC through the role model: a set of well-defined roles (Observer, Operator, Engineer, Supervisor, ConfigureAdmin, SecurityAdmin) with defined permission sets. Server implementations can map their access control to these standard roles, or define custom roles.

Why RBAC matters for compliance

IEC 62443, the leading industrial cybersecurity standard, requires that systems implement least privilege – every application and user should have the access necessary to only perform their function, and no more. OPC UA’s node-level RBAC directly supports this requirement. Without it, a compromised HMI or historian would have unlimited read/write access to the entire OPC UA address space and consequently to read/write access to the target OT system.

7. OPC UA and regulatory compliance

OPC UA’s security architecture aligns with the major industrial cybersecurity and regulatory frameworks. Here is how the mapping works in practice.

IEC 62443 (industrial cybersecurity globally applicable)

IEC 62443 is the international standard for industrial automation and control system (IACS) cybersecurity. It defines security levels (SL1–SL4) for zones and conduits in industrial networks.

OPC UA’s contribution to IEC 62443 compliance:

FR: Foundational Requirement

OPC UA does not by itself achieve a specific IEC 62443 security level that depends on the overall system architecture and implementation. But it provides the cryptographic and access control primitives that make SL2 and SL3 achievable.

NIS2 Directive (European Union effective 2024)

The Network and Information Security 2 (NIS2) Directive applies to operators of essential services across the EU, including energy, manufacturing, water, transport, and healthcare. It requires these operators to implement appropriate technical and organizational measures to manage cybersecurity risks.

For OT environments, OPC UA supports NIS2 compliance in the following areas:

• Risk management measures (Article 21): OPC UA’s encrypted communications and certificate-based authentication reduce the risk of unauthorized access and data interception
• Incident handling: OPC UA’s audit logging supports the incident detection and reporting requirements
• Access control policies: OPC UA RBAC supports the access control requirements of NIS2 for critical systems

For EU-based industrial operators: The combination of migrating from OPC Classic (DCOM) to OPC UA, implementing certificate-based authentication, and enabling RBAC represents a substantial reduction in cybersecurity risk and a meaningful step toward NIS2 compliance.

NERC CIP (North American energy sector)

NERC CIP (Critical Infrastructure Protection) standards apply to bulk electric system operators in North America. Key standards relevant to OPC UA:

• CIP-005 (Electronic Security Perimeters): OPC UA’s single-port, firewall-friendly design makes it significantly easier to define and enforce Electronic Security Perimeters compared to DCOM’s dynamic port requirements
• CIP-007 (Systems Security Management): OPC UA’s authentication mechanisms support the access control requirements of CIP-007; audit logging supports the monitoring requirements
• CIP-010 (Configuration Change Management): OPC UA’s explicit trust model means unauthorized applications cannot connect to production systems even if they gain network access

FDA 21 CFR Part 11 and EU Annex 11 (pharmaceuticals)

Pharmaceutical manufacturers operating under FDA 21 CFR Part 11 or EU Annex 11 must ensure that electronic records and electronic signatures are trustworthy, reliable, and compliant.

OPC UA’s contribution:

• Audit trails: OPC UA servers can generate audit events for all significant operations -reads, writes, session establishment, access control decisions – creating the audit trail required by both regulations
• User authentication: OPC UA’s user authentication mechanisms support the individual accountability requirements of 21 CFR Part 11
• Data integrity: Message signing ensures that critical data recorded from OPC UA sources has not been tampered with in transit

8. OPC UA Global Discovery Server: certificate management at scale

As noted in Section 5, certificate management is the primary operational challenge of OPC UA security. In a plant with dozens or hundreds of OPC UA applications, manually and individually managing certificate trust lists across all of them is impractical, and manual processes inevitably lead to expired certificates, inconsistent trust stores, and connectivity failures at the worst possible moments.

The OPC UA Global Discovery Server (GDS) is the OPC Foundation’s solution to this problem. A GDS is a central service that can:

• Act as the Certificate Authority (CA) for all OPC UA applications in a deployment
• Issue application instance certificates to new OPC UA clients and servers
• Manage the distribution of trust lists ensuring all applications have up-to-date lists of trusted certificates
• Support certificate renewal before expiry automatically or with minimal operator intervention
• Handle certificate revocation immediately removing trust from a compromised or decommissioned application

With a GDS in place, adding a new OPC UA device to the network becomes a managed, auditable process: the device requests a certificate from the GDS, an administrator approves the request, the GDS issues the certificate, and the device is trusted by all other applications in the deployment automatically.

GDS deployment considerations

A GDS is a critical infrastructure component. It should be:

• Highly available: consider redundant GDS instances for large deployments
• Secured: the GDS has privileged access to the PKI; it should be hardened, access-controlled, and monitored
• Integrated with enterprise PKI: where an enterprise PKI already exists, the OPC UA GDS should be integrated as a subordinate CA rather than operating as an independent root CA
• Backed up: the GDS certificate database and CA private key must be backed up securely and regularly

9. OPC UA security in practice: common mistakes and how to avoid them

Even with a strong protocol, security depends on correct implementation and configuration. These are the most common OPC UA security mistakes seen in industrial deployments.

Using Security Mode: None in production. Security mode None is appropriate for isolated test environments and development. It should not be used in production, even on networks that are assumed to be isolated. Network isolation is not a reliable long-term security control.

Accepting all certificates automatically. Many OPC UA implementations offer an option to automatically accept any certificate presented by a connecting application. This bypasses the entire trust model and should not be enabled in production. Every new certificate should require explicit approval.

Not renewing certificates before expiry. X.509 certificates have validity periods. An expired certificate will cause connection failures often at inconvenient times. Certificate expiry monitoring and automated renewal (via GDS or SCEP) should be standard practice.

Using deprecated security policies. Basic128Rsa15 and Basic256 use RSA 1024 keys, which are no longer considered secure. Any new OPC UA deployment should use Basic256Sha256 as the minimum, or the newer Aes128_Sha256_RsaOaep / Aes256_Sha256_RsaPss policies.

Not implementing RBAC. Running all OPC UA applications with administrator-level access creates an unnecessarily large blast radius in the event of a compromise. Implementing role-based access from the outset is the recommended cyber security practice.

Sharing application certificates across instances. Each OPC UA application instance should have its own unique certificate. Sharing a certificate between multiple instances means that revoking the certificate (e.g., because one instance is compromised) disrupts all instances.

Ignoring audit logs. OPC UA generates rich audit events. Not collecting and monitoring these events means that security incidents- including unauthorized connection attempts and unexpected writes to process values – go undetected.

10. Migrating from OPC Classic to OPC UA: the security case

The security argument for migrating from OPC Classic to OPC UA is straightforward: OPC Classic has no credible path to the security posture required by modern industrial cybersecurity standards. Without OPC tunneling products, DCOM cannot be made to support X.509 certificate authentication, AES encryption, or fine-grained RBAC.   DCOM simply does not support it.

This does not mean a disruptive, overnight replacement is necessary. The practical migration path for most organizations is:

Phase 1: Immediate risk reduction: Deploy an to stop DCOM at the wrapper boundary. OPC Classic servers continue to operate unchanged; the wrapper presents an OPC UA interface to new clients, and all new client connections use OPC UA security. DCOM traffic is now contained within a controlled perimeter rather than traversing the network broadly.

Phase 2: Progressive modernization: As OPC Classic servers reach end-of-life or undergo scheduled maintenance, replace them with native OPC UA servers. The wrapper handles the transition period, allowing old and new clients to coexist.

Phase 3: OPC Classic retirement: Once all clients and servers are native OPC UA, the wrapper layer can be removed. The full security benefits of OPC UA – mutual certificate authentication, encrypted communications, RBAC are now in effect end-to-end.

Integration Objects’ OPC UA Wrapper is designed support exactly this migration path. It bridges existing OPC Classic servers (DA, HDA, and AE) to the OPC UA world, so new clients connect via production-grade OPC UA security while legacy infrastructure continues operating unchanged.

Frequently asked questions

 Related resources

• What is OPC UA? Complete guide: Foundational overview of the OPC UA standard
• Migrating from OPC Classic to OPC UA seamlessly: Practical migration guidance
• From Vulnerability to Security: Addressing Legacy Protocol Risks with OPC UA Wrapper: Security-focused migration case
• OPC UA Wrapper product page: Solution for OPC Classic environments
• Coming soon: OPC UA and IEC 62443 – implementation guide
• Coming soon: OPC UA and NIS2 – compliance roadmap for EU operators
• Coming soon: OPC UA certificate management with GDS – step-by-step guide