August 11, 2026 · How-To

OPC UA Security: Certificates, Encryption, and Auth Setup

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated October 28, 2026.

Unlike classic OPC, which inherited DCOM's fragile security, OPC UA was designed with security in the protocol. Every UA server publishes one or more endpoints, each advertising a security mode and policy. Clients and servers authenticate each other with X.509 certificates. The first secure connection you make always involves a trust handshake, and that is the step that trips people up. This guide walks through the model and the setup so the trust dance stops being a mystery.

For the wider protocol, see OPC UA vs OPC DA; for what you do after the secure channel is up, browsing a server.

Security Modes

Each UA endpoint advertises one of three security modes:

• None: no signing, no encryption. Plaintext. Acceptable only on a fully isolated, trusted network.
• Sign: every message is signed. Integrity and source authentication, but the payload is still readable.
• SignAndEncrypt: messages are signed and encrypted. Integrity, authentication, and confidentiality.

Security Policies

A security policy is the cryptographic suite behind a mode: the asymmetric algorithm for the handshake (RSA or ECC), the symmetric algorithm for the session (AES), the key length, and the hash (SHA-256). Modern deployments use Basic256Sha256 or Aes128_Sha256_RsaOaep. Older policies like None (the policy, not the mode) or Basic128Rsa15 are deprecated and should be disabled where possible.

Certificates and Mutual Authentication

UA authenticates with X.509 certificates, not passwords. When a client opens a SecureChannel:

1. The client and server exchange certificates.
2. Each side validates the other's certificate chain and checks it against its trust list.
3. If both trust each other, the channel is established and a session is created.
4. Optional user authentication (username/password, another certificate, or a token) gates access to the address space on top of the channel-level identity.

The Trust List Dance

The first time a client connects, the server does not yet trust the client's certificate. Typical behavior: the server accepts the connection attempt, places the unknown client certificate in a rejected certificates folder, and closes. The administrator moves that certificate into the server's trusted folder, and the next connection succeeds. The client does the symmetric thing with the server's certificate. This manual step is intentional: it prevents unknown clients from silently connecting.

Certificate lifecycle matters: certificates expire. A connection that worked for a year suddenly fails the day a client or server certificate lapses. Track expiry dates and rotate before they pass.

Setting Up a Secure Connection

1. Pick an endpoint advertising SignAndEncrypt with a modern policy (Basic256Sha256).
2. Generate (or obtain) an X.509 certificate for the client.
3. Connect once so the server sees and rejects the unknown client certificate.
4. Move the client certificate from the server's rejected folder to its trust list; move the server certificate into the client's trust list.
5. Reconnect: the SecureChannel establishes, then authenticate as a user if the server requires it.

Doing It on macOS

MacTools OPC UA Explorer presents the endpoint list with each one's security mode and policy, manages the client certificate, and walks you through the trust handshake. You can connect over SignAndEncrypt, browse, and subscribe from macOS with the same security posture as any production client. No Windows, no DCOM.

Further Reading

• OPC UA vs OPC Classic (DA)
• How to Browse an OPC UA Server
• OPC UA Subscriptions and Monitored Items