OPC UA - the most secure communication protocol in industrial automation

In the world of industrial protocols, where Modbus TCP offers no authentication and S7comm transmits commands in cleartext, OPC UA (Open Platform Communications Unified Architecture) is the exception. It is the only widely used OT protocol designed from the ground up with security in mind - with X.509 authentication, TLS encryption, and a permissions model. This does not mean it is immune to attacks - but it does mean that when properly configured, it offers a level of protection unavailable from any other protocol in industrial automation.

Origins - the problems of OPC Classic

To understand why OPC UA was created and how it changed the approach to OT security, we need to look back at its predecessor. OPC Classic (OPC DA, OPC HDA, OPC A&E) appeared in 1996 as a standard for data exchange between SCADA systems, HMIs, and PLCs. It was built on Microsoft DCOM (Distributed Component Object Model) technology - and that was the source of nearly all its problems:

• Windows dependency - DCOM is exclusively a Microsoft technology. OPC Classic only ran on Windows systems, ruling out embedded devices, Linux systems, and mobile platforms.
• DCOM configuration - correctly configuring DCOM permissions was a notorious nightmare for administrators. Configuration errors led either to connectivity failures or - worse - to overly broad permissions.
• Security vulnerabilities - DCOM required opening dynamic RPC ports (often the entire 1024-65535 range), making meaningful firewall filtering impossible. Numerous vulnerabilities in the DCOM/RPC implementation (including MS03-026 exploited by the Blaster worm in 2003) posed additional risk.
• No encryption - OPC Classic offered no communication encryption. Process data transmitted between the OPC server and client could be intercepted by anyone on the network.

The OPC Foundation responded to these problems in 2008 by publishing the OPC UA specification - a completely new architecture, platform-independent, with security built into the protocol’s core.

OPC UA architecture

OPC UA is not just a communication protocol - it is a platform for data modeling and exchange. It consists of several layers:

Transport layer - OPC UA supports two transport mechanisms:

• opc.tcp:// - native binary TCP protocol (port 4840), optimized for performance
• https:// - HTTP/S transport for environments requiring web infrastructure compatibility

Address Space - a hierarchical data model where every element (process variable, alarm, method, folder) is a Node with a unique identifier (NodeId). The client browses the address space like a file system.

Information model - OPC UA allows defining object types and their relationships. A controller manufacturer can publish a model of their devices as a Companion Specification - e.g. OPC UA for Machinery, OPC UA for Robotics, OPC UA for PackML.

Technical parameters

Parameter	Value
Port	4840/TCP (opc.tcp), 443/TCP (HTTPS)
Transport	TCP/IP (binary) or HTTPS
Authentication	X.509 certificates (application and user), username/password, Kerberos, JWT tokens
Encryption	TLS 1.2/1.3 (HTTPS), or built-in UA Secure Channel mechanism (AES-128/256-CBC, RSA-OAEP)
Integrity	HMAC-SHA256, RSA/ECDSA digital signature
Standard	IEC 62541 (14 parts)
Organization	OPC Foundation (opcfoundation.org)

Security model - three modes

OPC UA defines three security modes (Security Mode) that client and server negotiate during connection establishment:

Mode	Authentication	Encryption	Integrity	Use case
None	None	None	None	Diagnostics only in isolated test environments
Sign	X.509 certificate	None	Digital signature (RSA/ECDSA)	When data confidentiality is not required but integrity is
SignAndEncrypt	X.509 certificate	AES-128/256-CBC or AES-128/256-GCM	Digital signature + HMAC	Recommended for production environments

Two-level authentication

OPC UA applies authentication at two levels:

1. Application level - every OPC UA application (client and server) has an X.509 certificate that uniquely identifies it. During connection establishment (Secure Channel), both sides exchange certificates and verify them mutually. The server can reject connections from unknown applications.

2. User level - after the secure channel is established, the client authenticates the user via one of the following methods: anonymously (Anonymous), with username and password (UserName), with a user X.509 certificate, or with an external token (Kerberos, JWT).

This two-level model means that even if an attacker intercepts user credentials, they still need the client application certificate registered on the server.

Security assessment

Strengths

OPC UA is recognized as the best-secured OT protocol. The German Federal Office for Information Security (BSI) conducted an in-depth analysis of the specification in 2016 and published the report “OPC UA Security Analysis” (BSI, OPC UA Security Analysis, 2016) - confirming that the security architecture is solid and well-designed, provided it is correctly configured.

Known vulnerabilities

Despite the sound design, OPC UA implementations are not free from bugs:

• CVE-2022-29862 - a vulnerability in the OPC Foundation .NET Standard Stack enabling DoS through a specially crafted packet (Claroty Team82, 2022). An attacker could trigger an infinite loop, freezing the OPC UA server.
• CVE-2023-27321 - a Use-After-Free (UAF) in the Unified Automation C++ SDK, enabling remote code execution (ZDI-23-543).
• None mode - the greatest practical threat is not a code vulnerability but the deliberate selection of “None” mode by administrators. Many OPC UA deployments in OT environments operate without authentication and encryption - often “temporarily” (which in OT means permanently). An OPC UA server in None mode is functionally equivalent to a Modbus TCP server in terms of security.

MITRE ATT&CK for ICS

Technique	ID	OPC UA context
Exploitation of Remote Services	T0866	Exploiting vulnerabilities in the OPC UA server
Point & Tag Identification	T0861	Browsing the server’s address space
Monitor Process State	T0801	Subscribing to process value changes
Manipulation of Control	T0831	Writing values through OPC UA methods

Segmentation and configuration recommendations

Key recommendations

1. Enforce SignAndEncrypt mode - on production servers, disable None and Sign modes. Ensure the Security Policy includes at least Basic256Sha256 or the newer Aes128_Sha256_RsaOaep. Older policies (Basic128Rsa15, Basic256) are deprecated and vulnerable to attacks.

2. Manage X.509 certificates - deploy a PKI infrastructure for issuing, renewing, and revoking OPC UA application certificates. Do not use self-signed certificates in production environments with more than a few devices - trust management becomes unmanageable. OPC UA Global Discovery Server (GDS) automates certificate distribution.

3. Enable user authentication - do not rely solely on application-level authentication. Configure user authentication and define roles with minimal permission sets (principle of least privilege). OPC UA Part 3 defines roles: Anonymous, AuthenticatedUser, Observer, Operator, Engineer, Supervisor, ConfigureAdmin, SecurityAdmin.

4. Network segmentation - place OPC UA servers in a dedicated OT network zone. Client-server communication should pass through a firewall with rules restricting access to port 4840 to authorized IP addresses only.

5. Audit and log - OPC UA has a built-in audit mechanism (Audit Events). Enable security event logging: failed authentications, rejected certificates, configuration changes, value writes. Export logs to a SIEM system.

6. Migration from OPC Classic - if you still use OPC Classic (DA/HDA/A&E), plan migration to OPC UA. During the transition, use OPC Classic-to-UA gateways with authentication enabled on the UA side. Never expose OPC Classic (DCOM) servers outside the local segment.

Comparison with OPC Classic

Feature	OPC Classic (DA/HDA/A&E)	OPC UA
Platform	Windows only (DCOM)	Cross-platform (Windows, Linux, embedded)
Ports	Dynamic RPC (1024-65535)	4840/TCP or 443/TCP
Authentication	DCOM/NTLM (problematic)	X.509, username/password, Kerberos, JWT
Encryption	None	TLS 1.2/1.3, AES-128/256
Firewall-friendly	No (dynamic ports)	Yes (single port)
Data model	Flat (tags)	Hierarchical (Address Space)
Status	Being phased out	Actively developed

Summary

OPC UA is the best-secured protocol in the OT ecosystem - but only when its security mechanisms are actively enabled. SignAndEncrypt mode with X.509 certificates and user authentication provides confidentiality, integrity, and accountability of communication at a level comparable to IT protocols. Organizations should treat migration from OPC Classic and legacy protocols (Modbus, S7comm) to OPC UA as a strategic element of their OT security program - while remembering that the protocol itself does not replace network segmentation, anomaly monitoring, and vulnerability management.

Open source tools

Tool	Language	Description	Link
open62541	C99	Complete OPC UA implementation (client and server), certified by OPC Foundation	GitHub
opcua-asyncio	Python	Asynchronous OPC UA client and server - scripting security tests	GitHub
UaExpert	GUI	Free OPC UA client with address space browser and attribute monitor	Unified Automation

---

Sources:

• OPC UA Specification (IEC 62541) - OPC Foundation
• OPC UA Security Analysis - BSI (Bundesamt fur Sicherheit in der Informationstechnik), 2016
• CVE-2022-29862 - OPC UA .NET Standard Stack DoS - Claroty Team82, 2022
• IEC 62443 - Industrial communication networks - IT security - IEC
• MITRE ATT&CK for ICS - MITRE Corporation
• NIST SP 800-82 Rev. 3 - Guide to OT Security - NIST, 2023
• OPC UA Security Best Practices - OPC Foundation, 2021