OPC UA Security: What Every OT Engineer Should Know

Why OPC UA security deserves a closer look

As an operational technology (OT) engineer, you already know how much rides on industrial systems. OPC UA (Open Platform Communications Unified Architecture) is now a standard protocol that ties those systems together, connecting PLCs, sensors, drives, SCADA, and historians that were never designed to interact. The good news is that OPC UA was built with security in mind from the start. The bad news is that the model is layered and optional, which means most field deployments enable only part of it, or none of it at all. Knowing exactly what the protocol offers, and which knobs change what, is the difference between a hardened endpoint and an open door.

This primer walks through the OPC UA security model the way the specification actually structures it, then points at the mistakes that show up most often in the field.

The layered security model

OPC UA security is not a single feature you switch on. The OPC Foundation Part 2 Security Model describes it as three cooperating layers, each solving a different problem:

1. Transport layer. This is the underlying connection that moves bytes between client and server. For the common opc.tcp binding, the transport is a raw TCP socket. For the HTTPS and WebSocket bindings (opc.https, opc.wss), the transport is TLS.
2. Communication layer (the SecureChannel). This is where OPC UA establishes confidentiality and integrity for the conversation, independent of the transport. Over opc.tcp, this layer is provided by UA-SecureConversation, defined in OPC Foundation Part 6 Mappings. It negotiates keys, signs messages, and optionally encrypts them.
3. Application layer (the Session). A Session runs on top of a SecureChannel and is where user authentication and authorization live. A single SecureChannel can carry one Session, and Sessions can be re-associated with a new channel if the underlying connection drops.

The key thing to internalize: over opc.tcp, the security that protects your data is the SecureChannel, not TLS. People often assume that because a connection "looks encrypted" it must be using TLS, but opc.tcp does its own signing and encryption through UA-SecureConversation. TLS only enters the picture when you use the opc.https or opc.wss bindings. This distinction matters when you are reasoning about what a firewall, a packet capture, or a TLS-terminating proxy can and cannot see.

MessageSecurityMode: None, Sign, SignAndEncrypt

When a client opens a SecureChannel, it picks a MessageSecurityMode. There are three values, and they map directly to the protection your traffic actually gets:

• None. No signing, no encryption. Messages travel in plaintext and nothing verifies they were not altered in flight. This is the equivalent of running the protocol with the doors off.
• Sign. Every message is signed, so the receiver can detect tampering and confirm the message came from the holder of the negotiated key. The payload is still readable on the wire, but it cannot be silently modified.
• SignAndEncrypt. Messages are both signed and encrypted. This gives you integrity and confidentiality together, and it is the mode you want for anything carrying setpoints, process values, or credentials.

For production OT traffic, SignAndEncrypt should be the default. Sign-only has a narrow place when confidentiality genuinely does not matter but integrity does. None has essentially no place in production, which brings us to the most common failure in the field.

The SecurityMode None trap

The single most frequent OPC UA security problem is not an exotic exploit. It is servers left at SecurityPolicy=None with MessageSecurityMode=None and anonymous user access, exactly the way many products ship by default for first-boot convenience. In that state, anyone who can reach the TCP port (commonly 4840) can browse the address space, read live process values, and often write setpoints, with no authentication and no encryption.

This is not a theoretical risk. It is how a large share of internet-exposed and flat-network OPC UA servers actually run, because the secure modes were never enabled after commissioning. The OPC Foundation's own guidance in "Exploring OPC UA Security Concepts" is explicit that None is intended for discovery and testing, not for carrying real data. If you audit only one thing this quarter, audit for SecurityMode None on production endpoints.

SecurityPolicies: which crypto suite is in use

A SecurityPolicy is the named set of cryptographic algorithms, the hash, the symmetric and asymmetric ciphers, the signature and key-derivation algorithms, that a SecureChannel uses once Sign or SignAndEncrypt is selected. Picking a policy is picking your crypto strength. The ones you will encounter:

• Aes256_Sha256_RsaPss. The current recommended policy. It uses AES-256, SHA-256, and RSA-PSS signatures. Prefer this where both ends support it.
• Basic256Sha256. Widely deployed and still considered acceptable. AES-256 with SHA-256 and RSA-PKCS#1 v1.5 signatures. A reasonable choice when the newer policy is not available on both sides.
• Basic128Rsa15 and the older Basic256. These are deprecated. They rely on SHA-1 and weak RSA padding, and the OPC Foundation has moved them out of the recommended set. Treat their presence as a finding to remediate, not a configuration to keep.

A practical audit step: enumerate the endpoints a server advertises (every OPC UA server exposes its supported endpoints through the discovery service) and confirm it offers a strong policy with SignAndEncrypt, and that the deprecated policies are either disabled or not the ones clients actually select.

Application authentication vs user authentication

OPC UA authenticates on two distinct levels, and conflating them is a common source of false confidence.

• Application authentication happens at the SecureChannel level and answers "is this client application and this server application who they claim to be?" It is based on application instance certificates: each application holds an X.509 certificate, and the two sides exchange and validate certificates when the channel is established. Trust is managed through a certificate trust list on each side, you decide which certificates (or which issuing CA) you accept. This is what stops an unknown application from establishing a secure channel at all.
• User authentication happens at the Session level and answers "which human or service is on the other end?" OPC UA supports several user identity token types: Anonymous (no user identity, avoid in production), UserName/Password, and X.509 user certificates. A SecureChannel can be cryptographically sound at the application level while still admitting an anonymous user at the session level, so both layers need attention.

The takeaway: a properly secured OPC UA endpoint validates the peer application's certificate against a managed trust list, and requires a named user identity rather than anonymous access. Certificate management, issuing, distributing, trusting, and rotating application and user certificates, is the operational work that makes this real, and it is also the part most teams underinvest in.

Where the real-world pitfalls cluster

Most OPC UA incidents in the field trace back to configuration, not protocol flaws:

• SecurityMode None in production, as described above, the dominant issue.
• Auto-accepting untrusted certificates. Some deployments configure the server to trust any certificate it sees ("trust on first use" left permanently on), which defeats application authentication entirely.
• Anonymous user access left enabled alongside an otherwise encrypted channel.
• Deprecated SecurityPolicies kept available for backward compatibility and then selected by old clients.
• Plaintext fallback where a client silently downgrades to None when the secure handshake fails, rather than refusing the connection.

These are exactly the kinds of weaknesses that broader OT security guidance such as NIST SP 800-82, Guide to Operational Technology Security, tells you to find and close: enforce authentication, protect data in transit, and segment the network so an unsecured endpoint is not directly reachable from everywhere.

What to do about it

You generally have two complementary paths. The first is to configure OPC UA security correctly on the endpoints themselves: select a strong SecurityPolicy, require SignAndEncrypt, validate application certificates against a real trust list, and require named user authentication. The second, for legacy servers and clients you cannot reconfigure, is to put the protection in front of the device at the network layer, bringing the server inside a segmented enclave and securing the channel through a gated tunnel so the unsecured endpoint is never directly exposed.

Securing OPC UA endpoints that cannot secure themselves

That second path is the gap Trout Access Gate is built to close. Instead of provisioning and maintaining certificates on every endpoint, Access Gate terminates the session at a protocol-aware proxy, applies identity and policy, and re-establishes the connection to the asset. That single chokepoint is what lets you add encryption, enforce access, and see the traffic without touching device firmware.

For an OPC UA server, or any plaintext or legacy protocol, that means you can:

• Wrap it in a transparent TLS tunnel. Access Gate runs its own PKI and issues terminal certificates on the fly, so a device that speaks plaintext on the plant floor can be reached securely across a wider network without per-device certificate work. The Set up TLS encryption guide covers it end to end, and The role of TLS in securing OPC UA explains where TLS does and does not apply to OPC UA.
• Default-deny by identity and protocol. Granting a user OPC UA access to one asset grants nothing else; every protocol on every asset is an explicit allow. See Protocol configuration use cases.
• Segment and observe. The same proxy that gates the channel records who connected, to what, and over which protocol, the evidence that frameworks like NIST 800-171, CMMC, and NIS2 ultimately ask for. This is the core of OT network security.

Conclusion

OPC UA security comes down to a short, checkable list. Confirm production endpoints are not running SecurityMode None. Require SignAndEncrypt with a current SecurityPolicy such as Aes256_Sha256_RsaPss, and retire deprecated policies like Basic128Rsa15. Validate application instance certificates against a managed trust list, and require named user authentication instead of anonymous access. Remember that over opc.tcp your protection is the SecureChannel, while opc.https and opc.wss ride on TLS. Almost every OPC UA weakness you will find in the field is a configuration gap, not a protocol flaw, which means it is also something you can fix.