OPC UA is secure by design. Most deployments are not.
The protocol has signing, encryption, certificate-based application identity and named user authentication built in. Every one of them is optional, and the defaults ship open. This guide covers what the security model actually does, which settings change what, and how to protect servers that cannot be reconfigured.
Last updated:
What is OPC UA security, and why is it usually off?
OPC UA security is a three-layer model built into the protocol: a transport, a SecureChannel that signs and encrypts every message, and a Session that carries user identity. All three layers are optional, and most products ship with SecurityPolicy None, MessageSecurityMode None and anonymous access enabled for first-boot convenience. Almost every OPC UA weakness found in the field is a configuration gap rather than a protocol flaw, which is also what makes it fixable.
OPC UA is the protocol that ties an industrial estate together: PLCs, drives, sensors, SCADA and historians that were never designed to talk to each other. Unlike Modbus, it was built with security in mind from the start, and the model is genuinely good. The catch is that it is layered and optional. A server can advertise strong encryption and still accept an anonymous, unencrypted session on the same port, because that is how most products ship for first-boot convenience.
Why are most OPC UA servers left insecure?
Four defaults account for the majority of what an assessment finds on a plant floor. None of them is a vulnerability in the specification. All of them are the state a server is in when commissioning finished and nobody came back.
SecurityMode None on production endpoints
A server left at SecurityPolicy None with MessageSecurityMode None accepts plaintext sessions from anyone who can reach TCP 4840. They can browse the address space, read live process values and very often write setpoints. The OPC Foundation intends None for discovery and testing, not for carrying real data. If you audit one thing this quarter, audit for this. With SecurityPolicy None there is no key to encrypt the identity token with either, so a UserName login sends the password across the wire as UTF-8 cleartext (OPC UA Part 4, 7.40).
Anonymous user access left enabled
Application-level and user-level authentication are separate. A channel can be cryptographically sound, with valid certificates on both ends, and still admit an anonymous session on top of it. Encrypting the pipe tells you nothing about who is at the other end of it.
Untrusted certificates auto-accepted
Auto-accepting certificates is convenient during commissioning and is frequently never turned back off. The flag is AutoAcceptUntrustedCertificates in the OPC Foundation stack, often labelled trust-on-first-use in vendor UIs, though it is weaker than that name suggests: it trusts every certificate, every time, not just the first one it sees. A server in that state has no application authentication at all, whatever the security mode says.
Deprecated policies kept for compatibility
Basic128Rsa15 and Basic256 rely on SHA-1 and weak RSA padding, and the OPC Foundation has moved them out of the recommended set. They are usually left advertised so an old client keeps working, and then old clients keep selecting them.
What can an attacker do with an open OPC UA server?
OPC UA is rich by design: a client can discover the entire address space, subscribe to live values and call methods. That richness is exactly what makes an unauthenticated endpoint valuable to an attacker.
Address space reconnaissance
The browse service is designed to be self-describing. An unauthenticated client can enumerate every node, its data type, and often the human-readable name of the process it controls, producing a map of the plant without sending a single malicious packet.
Unauthorized writes to setpoints
Where the server exposes writable nodes and no user identity is required, the same session that reads a value can change it. Nothing in the protocol distinguishes an engineer from anyone else who reached the port.
Silent downgrade to plaintext
Some clients fall back to SecurityMode None when a secure handshake fails rather than refusing the connection. An attacker who can break the handshake gets plaintext, and the operator sees a working connection.
Interception on a flat network
Over opc.tcp with Sign only, payloads travel readable on the wire. Process values, tag names and the shape of the process are visible to anything on the same segment. Passwords are the exception: the specification requires the server to encrypt the user identity token separately whenever the channel is not SignAndEncrypt, so the cleartext-password failure belongs to SecurityPolicy None rather than to Sign.
How does the OPC UA security model work?
OPC UA security is not a switch. The specification describes three cooperating layers, and knowing which one a given setting belongs to is most of the battle.
- 01
Transport
The connection that moves bytes. For the common opc.tcp binding this is a raw TCP socket. For the opc.https and opc.wss bindings it is TLS.
- 02
Communication: the SecureChannel
Where confidentiality and integrity are established, independently of the transport. Over opc.tcp this is UA-SecureConversation: it negotiates keys, signs messages and optionally encrypts them.
- 03
Application: the Session
Runs on top of a SecureChannel and carries user authentication and authorization. A Session can be re-associated with a new channel if the connection drops.
What is the difference between None, Sign and SignAndEncrypt?
When a client opens a SecureChannel it picks one of three modes. They map directly onto the protection the traffic gets.
| Mode | Integrity | Confidentiality | Where it belongs |
|---|---|---|---|
| None | None. Nothing detects tampering. | None. Plaintext on the wire. | Discovery and testing only. No place on a production endpoint. |
| Sign | Every message signed. Tampering is detectable. | None. Payload readable on the wire. | Narrow: where integrity matters and confidentiality genuinely does not. |
| SignAndEncrypt | Every message signed. | Full. Payload encrypted. | The default for production. Anything carrying setpoints, process values or credentials. |
Which OPC UA SecurityPolicy should you use?
A SecurityPolicy is the named set of algorithms a SecureChannel uses once Sign or SignAndEncrypt is selected. Picking a policy is picking your crypto strength.
| Policy | Algorithms | Status |
|---|---|---|
| Aes256_Sha256_RsaPss | AES-256, SHA-256, RSA-PSS signatures | Current recommendation. Prefer it wherever both ends support it. |
| Aes128_Sha256_RsaOaep | AES-128, SHA-256, RSA-OAEP | Current, lighter. Acceptable where AES-128 meets the requirement. |
| Basic256Sha256 | AES-256, SHA-256, RSA PKCS#1 v1.5 signatures | Widely deployed and still acceptable. A reasonable choice when the newer policies are not available on both sides. |
| Basic256 | AES-256, SHA-1, RSA-OAEP | Deprecated by the OPC Foundation. The padding is sound, but SHA-1 is no longer acceptable. Treat its presence as a finding. |
| Basic128Rsa15 | AES-128, SHA-1, RSA PKCS#1 v1.5 encryption | Deprecated by the OPC Foundation. Weak padding and a broken hash. Treat its presence as a finding. |
A practical audit step
Every OPC UA server advertises its supported endpoints through the discovery service. Enumerate them, confirm the server offers a strong policy with SignAndEncrypt, and confirm the deprecated policies are either disabled or not the ones clients actually select. An endpoint list is the fastest honest answer to "is this thing secured".
What are the OPC UA authentication methods?
OPC UA authenticates on two distinct levels, and conflating them is a common source of false confidence. One asks whether the software at the other end is known. The other asks who is using it.
Application authentication
Happens at the SecureChannel level and answers "is this client application and this server application who they claim to be?" Each application holds an X.509 application instance certificate, and the two sides exchange and validate certificates when the channel opens. Trust is managed through a certificate trust list: you decide which certificates, or which issuing CA, you accept. This is what stops an unknown application from establishing a 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 identity token types: Anonymous, which has no place in production, UserName with password, and X.509 user certificates. A channel can be cryptographically sound at the application level while still admitting an anonymous user on top.
A properly secured endpoint does both: it validates the peer application's certificate against a managed trust list, and it requires a named user identity. Issuing, distributing, trusting and rotating those certificates is the operational work that makes it real, and it is the part most teams underinvest in.
Where does OPC UA security break in the field?
Most OPC UA incidents trace back to configuration rather than protocol flaws. These five account for the bulk of what an assessment turns up.
SecurityMode None in production
The dominant issue by a wide margin, and the one to check first.
Auto-accepting untrusted certificates
AutoAcceptUntrustedCertificates left permanently on, which defeats application authentication entirely.
Anonymous user access alongside an encrypted channel
The channel is sound, the session is wide open, and dashboards report the endpoint as secured.
Deprecated policies still advertised
Kept available for backward compatibility, then selected by exactly the old clients you were worried about.
Silent plaintext fallback
A client that downgrades to None when the secure handshake fails, rather than refusing the connection outright.
How do you manage OPC UA certificates without a Global Discovery Server?
OPC UA application authentication depends on certificates, and the specification's answer at scale is a Global Discovery Server (GDS, OPC UA Part 12). Plenty of OT estates never stand one up: it is another server to run, patch and back up inside the process network, and a small estate rarely justifies it. The layers still work, only the distribution changes.
Issue from a local authority
An on-premise CA, or self-signed instance certificates where the estate is small enough to enumerate. What matters is that a human decided which certificates are trusted, not that a public CA vouched for them.
Populate trust lists deliberately
Each application keeps its own trust list. Filling it during commissioning, and then turning AutoAcceptUntrustedCertificates off, is what converts certificates from decoration into authentication.
Plan rotation before expiry
Certificates expire, and in an air-gapped estate nothing renews them automatically. An expiry that nobody tracked becomes an outage on a Sunday. Record issue and expiry dates in the same runbook that holds the rest of the network's state.
Or move the problem off the endpoints
Where per-device certificate work is not realistic, terminating the session at a protocol-aware proxy lets one component hold the PKI instead of every device holding part of it.
OPC UA hardening checklist: what to verify
OPC UA security comes down to a short, checkable list. Most of it is verification rather than construction. All of it assumes one thing: that you are allowed to change the endpoint. Where you are not, the next section covers the other way to close the same gaps.
- 01
Confirm no production endpoint is running MessageSecurityMode None.
- 02
Require SignAndEncrypt for anything carrying process data, setpoints or credentials.
- 03
Select a current SecurityPolicy, preferably Aes256_Sha256_RsaPss, and retire Basic128Rsa15 and Basic256.
- 04
Validate application instance certificates against a managed trust list, and turn AutoAcceptUntrustedCertificates off once commissioning is done.
- 05
Require a named user identity. Disable anonymous access.
- 06
Confirm clients refuse to downgrade rather than falling back to plaintext.
- 07
Remember that over opc.tcp your protection is the SecureChannel, while opc.https and opc.wss ride on TLS. Check the binding before you reason about what a proxy or capture can see.
These controls map onto IEC 62443 identification and authentication (FR1) and use control (FR2), NIST SP 800-82r3 for OT systems, and the access-control measures NIS2 Article 21 requires of essential and important entities.
Does OPC UA use TLS?
Over opc.tcp, the security protecting your data is the SecureChannel, not TLS. A connection that looks encrypted is not necessarily using TLS at all, because UA-SecureConversation does its own signing and encryption. TLS only enters the picture with the opc.https and opc.wss bindings. This matters the moment you reason about what a firewall, a packet capture or a TLS-terminating proxy can and cannot see.
How do you secure an OPC UA server you cannot reconfigure?
The checklist assumes you can change the endpoint. Often you cannot: the vendor forbids it, the change window does not exist, or the server predates the parts of the specification you want to enforce. The alternative is to put the protection in front of the device, at the network layer, so the unsecured endpoint is never directly reachable.
Wrap it in a transparent tunnel
Access Gate runs its own PKI and issues terminal certificates on the fly. The channel to the Gate is TLS 1.3 with post-quantum key exchange (ML-KEM-768), verified against that PKI, in front of a server that speaks none of it, and with no per-device certificate work.
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, which is the enforcement the server's own anonymous session cannot provide.
Keep the server off the flat network
The endpoint sits inside a segmented enclave and keeps its own IP. Nothing on the device changes, and nothing reaches TCP 4840 without passing policy first.
Record who connected to what
The same proxy that gates the channel logs the session: which identity, which asset, which protocol. That is the access-control evidence IEC 62443, NIST SP 800-82r3, NIS2 and CMMC ultimately ask for.
Bring an OPC UA server under control without touching it
If your estate has servers that cannot be reconfigured, or certificate work that is not realistic per device, we can walk through what gating the channel looks like on your network.
Configure OPC UA access
The step-by-step guide: bring an unsecured server inside an enclave, then secure the channel with TLS, message security, or a gated tunnel.
See it on your own estate
A walkthrough against your topology: which endpoints are exposed, what enforcement looks like, and what it takes to deploy.
OPC UA security questions
The default OPC UA TCP port. An endpoint listening here with SecurityMode None is readable, and often writable, by anything that can route to it.
Only on some bindings. The opc.https and opc.wss bindings ride on TLS. The common opc.tcp binding does not: it uses UA-SecureConversation, the protocol's own signing and encryption at the SecureChannel layer. A connection can be fully encrypted without any TLS involved, which matters when you are reasoning about what a TLS-terminating proxy or a packet capture can see.
No. The security model is strong but every layer of it is optional, and most products ship with SecurityPolicy None, MessageSecurityMode None and anonymous access enabled for first-boot convenience. A server is secure only if someone configured it that way after commissioning.
Sign gives you integrity: every message is signed, so tampering is detectable, but the payload is still readable on the wire. SignAndEncrypt adds confidentiality, so the payload is encrypted as well. For production OT traffic SignAndEncrypt should be the default; Sign only has a narrow place where confidentiality genuinely does not matter.
Aes256_Sha256_RsaPss where both ends support it, and Basic256Sha256 as an acceptable fallback. Basic128Rsa15 and Basic256 are deprecated: they rely on SHA-1 and weak RSA padding, and the OPC Foundation has moved them out of the recommended set. If a server still advertises them, treat it as a finding rather than a setting to preserve.
Put the protection in front of it. Bring the server inside a segmented enclave so it is not directly reachable, and terminate the session at a protocol-aware proxy that applies identity and policy before re-establishing the connection to the asset. The device keeps its IP, its firmware and its configuration, and the encryption, access control and logging happen at the chokepoint instead of on the endpoint.
