OPC UA security modes in practice

In short

OPC UA is one of the most security-conscious industrial protocols by design: it supports message signing, encryption, certificate-based application authentication and user authentication. Yet in practice it often runs in None security mode, with anonymous access, or on a server that automatically accepts every client certificate. This note explains what the security modes mean, what an attacker sees under each setting, and which configuration we recommend.

Security mode and security policy

Every OPC UA endpoint is defined by two settings:

• Security mode (MessageSecurityMode): None (no signing, no encryption), Sign (messages are signed but readable), SignAndEncrypt (signed and encrypted).
• Security policy: the algorithms in use. Recommended today: Basic256Sha256, Aes128_Sha256_RsaOaep, Aes256_Sha256_RsaPss. Deprecated and to be avoided: Basic128Rsa15 and Basic256 (based on SHA-1).

A server can offer several endpoints at once. What matters for security is the weakest endpoint offered: if the server accepts None alongside SignAndEncrypt, an attacker will choose the weaker one.

What does an attacker see?

• Unauthenticated endpoint discovery. By design, the GetEndpoints call is public: anyone can query which endpoints, policies and user token types a server offers. That alone is not a flaw, but it gives an attacker on the network an exact map.
• None mode. All traffic can be read and modified on the network: process values, recipes, alarms and write operations. If the user token policy does not require its own encryption, user names and passwords may be readable as well.
• Anonymous access. The address space can be read without authentication and, with poor permissions, written to as well. A writable node can mean direct interference with the process.
• Automatic certificate acceptance. For convenience during development, many servers (and many clients) trust every unknown certificate. Certificate-based authentication then provides practically no protection, and man-in-the-middle attacks become possible.
• Sign mode. Protects message integrity, but the data remains readable. For recipes or production data that count as trade secrets, this may not be enough.

How we test it

With written authorization, and on production systems only passively or within a maintenance window:

1. Query the endpoint list and record the modes, policies and token types offered.
2. Check whether the anonymous and None endpoints are reachable, using read-only operations only.
3. Examine the server certificate: expiry, key size, signature algorithm.
4. Review the trust list and certificate revocation list (CRL) configuration, and look for automatic acceptance.
5. Review address space permissions: which nodes are writable, and by whom.
6. From a passive traffic capture: which clients actually connect, and in which mode.

Recommended configuration

• SignAndEncrypt endpoints only, with a current policy (Basic256Sha256 or newer); disable None and the deprecated policies.
• Disable anonymous access; use user name and password or X.509 user certificates, with role-based permissions.
• A manually maintained trust list, automatic certificate acceptance turned off, and a maintained revocation list.
• Minimize writable nodes; grant write access only to clients that strictly need it.
• At network level: the OPC UA port should only be reachable from the zones that need it (IEC 62443 zones and conduits), and management and diagnostic interfaces should not be exposed to the whole network.

A practical lesson from the lab

In our own lab we examined an OPC UA aggregator, a server that combines data from several PLC modules. The typical starting point matched what we see in the field: anonymous access enabled, an empty trust list, and a diagnostic web interface reachable from the entire network. The order of remediation: first restrict the diagnostic interface and enable a host firewall, then, coordinated with the client side, tighten the security mode and authentication. The latter also requires changing the client (SCADA or MES) configuration, so it can only be done as a planned changeover.

References

• OPC Foundation: OPC 10000-2 (Security Model) and OPC 10000-7 (Profiles)
• BSI: OPC UA Security Analysis
• IEC 62443-3-3: system security requirements