August 11, 2026 · How-To

OPC UA Security: Certificates, Encryption, and Auth Setup

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.

Frequently Asked Questions

What are the OPC UA security modes?

OPC UA defines three security modes per endpoint. None — no security, plaintext, for trusted isolated networks. Sign — messages are signed (integrity + authentication) but not encrypted. SignAndEncrypt — messages are signed and encrypted (confidentiality + integrity + authentication). For any network that is not fully isolated, SignAndEncrypt is the correct choice.

Does OPC UA use certificates?

Yes. OPC UA authenticates with X.509 certificates. Both client and server present a certificate during the SecureChannel handshake, and each side decides whether to trust the other based on its trust list. This mutual certificate-based authentication is what replaces the username/password or DCOM identity model of classic OPC.

What happens if a client certificate is not trusted?

The server rejects the connection (or accepts it only to immediately push it into a rejected-certificate state, depending on configuration). The administrator must move the client certificate from the server's rejected folder to its trusted folder before the connection succeeds. This manual trust step is intentional — it prevents unknown clients from connecting silently.

Is OPC UA security None ever acceptable?

Only on a fully isolated, trusted network where you control every device and every packet path — for example a local bench test or a physically isolated commissioning LAN. On any shared, routed, or remotely accessible network, use SignAndEncrypt. Security None transmits credentials and data in plaintext and provides no authentication beyond the endpoint URL.

Further Reading

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