TL;DR
OPC UA has built-in security layers, but most real-world vulnerabilities come from misconfiguration — anonymous access left on, weak policies never removed, no GDS in place. Three priorities: enable SignAndEncrypt on every production server, manage certificates as infrastructure (not an afterthought), and align role-based access with IEC 62443 security levels.
OPC UA is now the dominant protocol for machine-to-machine and machine-to-cloud communication in industrial environments — running on PLCs, SCADA systems, edge gateways, and MES interfaces across virtually every manufacturing vertical. The OPC Foundation's own figures put active OPC UA deployments in the hundreds of thousands, and the 2026 update to BS EN IEC 62541-2 (the OPC UA Security Model specification) reinforces that the standard was designed with enterprise-grade security primitives from day one.
The problem is not the protocol. It is the gap between what OPC UA makes possible and what actually gets configured on the factory floor. A 2026 survey cited by FlowFuse found that a significant proportion of production OPC UA servers still operate in SecurityMode None or Sign — meaning data flows in plaintext, or is signed but not encrypted. Many of the security gaps we see stem from how OPC UA integrations are first built — if your team is working on custom OPC UA or industrial API development, security configuration is best addressed at the architecture stage, not as an afterthought.
This guide covers the full security stack: transport and session security, security policies and their current status, certificate management, RBAC, IEC 62443 alignment, audit logging, and a numbered deployment checklist.
Why OPC UA Security Matters More Than Ever in 2026
OT-targeted attacks have accelerated sharply. CISA's Known Exploited Vulnerabilities (KEV) catalog added dozens of ICS/OT entries in 2024–2025, including vulnerabilities affecting SCADA HMI software and industrial communication stacks. State-sponsored actors — including Iranian groups documented by CISA in 2024 — specifically targeted water, energy, and manufacturing SCADA systems running on protocols including OPC. The attack surface has grown as OT/IT convergence opens channels that were previously air-gapped.
Regulatory pressure is reinforcing the operational risk. The EU NIS2 Directive (effective October 2024) explicitly covers operators of essential services in manufacturing, energy, and water — requiring documented security measures for industrial control systems. IEC 62443 is the reference framework for these obligations. NERC CIP applies to energy sector OT in North America. In this context, "we haven't been attacked yet" is no longer a defensible security posture.
How OPC UA Security Works: The Three-Layer Model
OPC UA security operates across three distinct layers, each independently configurable — and each independently exploitable if misconfigured.
Transport Security
At the channel level, OPC UA uses a secure conversation mechanism conceptually similar to TLS. The SecurityMode parameter controls what protection the channel applies to every message. Three modes are defined:
| Mode | Encryption | Signing | Recommended use |
|---|---|---|---|
| None | ❌ | ❌ | Testing only — never production |
| Sign | ❌ | ✓ | Legacy compatibility only |
| SignAndEncrypt | ✓ | ✓ | All production deployments |
SecurityMode None is explicitly documented in the OPC UA specification as unsuitable for production networks. Despite this, many stack implementations ship with it enabled by default, and it is rarely removed during initial commissioning.
Session Security
Once a channel is established, the session layer handles application identity. Each OPC UA application — whether server or client — holds an X.509 Application Instance Certificate. The server maintains a trust list: only certificates whose CA chain resolves to an entry in that list are accepted. Certificates not in the trust list must be rejected automatically; allowing untrusted certificates on a "warn and continue" basis defeats the purpose of the mechanism entirely.
User Authentication
Even with SignAndEncrypt and valid application certificates in place, anonymous user authentication remains a common misconfiguration. OPC UA supports three user authentication modes: Anonymous, Username+Password, and X.509 user certificates. Anonymous access — often left on for HMI convenience — means any client that can present a valid application certificate can read and write to the server without identifying its human operator. Disable it on any server that exposes write-capable nodes.
Choosing the Right Security Policy
The SecurityPolicy defines the cryptographic algorithms used for key exchange, signing, and encryption within the channel. The current status of each defined policy as of 2026:
| Policy | Key Exchange | Signing | Encryption | Status |
|---|---|---|---|---|
| Basic128Rsa15 | RSA 1024 | SHA-1 | AES-128 CBC | 🔴 Deprecated — NIST/BSI |
| Basic256 | RSA 1024 | SHA-1 | AES-256 CBC | 🔴 Deprecated |
| Basic256Sha256 | RSA 2048 | SHA-256 | AES-256 CBC | 🟡 Acceptable (legacy) |
| Aes128_Sha256_RsaOaep | RSA 2048 | SHA-256 | AES-128 CBC | ✓ Recommended |
| Aes256_Sha256_RsaPss | RSA 2048+ | SHA-256 | AES-256 CBC | ✓ Best for new deployments |
Basic128Rsa15 and Basic256 rely on RSA 1024-bit keys, which NIST formally deprecated in SP 800-131A and BSI deprecated in TR-02102-1. Both also use SHA-1, which has been broken for collision resistance since 2017. These policies must be explicitly removed from the server's allowed list — most stacks still include them by default for backwards compatibility. For any new deployment in 2026, Aes256_Sha256_RsaPss provides the strongest currently defined security profile.
Certificate Management — Treating Certificates as Infrastructure
An X.509 Application Instance Certificate identifies a specific OPC UA application instance. It contains the application URI, the public key, validity period, and the signing CA chain. Lost or expired certificates are one of the most common causes of unplanned production downtime in OPC UA environments — a connection simply stops when its certificate is rejected.
Self-Signed vs. CA-Signed
Self-signed certificates are acceptable for isolated development environments and single-node test deployments where both endpoints are fully controlled. In any multi-node production environment, especially one targeting IEC 62443 Security Level 2 or higher, self-signed certificates introduce trust list management complexity that scales linearly with the number of nodes. A CA-backed PKI reduces this to managing a single trusted root. The OPC Foundation's practical security guidelines recommend CA-signed certificates for all production deployments.
Global Discovery Server (GDS)
The GDS is an OPC UA server that provides automated certificate lifecycle management: issuance, distribution, renewal, and revocation. For deployments with more than ten OPC UA nodes, manual trust list management becomes the primary source of configuration errors. The GDS eliminates this by acting as the central CA for the OPC UA application layer. It also supports push-based certificate renewal so that no application certificate expires without an automatic replacement being issued 30 days in advance.
Reverse Connect
An often-overlooked security mechanism is OPC UA Reverse Connect, introduced in OPC UA 1.04. In standard mode, the client initiates the TCP connection to the server. Reverse Connect inverts this: the server establishes an outgoing connection to the client, which then operates the OPC UA session over that client-initiated channel from the server's perspective. This is particularly useful in DMZ and firewall-constrained scenarios where an OT-zone OPC UA server should not have any open inbound ports exposed to IT-zone clients. The server needs only outbound connectivity to a known client endpoint, keeping the firewall rule set minimal.
Private Key Protection
Application private keys must be stored in protected storage — an HSM where available, or the OS-protected key store at minimum. Private keys must never be copied between systems or stored in plaintext configuration files. A compromised private key allows an attacker to impersonate the OPC UA application to any server in the trust list.
Role-Based Access Control and Least Privilege
OPC UA's node-level RBAC lets servers expose different parts of the address space — or different method permissions — to different authenticated users or application roles. A typical production permission model defines four tiers:
- Observer — read access to telemetry nodes; no write, no method calls
- Operator — read + write to setpoint nodes; no configuration changes
- Engineer — full read/write + method calls; no user or certificate management
- Administrator — full access including security configuration
IEC 62443-3-3 Security Requirement SR 2.1 (User Authorization) maps directly to this model: each user or application should receive only the minimum permissions needed for its defined function. A SCADA historian client that only reads tag values should never hold Operator or higher privileges. Each connected application should authenticate with its own dedicated account — shared accounts make audit trails uninterpretable and make rotating compromised credentials operationally painful.
IEC 62443 and What OPC UA Covers (and What It Doesn't)
OPC UA's built-in security mechanisms cover the core security primitives that IEC 62443 requires at the component level. The mapping is direct:
| IEC 62443-3-3 SR | Requirement | OPC UA mechanism |
|---|---|---|
| SR 1.1 | Human User Identification & Authentication | Username+Password / X.509 user certificate |
| SR 1.2 | Software Process Identification & Authentication | Application Instance Certificate (X.509) |
| SR 2.1 | Authorization Enforcement | Node-level RBAC |
| SR 3.1 | Communication Integrity | SignAndEncrypt channel |
| SR 3.3 | Security Functionality Verification | Audit trail (AuditEvents) |
However, OPC UA covering these primitives is not the same as IEC 62443 compliance. The standard is a system-level assessment. Network segmentation (zone-and-conduit model), patch management procedures, personnel training, physical security, and supplier management are all within IEC 62443's scope and entirely outside what OPC UA touches. A correctly configured OPC UA deployment is a necessary component of IEC 62443 compliance; it is not sufficient on its own.
For the network architecture side of IEC 62443 zone-and-conduit design — how to structure OT and IT zones, what goes in the DMZ, and how edge gateways should be positioned — see our IIoT Architecture Guide. And for predictive maintenance workloads where IIoT data routes through multiple security zones, the same zone-boundary controls apply — see predictive maintenance: where to start for the data flow considerations.
Audit Logging and Ongoing Monitoring
OPC UA defines a built-in audit event framework. When AuditingEnabled is set to true in the ServerCapabilities node, the server emits structured audit events for security-relevant operations. These events are themselves OPC UA nodes that can be subscribed to by any authorized monitoring client and forwarded to a SIEM or OT-aware IDS.
At minimum, a production OPC UA deployment should monitor and alert on:
- Failed authentication attempts — repeated failures indicate credential stuffing or misconfigured client applications
- Certificate rejections — unexpected rejections can signal an untrusted new client or a certificate rollover that was not coordinated
- Unexpected client connections — any application URI appearing in a session that is not in the expected application inventory
- Write operations to sensitive nodes — setpoint changes and configuration writes should be logged with the user identity and timestamp
Audit events alone are not a detection system. They need to be forwarded off the OPC UA server — which may have limited storage — to a central log aggregation platform where retention, alerting, and correlation rules can be applied. Audit logging that stays only on the OPC UA server provides evidence for post-incident investigation but not real-time detection.
Implementation Checklist — 8 Steps to a Secure OPC UA Deployment
- Disable SecurityMode None on all production servers. Remove it from the list of endpoints the server advertises. Clients that require None for legacy reasons should be addressed at the client, not by leaving the server unprotected.
- Remove Basic128Rsa15 and Basic256 from allowed policies; enable Aes256_Sha256_RsaPss. These deprecated policies are enabled by default in most stacks. Explicitly configure the allowed policy list rather than relying on default settings.
- Disable anonymous user authentication. Use Username+Password at minimum for human operators; use X.509 user certificates for application-to-application connections where the identity of the connecting application matters independently of the channel certificate.
- Replace self-signed certificates with CA-issued certificates in any multi-node environment. A dedicated OPC UA PKI with an offline root CA and issuing CA is the right architecture for production deployments targeting IEC 62443 SL 2+.
- Deploy a Global Discovery Server (GDS) for automated certificate lifecycle. For more than ten OPC UA nodes, manual certificate management is a reliability risk. The GDS should be treated as critical infrastructure — highly available, backed up, and monitored.
- Configure the trust list to auto-reject unknown certificates. The default "warn and add to rejected list" behaviour of some stacks is not the same as automatic rejection. Verify that untrusted application certificates cause the server to terminate the session, not merely log a warning.
- Enable and forward audit events to SIEM. Turn on AuditingEnabled, subscribe a monitoring client to the server's AuditEventType node hierarchy, and forward events to your central log platform within the same change window.
- Run a security regression test after every firmware or stack update. OPC UA stack updates have historically re-enabled deprecated security policies or reset certificate trust lists. Treat any stack update as a potential security configuration reset and verify the full security posture before returning to production.
Building custom OPC UA integrations or industrial API middleware? YuSMP Group provides custom API and integration development for industrial environments — with security configuration addressed from the architecture stage.
Frequently Asked Questions
- Is OPC UA secure by default?
- No. Many OPC UA stacks ship with SecurityMode None or Sign (no encryption) as the default configuration. Always explicitly configure SignAndEncrypt — do not assume the stack defaults are production-appropriate.
- What security mode should I use in production?
- SignAndEncrypt with the Aes256_Sha256_RsaPss policy for all production OPC UA servers. Remove Basic128Rsa15 and Basic256 from the allowed list — both use RSA 1024-bit keys deprecated by NIST (SP 800-131A) and BSI (TR-02102-1).
- Can OPC UA replace a VPN for secure remote access?
- Partially. OPC UA encrypts at the protocol layer, but it does not replace network segmentation or access control at the network level. Best practice: keep OPC UA traffic within its security zone and use a VPN or DMZ architecture for any cross-zone or remote access scenario.
- How does OPC UA map to IEC 62443?
- OPC UA covers the core security primitives IEC 62443 requires: human and application authentication (SR 1.1/1.2), node-level authorization (SR 2.1), communication integrity via SignAndEncrypt (SR 3.1), and audit trail (SR 3.3). IEC 62443 compliance also requires network segmentation, patch management procedures, and other system-level controls that OPC UA does not address.
- What is the Global Discovery Server and do I need it?
- GDS is an OPC UA service that automates certificate issuance, renewal, and revocation across a deployment. Recommended for any environment with more than 10 OPC UA nodes — manual trust list management at that scale becomes a persistent source of configuration errors and unplanned outages.
- How often should OPC UA certificates be renewed?
- Typical Application Instance Certificate validity is 1–2 years. A GDS can automate renewal 30 days before expiry. Monitor certificate expiry dates actively — an expired certificate silently breaks production connections without triggering an application-level error that operators will recognise as a certificate problem.
Sources: OPC Foundation, Practical Security Guidelines for Building OPC UA Applications (opcconnect.opcfoundation.org, 2018); FlowFuse, OPC UA Security: How to Establish a Defensible OPC UA Security Architecture (2026-06); IntegrationObjects, OPC UA Security Explained — The Complete Guide; ANSI/BSI, BS EN IEC 62541-2:2026 OPC Unified Architecture Security Model.