OPC UA Security: Certificates, Authentication, and Encryption Explained

Introduction

OPC UA was designed from the ground up with security in mind — a stark contrast to older industrial protocols like Modbus and OPC Classic (DCOM), which have no built-in security at all. But having security capabilities and actually using them correctly are two different things. Many OPC UA deployments in the field run with security disabled because the configuration was too confusing or too time-consuming during commissioning.

This guide explains the OPC UA security model in practical terms and walks through the key configuration decisions you need to make.

The OPC UA Security Model: Three Layers

OPC UA security operates at three distinct layers:

1. Transport Security (Secure Channel)

This is the encryption and signing of data as it moves between an OPC UA client (your SCADA system) and an OPC UA server (your PLC or gateway). It is conceptually similar to TLS/HTTPS for web traffic, but uses OPC UA's own protocol layer.

The secure channel provides:

• Confidentiality — Data is encrypted so it cannot be read if intercepted.
• Integrity — Data is signed so tampering is detected.
• Application authentication — Both the client and server verify each other's identity using X.509 certificates.

2. User Authentication

After the secure channel is established, the user (or application acting on behalf of a user) must authenticate. OPC UA supports several authentication methods:

• Anonymous — No authentication required. Appropriate only for read-only public data.
• Username/Password — The most common method. The password is protected by the secure channel encryption.
• X.509 Certificate — The user presents a certificate instead of a password. Used for machine-to-machine authentication.
• Kerberos/OAuth2 — Supported in newer OPC UA specifications for enterprise SSO integration.

3. Authorization (Access Control)

After authentication, the server determines what the authenticated user can do. OPC UA defines role-based access control where different users or certificates can have different read, write, and browse permissions on different nodes in the address space.

Understanding Security Policies

An OPC UA security policy defines the cryptographic algorithms used for signing and encryption. When a client connects to a server, they negotiate which policy to use. Common policies include:

• None — No security. Data is transmitted in clear text with no authentication. This should only be used for discovery or on completely isolated networks.
• Basic256Sha256 — The current recommended policy. Uses SHA-256 for hashing, AES-256-CBC for encryption, and RSA with OAEP padding for key exchange.
• Aes128-Sha256-RsaOaep — A newer alternative that uses AES-128 for symmetric encryption. Slightly lower computational overhead with security that is still considered strong.
• Aes256-Sha256-RsaPss — The most recent and strongest policy, using RSA-PSS signatures.

Deprecated policies to avoid:

• Basic128Rsa15 — Uses weak RSA PKCS#1 v1.5 padding, vulnerable to padding oracle attacks.
• Basic256 — Uses SHA-1, which is cryptographically broken.

If your server still offers these deprecated policies, disable them.

Security Modes

In addition to the security policy, OPC UA defines a security mode for the connection:

• None — No security applied (regardless of policy).
• Sign — Messages are signed but not encrypted. This ensures integrity (tampering is detected) but data is visible if intercepted. Appropriate when confidentiality is not a concern but integrity is.
• SignAndEncrypt — Messages are both signed and encrypted. This is the recommended mode for most deployments.

The combination of security policy and security mode defines the actual security applied. For example, "Basic256Sha256 + SignAndEncrypt" provides full encryption and integrity with current-generation algorithms.

Certificate Management in Practice

X.509 certificates are central to OPC UA security. Every OPC UA application (client and server) should have its own certificate. Here is how certificate management works in practice:

Self-Signed vs CA-Signed Certificates

Self-signed certificates are generated by the application itself. They are the simplest option: the OPC UA client or server generates a certificate on first startup. The downside is that trust must be established manually — you must explicitly copy the client's certificate to the server's trusted certificates folder and vice versa.

CA-signed certificates are issued by a Certificate Authority (either a public CA or your own private CA). Any application that trusts the CA automatically trusts all certificates issued by that CA. This scales much better for large deployments — you add the CA certificate to each application's trust store once, and any new application with a CA-signed certificate is automatically trusted.

Recommendation: For small deployments (fewer than 10 OPC UA connections), self-signed certificates are practical. For larger deployments, invest in setting up a private CA.

The Trust Handshake

When an OPC UA client first connects to a server:

1. The client presents its certificate to the server.
2. The server checks if the client's certificate (or its issuing CA) is in the server's trusted certificates store.
3. If not trusted, the server rejects the connection. Many servers move the untrusted certificate to a "rejected" folder.
4. An administrator reviews the rejected certificate and, if it belongs to a legitimate client, moves it to the trusted folder.
5. The client does the same for the server's certificate.

This manual trust establishment is the step that trips up most people during commissioning. The common mistake is disabling security entirely to avoid the certificate exchange process.

Certificate Storage

OPC UA applications typically store certificates in a folder structure:

own/ - The application's own certificate and private key

trusted/ - Certificates of trusted peers and CAs

rejected/ - Certificates that were presented but not yet trusted

issuers/ - CA certificates used to validate certificate chains

The exact folder locations depend on the OPC UA implementation. Always protect the private key file with filesystem permissions — only the application should be able to read it.

Certificate Expiration and Renewal

OPC UA certificates have expiration dates. When a certificate expires, connections using it will fail. Plan for renewal:

• Set calendar reminders for certificate expiration dates.
• For self-signed certificates, generate new ones before expiration and update the trust stores.
• For CA-signed certificates, request renewal from your CA well before expiration.
• Some OPC UA implementations support the GDS (Global Discovery Service) Push model, which can automate certificate renewal.

User Authentication Best Practices

Username/Password

• Use unique credentials per SCADA client, not shared accounts.
• Enforce strong passwords (minimum 12 characters, mixed case, numbers, symbols).
• Change default credentials immediately. Many OPC UA servers ship with default usernames and passwords.
• Use account lockout after failed login attempts to prevent brute-force attacks.
• Passwords are only protected in transit if the secure channel is active. Never use username/password authentication with SecurityMode=None.

Certificate-Based User Authentication

For machine-to-machine communication (SCADA server to PLC, historian to data source), certificate-based authentication is more secure than passwords:

• No password to be intercepted, guessed, or forgotten.
• Certificates can be bound to specific machines.
• Revocation is cleaner — revoke the certificate rather than changing a shared password.

Practical Configuration Checklist

Here is a step-by-step checklist for securing an OPC UA connection:

1. On the server: Enable SecurityPolicy Basic256Sha256 (or newer). Disable deprecated policies and SecurityPolicy None.
2. On the server: Set SecurityMode to SignAndEncrypt.
3. On the server: Generate or install the server's application certificate. Note the certificate's location.
4. On the client (SCADA): Generate or install the client's application certificate.
5. Exchange trust: Copy the client's certificate to the server's trusted folder. Copy the server's certificate to the client's trusted folder.
6. Configure user authentication: Create user accounts on the server with appropriate roles. Disable anonymous access unless explicitly needed.
7. On the client: Configure the username/password or client certificate for user authentication.
8. Test the connection: Connect and verify that data flows. Check the server's audit log for any security warnings.
9. Document the configuration: Record which certificates are deployed where, their expiration dates, and the security policies in use.

Common Mistakes

• Disabling security "to get it working" — The most common and most dangerous mistake. Once disabled during commissioning, security often never gets re-enabled.
• Using the same certificate for every application — Each client and server should have its own unique certificate. Sharing certificates defeats the purpose of application authentication.
• Ignoring certificate expiration — Connections silently fail when certificates expire, and the root cause is not always immediately obvious.
• Running OPC UA on the corporate network without segmentation — OPC UA servers should be on an isolated industrial network (VLAN), accessible from the corporate network only through a firewall or DMZ.
• Not auditing OPC UA access — Enable audit logging on your OPC UA servers. Know who connected, when, and what they did.

OptiZeus and OPC UA Security

OptiZeus implements the OPC UA client stack with full support for certificate-based security. During connection setup, you select the security policy and mode, provide the client certificate, and configure user authentication. The system manages the certificate trust store through the UI — when a server presents an untrusted certificate, you can review and accept it without manually copying files between folders. Certificate expiration monitoring alerts you before certificates expire so you can renew them proactively.

Conclusion

OPC UA's security model is comprehensive and well-designed, but it requires deliberate configuration. The three layers — transport security (secure channel with certificates), user authentication, and authorization — each need attention. Start with Basic256Sha256 SignAndEncrypt, exchange application certificates, configure user accounts with least-privilege access, and monitor certificate expiration. The initial setup takes more time than connecting with security disabled, but the alternative — an unencrypted, unauthenticated channel to your industrial control system — is not acceptable in any facility that takes security seriously.