OPC UA Security: Certificates, Policies, and the Settings People Get Wrong

A commissioning engineer sets SecurityPolicy to None to get a new line talking to the historian before a shift-change deadline. The plan is to lock it down the following week. Three years later, that server is still sitting on the network at SecurityPolicy None, and nobody remembers it was ever meant to be temporary.

That story isn't rare. Internet-wide scans of publicly reachable OPC UA servers found 92 percent configured deficiently, and roughly a quarter support only the plaintext None policy (NotebookLM, OPC UA Security notebook, 2026). What is OPC UA covers the protocol's information model and why security ships built into the spec rather than bolted on. This piece is about the part that goes wrong anyway: the certificates, the policies, and the settings that quietly turn a secure-by-design protocol into an open door.

TL;DR: OPC UA's certificate and encryption model is sound by design, but deployment is where it fails. Internet-wide scans found 92% of reachable OPC UA servers configured deficiently, with 24-26% running plaintext only and 44-51% allowing anonymous access (NotebookLM, OPC UA Security notebook, 2026). The fix is a short, specific checklist: remove SHA-1 policies, disable None, require SignAndEncrypt, and stop trusting self-signed certificates by hand.

What Is the Two-Layer Trust Model in OPC UA?

OPC UA authenticates applications and users separately, and that separation is the design decision everything else builds on. Application authentication happens first, at the Secure Channel, using X.509 certificates that identify the software instance rather than the person using it (NotebookLM, OPC UA Security notebook, 2026).

User authentication happens second, inside an active session, when the client passes a UserIdentityToken during ActivateSession. Encrypting the channel says nothing about who is on it, and authenticating the user says nothing about whether the channel is encrypted. Both checks have to pass, and they run at different points in the handshake (NotebookLM, OPC UA Security notebook, 2026).

That decoupling has a practical payoff. Because application trust and user identity live on separate layers, one Secure Channel can host multiple concurrent user sessions, each with its own role-based permissions. A read-only operator and a read-write engineer can share the same encrypted tunnel without opening two separate cryptographic connections (NotebookLM, OPC UA Security notebook, 2026).

OPC UA defines four ways to establish that second layer: Anonymous, Username/Password, X.509 User Certificate, and Issued Tokens delegated to an enterprise identity provider like Active Directory (NotebookLM, OPC UA Security notebook, 2026). Anonymous should be disabled in production or locked to a zero-privilege, read-only role. It rarely is, which is the subject of a later section.

Citation capsule: OPC UA runs a strict two-layer authentication model: application identity via X.509 certificates at the Secure Channel, then user identity via a UserIdentityToken during session activation. The two checks are independent, so encrypting a channel never proves who is using it, and authenticating a user never proves the channel itself is protected (NotebookLM, OPC UA Security notebook, 2026).

How Does Certificate Exchange Actually Work?

Every OPC UA application, client or server, carries a unique X.509 Application Instance Certificate that identifies the software instance, not the hardware host or the human operator (NotebookLM, OPC UA Security notebook, 2026). Before either side sends a single value, both present that certificate and check it against a local trust store. Neither side connects to an application it does not trust.

The certificate itself carries specific metadata: the owning organization, the application's logical name, a validity window, and a mandatory Application URI. The Subject Alternative Name extension must also list the URI and the hostnames or IP addresses where the application actually runs, and a mismatch there fails the handshake (NotebookLM, OPC UA Security notebook, 2026).

Validation follows a fixed sequence defined in OPC 10000-4, Table 100: structure and signature, chain of trust back to a root CA, security policy compliance, validity period, hostname and URI match, and revocation status against a CRL. Any critical failure halts session negotiation and generates an audit event (NotebookLM, OPC UA Security notebook, 2026).

Trust itself lives in three directories on every application. The Trusted Certificate List holds explicitly approved application certificates or trusted CA root keys. The Issuer Certificate List holds intermediate CAs needed to build a chain back to that root. The Rejected, or Quarantine, directory automatically catches any untrusted certificate a connecting peer presents, so an administrator can review a failed attempt and manually promote a legitimate one into the trusted list (NotebookLM, OPC UA Security notebook, 2026).

Self-signed certificates work for a handful of devices. An administrator copies each application's public key into every peer's trust list by hand. That model collapses at scale: a CA-based approach lets every device trust one root key, so adding a server means issuing one certificate rather than touching every existing client (NotebookLM, OPC UA Security notebook, 2026). Large industrial deployments solve this with a Global Discovery Server, a centralized certificate authority discussed later in this piece.

Citation capsule: OPC UA's Secure Channel handshake requires both sides to exchange X.509 Application Instance Certificates and validate them against three local stores, the Trusted Certificate List, the Issuer Certificate List, and a Rejected directory that automatically captures untrusted connection attempts for administrator review (NotebookLM, OPC UA Security notebook, 2026).

What Do Security Policies and Message Modes Actually Buy You?

A security policy sets the cipher suite, the specific asymmetric, symmetric, and key-derivation algorithms used to sign and encrypt a session. A message security mode sets how far those ciphers get applied: not at all, signed only, or signed and encrypted (NotebookLM, OPC UA Security notebook, 2026). The two settings work together, and both matter.

Two older policies, Basic128Rsa15 and Basic256, are deprecated because they depend on SHA-1, a hash algorithm vulnerable to collision attacks. Leaving either enabled invites a downgrade attack, where an attacker forces the handshake to negotiate down to the weakest algorithm the server still offers (NotebookLM, OPC UA Security notebook, 2026). Basic128Rsa15 is also the exact policy behind a demonstrated Bleichenbacher padding-oracle attack, CVE-2024-42512, shown at DEF CON 33: send enough malformed requests, measure the timing of the server's error responses, and recover the private key (NotebookLM, OPC UA Security notebook, 2026).

Basic256Sha256 is the recommended production minimum. It uses AES-256 for symmetric encryption, HMAC-SHA-256 for signatures, and RSA-OAEP with 2048 to 4096-bit keys for the asymmetric handshake (NotebookLM, OPC UA Security notebook, 2026). Aes128_Sha256_RsaOaep offers a lighter, 128-bit symmetric option, with one caveat: it still uses RSA-OAEP with SHA-1 padding for the asymmetric leg, an engineering compromise dating to older .NET frameworks that lacked native SHA-256 OAEP support. The OPC Foundation judged this acceptable because no known exploit targets SHA-1 when it's constrained to OAEP padding specifically (NotebookLM, OPC UA Security notebook, 2026).

The strongest current option, Aes256_Sha256_RsaPss, drops that compromise entirely by using RSA's Probabilistic Signature Scheme with strictly SHA-256 pipelines end to end (NotebookLM, OPC UA Security notebook, 2026).

Message security mode decides what those ciphers actually protect. None sends every message unsigned and unencrypted, and it belongs only in offline development or isolated diagnostics. Sign appends a digital signature but leaves the payload readable, useful when an intrusion detection system needs to inspect traffic. SignAndEncrypt signs and encrypts everything, and it's the only mode that delivers confidentiality (NotebookLM, OPC UA Security notebook, 2026).

Citation capsule: Basic128Rsa15 and Basic256 are deprecated for relying on SHA-1; Basic256Sha256 is the recommended production baseline; Aes256_Sha256_RsaPss is the strongest current policy, since it avoids the legacy SHA-1 OAEP padding workaround still present in Aes128_Sha256_RsaOaep (NotebookLM, OPC UA Security notebook, 2026).

One transport wrinkle worth knowing: opc.tcp has no TLS to enable, since its message-level security comes from the policy and mode above. Over HTTPS or WebSockets, TLS handles wire-level confidentiality instead, and the OPC UA policy shrinks to signing session nonces during CreateSession. WebSockets using the binary sub-protocol can still layer full OPC UA message security on top of TLS, which matters if traffic crosses an untrusted proxy that terminates the outer TLS tunnel (NotebookLM, OPC UA Security notebook, 2026).

How Do You Manage Certificates Over a 15-Year Plant Lifespan?

A control system commissioned this year will likely still run in 2041. Certificates issued at commissioning have to survive that entire span, get renewed without downtime, and stay revocable if a private key ever leaks. That's a fleet management problem, not a one-time setup task.

Two clocks run at once. Symmetric SecurityTokens, negotiated after the initial handshake, rotate automatically: the client requests a new token once 75 percent of the current one's lifetime has elapsed, so the session never drops (NotebookLM, OPC UA Security notebook, 2026). The long-lived X.509 Application Instance Certificate follows a slower clock, checked against its validFrom and validTo window on every new Secure Channel.

An expired certificate returns Bad_CertificateTimeInvalid and halts the connection. Facing that outage risk, teams under deadline pressure sometimes issue certificates with 99-year lifetimes or disable validation checks outright, which defeats the entire trust model to avoid a maintenance window (NotebookLM, OPC UA Security notebook, 2026).

The Global Discovery Server exists to remove that pressure. It acts as a centralized certificate manager across the fleet, running one of two workflows. In Pull Management, each device tracks its own expiration and periodically requests a renewed certificate from the GDS. In Push Management, the GDS tracks every device's expiration and initiates renewal itself, updating the trust list first, then pushing a new signed certificate, then instructing the device to apply the change (NotebookLM, OPC UA Security notebook, 2026).

Push Management includes a rollback safeguard worth knowing about specifically: if the GDS cannot reconnect to the device after the update, the device automatically reverts to its previous, still-valid certificate rather than stranding itself offline (NotebookLM, OPC UA Security notebook, 2026). The GDS also refuses to push a stronger certificate over a weaker channel; a 4096-bit certificate never gets delivered across a connection negotiated at 2048 bits (NotebookLM, OPC UA Security notebook, 2026).

What Misconfigurations Actually Show Up in Audits?

Attackers rarely break OPC UA's cryptography. They walk through security that was left switched off. Internet-wide scans found 92 percent of publicly reachable deployments configured deficiently, and the failures cluster around three habits (NotebookLM, OPC UA Security notebook, 2026).

The first is leaving SecurityPolicy None enabled. It's the fastest way to get a connection working during commissioning, and it survives into production far more often than anyone admits. Roughly 24 to 26 percent of scanned servers support only the None policy, and over 80 percent support plaintext as a fallback even when stronger policies exist, which opens the door to a downgrade attack (NotebookLM, OPC UA Security notebook, 2026).

The second is anonymous user access, which removes the second authentication layer entirely. Between 44 and 51 percent of exposed servers permit unauthenticated sessions. Of those, 90 percent allow the anonymous user to read live process data, and 61 percent allow that same user to write values or execute system functions outright (NotebookLM, OPC UA Security notebook, 2026).

The third is broken certificate validation. A CISPA study tested 48 OPC UA products and found 38 with broken certificate handling, commonly a server configured to accept any incoming certificate regardless of trust chain, which erases mutual authentication and opens the door to man-in-the-middle attacks (NotebookLM, OPC UA Security notebook, 2026). Researchers separately found the same self-signed certificate, private key included, deployed on 385 hosts across 24 different autonomous systems from one manufacturer, a scale of key reuse that turns one leaked private key into a fleet-wide compromise (NotebookLM, OPC UA Security notebook, 2026).

Implementation bugs compound the configuration problem. Because many vendors build on the same handful of reference stacks, a single flaw can cascade across an entire supply chain. Documented cases include a chunk-flooding denial-of-service that withholds the final message fragment to exhaust server memory (CVE-2022-25302, CVE-2022-29864), an unrate-limited ConditionRefresh call that floods alarm state and crashes the server (CVE-2023-27321), and a malformed UTF-8 string that triggers heap corruption in PTC KepServerEx (CVE-2022-2825) (NotebookLM, OPC UA Security notebook, 2026). Claroty's Team82 has disclosed more than two dozen OPC UA vulnerabilities since 2020, and its exploit framework has surfaced close to fifty across clients, servers, and gateways (NotebookLM, OPC UA Security notebook, 2026).

Formal verification research adds a sharper finding: eight new vulnerabilities exist even in a perfectly configured OPC UA deployment. Researchers using the ProVerif protocol verifier found a race condition where switching a session from a low-privilege to a high-privilege user can let an in-flight request execute under the wrong user's permissions, and a signature oracle where a server that skips certificate validation can be tricked into signing attacker-chosen data (NotebookLM, OPC UA Security notebook, 2026). Both have been acknowledged by the OPC Foundation, with fixes already folded into later spec revisions.

Citation capsule: Internet-wide scans found 92 percent of publicly reachable OPC UA deployments configured deficiently: 24 to 26 percent run plaintext-only, 44 to 51 percent allow anonymous access, and a CISPA study found 38 of 48 tested products had broken certificate validation, most commonly an "accept any certificate" default (NotebookLM, OPC UA Security notebook, 2026).

What Belongs on an OPC UA Hardening Checklist?

Start with the policies. Remove Basic128Rsa15 and Basic256 from every endpoint's configuration entirely, not just disable them, since a disabled-but-present policy is still a downgrade target. Configure Basic256Sha256 with SignAndEncrypt as the floor, and move toward Aes256_Sha256_RsaPss on new deployments (NotebookLM, OPC UA Security notebook, 2026).

Disable the None security mode on every production endpoint, or bind it strictly to localhost-only diagnostics that never touch the network. Disable anonymous user access, or if a read-only diagnostic account genuinely needs it, map it to a role with zero write and zero execute permissions (NotebookLM, OPC UA Security notebook, 2026).

Move from self-signed certificates to a company-issued CA, and stop accepting certificates automatically. Every incoming certificate should enter the trusted store through explicit administrator approval, sourced from the Rejected directory rather than a blanket accept-all setting (NotebookLM, OPC UA Security notebook, 2026).

Track certificate expiration as an operational metric with an owner, the same way you'd track a calibration due date. Deploy a Global Discovery Server once the device count makes manual trust-list updates impractical, and use Push Management for infrastructure like PLCs where a central security team should control renewal timing (NotebookLM, OPC UA Security notebook, 2026).

Map the deployment against IEC 62443 zones and conduits. An OPC UA Secure Channel already functions as a cryptographic conduit between zones, enforcing a boundary between, say, a Level 2 supervisory network and a Level 3 operations system without extra hardware firewalls at every endpoint (NotebookLM, OPC UA Security notebook, 2026). Where the network topology allows it, use the Reverse Connection profile so a server behind a firewall initiates the outbound connection, keeping inbound ports closed.

Finally, patch the stack, not just the configuration. A downgrade attack fails against a server that never offered a weak policy in the first place, but a heap-corruption bug in the underlying SDK bypasses configuration entirely. Track CVEs against whichever reference stack your vendor's product is built on, since one flaw there can affect every product built on it (NotebookLM, OPC UA Security notebook, 2026).

Frequently Asked Questions

What is the recommended OPC UA security policy?

Basic256Sha256 with SignAndEncrypt is the recommended minimum baseline for production. Aes256_Sha256_RsaPss is stronger still, since it drops the legacy SHA-1 padding workaround entirely (NotebookLM, OPC UA Security notebook, 2026).

Why is SecurityPolicy None still enabled on so many OPC UA servers?

It is the path of least resistance during commissioning, and it survives into production because nobody removes it after go-live. Roughly 24 to 26 percent of internet-reachable servers support only the None policy (NotebookLM, OPC UA Security notebook, 2026).

Does encrypting the OPC UA channel mean the user is authenticated?

No. Channel encryption and user authentication are two separate, decoupled layers. A server can trust the connecting application and still reject the session if the operator has no valid UserIdentityToken (NotebookLM, OPC UA Security notebook, 2026).

How does a Global Discovery Server help with certificate management?

A GDS acts as a centralized certificate authority, automating certificate issuance, renewal, and trust list distribution across a fleet through pull or push management, so nobody manually swaps public keys between hundreds of devices (NotebookLM, OPC UA Security notebook, 2026).

Is OPC UA aligned with IEC 62443?

Yes. OPC UA secure channels function as cryptographic conduits between IEC 62443 zones, and its certificate, encryption, and audit features map directly onto the standard's seven Foundational Requirements (NotebookLM, OPC UA Security notebook, 2026).

Conclusion

OPC UA's security model works when the settings behind it get used. Certificates authenticate applications, a separate UserIdentityToken authenticates operators, and Basic256Sha256 with SignAndEncrypt covers confidentiality and integrity end to end. None of that stops a server sitting at SecurityPolicy None or accepting anonymous logins from being exactly as exposed as a plant with no security spec at all.

The audit findings say where to look first: the policy list, the anonymous access setting, and whatever's actually sitting in the trusted certificate store. Fix those three, put certificate expiration on a fleet-wide dashboard, and map the deployment against IEC 62443 zones and conduits. For the protocol's information model and where it sits next to MQTT, see what OPC UA is and OPC UA vs MQTT. For the broker layer these security decisions eventually feed into, Unified Namespace and PROFINET vs EtherNet/IP cover the adjacent layers of the stack.