"Just turn on TLS" is the advice you hear most often about securing OPC UA. It is half right, and the missing half causes real misconfigurations. The transport that the overwhelming majority of industrial OPC UA deployments use, opc.tcp, does not use TLS at all. It carries its own encryption, built into the protocol. TLS only enters the picture for the HTTP and WebSocket mappings.
So OPC UA does not depend on TLS the way a web API does. It has a security model defined in the specification itself (Part 2 covers the security model, Part 6 covers how it maps onto each transport), and TLS is one of two mechanisms that model can use to encrypt a connection. Getting this distinction right is the difference between an OPC UA channel that is actually confidential and one that only looks like it is.
How OPC UA secures a connection
OPC UA layers security into three independent stages. Each answers a different question, and you can get one right while leaving another wide open.
- Transport. How the bytes physically move:
opc.tcp(binary),opc.https(HTTP), oropc.wss(WebSocket). The choice of transport decides which encryption mechanism is available. - SecureChannel. The cryptographic conversation between a client and server. This is where OPC UA signs and encrypts messages, negotiates keys, and exchanges certificates. The specification calls the protocol that runs here UA-SecureConversation.
- Session. Who is connecting. OPC UA separates application identity (the software endpoints, proven with X.509 certificates) from user identity (the human or service account, proven with anonymous, username/password, or certificate tokens). A device can trust an application and still reject the user behind it.
The important takeaway: encryption happens at the SecureChannel or transport layer, and authentication of the user happens above it. Encrypting a channel does not mean you have authenticated who is on it, and authenticating a user does not mean the channel is encrypted.
The two ways OPC UA gets encrypted
Because the encryption mechanism follows the transport, there are genuinely two different answers to "how is this OPC UA traffic encrypted."
opc.tcp: SecureChannel, not TLS
The binary opc.tcp mapping is the workhorse of industrial OPC UA, and it secures itself with UA-SecureConversation at the message level. When a client connects, the two endpoints exchange X.509 application instance certificates, use those public keys for an asymmetric handshake, then derive symmetric keys to sign and encrypt every subsequent message. The cryptographic primitives are the same family TLS uses (RSA, AES, SHA-2), but they are applied per message inside the OPC UA protocol rather than wrapped around the whole byte stream.
This is why "enable TLS" is the wrong instruction for most OPC UA servers. There is no TLS to enable on opc.tcp. What you actually configure is the security policy and the message security mode, covered below.
opc.https and opc.wss: TLS
When OPC UA runs over the HTTP or WebSocket mappings, it uses TLS for transport security, exactly the way a browser does. TLS secures all the bytes as they are sent, without regard to OPC UA message boundaries. One useful consequence: on the HTTPS mapping, the OPC UA security policy only governs the signing of nonces during the session handshake, because TLS is already providing the confidentiality. The cipher suite TLS negotiates is independent of the OPC UA security policy named on the endpoint.
These mappings show up in cloud-facing and firewall-friendly deployments, where running over 443 and reusing existing TLS tooling is worth the tradeoffs. On the plant floor, opc.tcp still dominates.
opc.tcp | opc.https / opc.wss | |
|---|---|---|
| Encryption mechanism | UA-SecureConversation (message level) | TLS (transport level) |
| Where keys are negotiated | OPC UA SecureChannel handshake | TLS handshake |
| What the security policy controls | Signing and encryption of all messages | Nonce signing during session setup |
| Typical use | Plant floor, device to device | Cloud, firewall traversal |
The knobs that actually matter: security policies and modes
On the SecureChannel, two settings decide what protection you get.
Message security mode is the headline switch, with three values:
- None. No signing, no encryption. Traffic is plaintext, and anyone on the network can read setpoints, capture credentials passed in the session, or inject commands.
- Sign. Every message is signed, so tampering and spoofing are detectable, but the payload is still readable on the wire.
- SignAndEncrypt. Messages are signed and encrypted. This is the only mode that gives you confidentiality.
If your goal is encryption, SignAndEncrypt is the only mode that delivers it. Sign alone protects integrity but leaves process data in the clear.
Security policy names the algorithms used. Current, recommended policies include Aes256_Sha256_RsaPss, Aes128_Sha256_RsaOaep, and Basic256Sha256. Older policies, Basic128Rsa15 and Basic256, are deprecated because the algorithms behind them are no longer considered safe, and many vendors now ship them disabled. Picking a current policy matters as much as picking the right mode: SignAndEncrypt with a broken policy is not the protection it appears to be.
Certificates carry two different identities
Certificates do a lot of work in OPC UA, and it helps to keep two roles separate.
The application instance certificate identifies the software endpoint. During the handshake, client and server exchange these certificates, and each side checks the other against its trust list. A certificate that is not trusted gets rejected, which is what stops a rogue client from opening a channel even when it speaks perfect OPC UA. This is the layer that establishes trustworthiness between applications, and it is also where most operational pain lives: provisioning, distributing, renewing, and revoking these certificates across hundreds of devices is the reason so many sites quietly run with security turned down.
User identity is a separate token presented after the channel is up: anonymous, username and password, or an X.509 user certificate. Encrypting the channel and trusting the application says nothing about which user is on the other end, so user authentication is a deliberate, separate decision.
Where it breaks in the field
The OPC UA security model is strong. Deployments are where it falls down, almost always in the same ways:
- SecurityMode None in production. It is the path of least resistance during commissioning, and it survives into production far more often than anyone admits. The endpoint advertises a "secure" protocol while sending plaintext.
- Deprecated policies left enabled. Legacy clients that only speak
Basic128Rsa15keep weak policies switched on for everyone, and an attacker simply negotiates down to the weakest one on offer. - Certificate management abandoned. When renewal and trust-list maintenance are manual, expired or over-permissive certificates accumulate, and teams disable validation to stop the outages it causes.
- Devices that cannot secure themselves. Plenty of field equipment exposes OPC UA with no usable security at all, or sits behind protocols (Modbus, plain HTTP) that predate the idea of encryption entirely.
The recurring theme is not that the cryptography is weak. It is that turning it on, and keeping it on, costs more operational effort than teams can sustain device by device.
Securing OPC UA assets that cannot secure themselves
This 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 makes it possible to add encryption, enforce access, and see the traffic without touching the device firmware.
For an OPC UA asset, or any plaintext or legacy protocol, that means you can:
- Wrap it in a transparent TLS tunnel. Access Gate runs its own PKI and generates terminal certificates on the fly, so a device that speaks plaintext on the plant floor can be exposed securely across a wider network without per-device certificate work. The Set up TLS encryption guide walks through it end to end, including the supported cipher suites and a "TLS only" access policy.
- Default-deny by identity and protocol. A rule that grants 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 encrypts the channel also gives you visibility into who connected, to what, and over which protocol, which is where compliance frameworks like NIST 800-171, CMMC, and NIS2 ultimately point.
The short version
TLS does have a role in securing OPC UA, but only on the HTTP and WebSocket mappings. The opc.tcp transport that runs most plant floors encrypts itself with UA-SecureConversation, and the settings that actually matter there are the message security mode (use SignAndEncrypt) and a current security policy (Aes256_Sha256_RsaPss or Basic256Sha256, never Basic128Rsa15). Either way, the hard part is not the cryptography, it is operating it consistently across a fleet of devices that were never designed for it. Terminating and re-securing OPC UA at a managed proxy is how you get encryption and access control without rebuilding every endpoint to support it.
