OPC-UA: The Most Widely Used OT Protocol and Its Most Common Security Problems

OPC-UA: What It Is and Why It Is Everywhere

OPC-UA (Open Platform Communications Unified Architecture) is the standard protocol for communication between components in modern industrial automation systems. Developed by the OPC Foundation as the evolution of the earlier classic OPC (based on Windows COM/DCOM), OPC-UA was designed to be platform-independent, scalable from the edge to the cloud, and secure by design, with a security model based on X.509 certificates, encryption and authentication built into the protocol specifications.

In practice, OPC-UA is the glue that connects PLCs to SCADA systems, process servers to historians, and OT gateways to industrial data analytics platforms. It is found in virtually every modern production plant, in new-generation CNC machinery, and in supervisory systems compliant with Industry 4.0 specifications. Its adoption is so widespread that understanding its security problems is equivalent to understanding a substantial part of the attack surface of any contemporary OT network.

The paradox of OPC-UA is that the security specifications are well designed, considerably better than those of Modbus, DNP3 or older industrial protocols, yet real-world deployments often fail to use them. Operational pressure, compatibility with legacy clients, and the need to avoid breaking working configurations systematically lead to deployments with the security features disabled or degraded.

Anonymous Sessions: The Most Common Problem

OPC-UA supports several authentication mechanisms: client certificate, username/password, and anonymous access. The latter mode exists for specific diagnostic and test scenarios, but it is enabled in production with a frequency that surprises those who approach real OT environments for the first time.

The reasons anonymous access is left enabled are almost always operational. A legacy client that does not support certificate-based authentication. A vendor HMI panel that uses anonymous for ease of implementation. A system integrator who configured it that way during commissioning, after which no one ever reviewed the configuration. The result is that anyone who can reach the OPC-UA server at the network level can connect and read, and in some cases write, the exposed nodes without presenting any credentials.

The scope of this access depends on how the server's node hierarchy is structured: in permissive configurations, an anonymous client can read all process tags, navigate the object tree and obtain a complete map of the plant. In worse configurations, it can also write values to nodes that control setpoints or actuators.

From a detection standpoint, an anonymous session toward an OPC-UA server is distinguishable in network traffic by analyzing the session handshake message. The UserTokenType field in the CreateSession and ActivateSession requests indicates the authentication type used: AnonymousIdentityToken is the value that indicates anonymous access, and it does not require deep decoding to be detected.

Self-Signed Certificates and Disabled Validation

OPC-UA uses X.509 certificates for two purposes: to authenticate the server to the clients (analogous to the role of TLS on websites) and to authenticate the clients to the server when certificate-based authentication is used. Both mechanisms require a certificate management infrastructure, a PKI, which in most manufacturing organizations does not exist or is managed loosely.

The practical result is that OPC-UA certificates in production are almost always self-signed, that is, signed by the server itself without a trusted CA acting as guarantor. Clients connecting to a server with a self-signed certificate receive a warning that the certificate cannot be validated and, in order not to interrupt operations, they are configured to accept any certificate without validation.

This behavior, which in a web environment would be equivalent to clicking "accept anyway" on a site with an expired or invalid certificate, forever, for every connection, drains all meaning from the protection that OPC-UA certificates are supposed to provide. An attacker in a man-in-the-middle position on the OT network can present their own self-signed certificate in place of the legitimate server's, and the clients will connect without detecting the substitution.

Security Policy "None": No Encryption

OPC-UA defines security policies that determine the combination of algorithms used for signing and encrypting communications. Among these is the special "None" policy, which completely disables both signing and encryption: traffic flows in the clear, with no cryptographic integrity.

"None" exists for test and debugging scenarios, and for completely isolated environments where encryption is deemed unnecessary. In practice it is found in production for two reasons: compatibility with very old clients that do not support modern cryptographic policies, and performance reasons on hardware with limited computational capacity.

The security problem is direct: with the "None" policy, an attacker who has passive access to the OT network traffic can read the entire content of OPC-UA sessions: process tag values, commands to actuators, configuration data. With active access (man-in-the-middle), they can modify messages in transit without the server or the client noticing, because there is no cryptographic signature to break.

In network traffic, the security policy used by an OPC-UA session is visible in the OpenSecureChannel message: the SecurityPolicyUri field contains the URI of the selected policy. The URI "http://opcfoundation.org/UA/SecurityPolicy#None" unambiguously identifies unencrypted and unsigned sessions.

Exposure on Non-Standard Ports and Discovery

The standard OPC-UA port is TCP 4840. In practice, many deployments use different ports: for convenience, to avoid conflicts with other services, or simply by the integrator's choice. This creates an inventory problem: monitoring systems configured to detect OPC-UA on port 4840 do not see the servers that use alternative ports.

OPC-UA includes a discovery mechanism, the Local Discovery Server (LDS), which allows clients to find the servers available on the network. In deployments where the LDS is active and reachable, a client can automatically obtain the list of all OPC-UA servers on the network, along with their endpoints and supported security policies. This mechanism, designed to simplify operational configuration, is also an extremely efficient reconnaissance mechanism for an attacker: a single query to the LDS returns a complete map of the OPC-UA servers present.

Correctly detecting OPC-UA on the network requires identification based on the protocol's behavior, the Hello/Acknowledge handshake process that characterizes the opening of every binary OPC-UA connection, not just on the port number. An industrial traffic monitoring system that decodes application protocols identifies OPC-UA sessions on any port.

What You See in the Traffic and How to Detect Anomalous Access

Legitimate OPC-UA sessions have recognizable characteristics: they are established from known source addresses (the SCADA client, the historian), they use security policies consistent with the plant's configuration, and they have predictable operation patterns (periodic reading of a stable set of tags).

The signals that indicate anomalous access or problematic configurations include:

• Sessions from previously unseen addresses: an OPC-UA client that connects to a server from an address that has never established sessions before should be investigated. It may be a new engineering tool, or it may be an attacker with access to the network.
• Sessions with security policy None or Anonymous on servers that should not use them: if the baseline shows that a given server always uses the Basic256Sha256 policy, a session with the None policy toward the same server is anomalous.
• Intensive browse operations on the address space: Browse operations, which navigate the server's node hierarchy, are normal during configuration and rare during operation. A burst of Browse operations from an unusual client indicates reconnaissance.
• Writes to nodes that show only Read traffic in the baseline: an OPC-UA node that is queried every 5 seconds for reading but never receives writes is probably a process sensor. A write to that node from an unauthorized client is a critical signal.
• Traffic volume significantly above the baseline: this could indicate a mass dump of process data, exfiltration of historical data, or configuration data.

OPC-UA is a well-documented protocol that is fully decodable from network traffic analysis. The granularity of visibility it offers, down to the level of the individual nodes read and written, with their associated values, is superior to that of older protocols such as Modbus. This is an advantage for security monitoring, provided that the tools used implement full protocol decoding and do not limit themselves to TCP-level visibility.

The MON5 Angle

Anonymous sessions, the None policy, certificates that are never validated: all the problems described in this article are visible in the traffic, as long as OPC-UA is decoded at the application level rather than stopping at the TCP port. The passive NDR of MON5's PROTECT phase does exactly this: native decoding of OPC-UA (in addition to Modbus, Siemens S7, PROFINET, EtherNet/IP), baselines per server and per node, alerts on unexpected anonymous sessions, writes to read-only nodes, and anomalous Browse bursts.

All of this out of band, without touching the production systems. To find out how the OPC-UA servers in your plant are really configured, the entry point is an OT assessment.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.