What OPC UA Is and Why It Matters for ICS Security

OPC Unified Architecture (OPC UA) is the IEC 62541 standard for industrial device interoperability. It replaced the Windows DCOM-dependent OPC Classic stack with a platform-independent, service-oriented protocol that runs over TCP (port 4840 by default) and optionally over HTTPS (port 4843). Most modern PLCs, HMIs, historian systems, and SCADA platforms either natively support OPC UA or use it for integration with higher-level systems.

The shift to OPC UA created a genuine security improvement over OPC Classic: the standard includes built-in authentication, message signing, and encryption. But built-in does not mean enabled by default, and the protocol’s complexity has introduced a class of vulnerabilities that well-resourced threat actors have learned to exploit.

Dragos, Claroty, and CISA advisories from 2024-2026 document consistent targeting of OPC UA endpoints in energy and manufacturing environments. Volt Typhoon’s documented pre-positioning in US critical infrastructure specifically involved traversal from IT networks into OT segments via protocols that bridge both — OPC UA over HTTPS is a documented traversal vector.

The OPC UA Threat Model

OPC UA defines three security modes, and the weakest is almost always what gets deployed:

Security ModeMessage SigningEncryptionWhat it means
NoneNoNoAll data transmitted in plaintext, no authentication of message origin
SignYesNoIntegrity protected but not confidential
SignAndEncryptYesYesBoth integrity and confidentiality

In production deployments, None is extremely common. The reasons are operational: when a PLC and a historian are on the same isolated OT network, encryption seems unnecessary; certificates are complex to manage; some legacy devices only support None. The result is that an attacker who gains access to the OT network segment can read all OPC UA traffic without any cryptographic barrier.

Certificate-based authentication is OPC UA’s primary identity mechanism, but certificate management in OT environments is consistently weak:

  • Certificates are often self-signed with no PKI infrastructure
  • Certificate expiry causes production outages, so operators disable expiry checks rather than maintain a renewal process
  • Application certificates from decommissioned devices remain trusted
  • No certificate revocation checking in most deployments

Session hijacking is possible when security mode is None or when certificate validation is disabled. An attacker on the network segment can observe session initiation, replay session tokens, or inject forged messages.

Documented Vulnerability Classes

CVE-2023-27321 — OPC Foundation .NET Standard Stack: Infinite Loop (DoS) The .NET reference stack had an infinite loop vulnerability in the session handling code triggered by a malformed message. Any server built on the reference implementation was affected. This class of vulnerability — where protocol complexity creates parsing edge cases — has appeared repeatedly across OPC UA implementations.

CVE-2024-33892 / CVE-2024-33893 — Prosys OPC UA SDK: Authentication Bypass and Denial of Service The Prosys Java SDK had separate authentication bypass and DoS vulnerabilities. Prosys is widely embedded in industrial historian and integration middleware products. Authentication bypass in an OPC UA server means an attacker can connect as any user, including privileged system accounts that can write values to PLCs.

CVE-2022-44725 — OPC Foundation UA-.NETStandard: Heap Corruption via Crafted Request Memory corruption in the decoder for specific NodeId types. Exploitable for potential code execution on the OPC UA server process.

ICSA-24-044 (CISA Advisory) — Multiple OPC UA Products CISA’s February 2024 advisory documented vulnerabilities across nine OPC UA implementations simultaneously, including products from ABB, Beckhoff, Bosch Rexroth, Cognex, Honeywell, and others. The vulnerability class was consistent: improper input validation in message parsing, enabling crash (DoS) or potentially RCE in some implementations.

The recurring theme across these CVEs is that the OPC UA specification’s complexity — it defines hundreds of data types, services, and security profiles — creates a large attack surface that individual implementors handle inconsistently.

Nation-State Exploitation Context

Volt Typhoon (Chinese state-sponsored, assessed as pre-positioning for potential conflict scenarios) has been documented performing reconnaissance against OPC UA endpoints in US energy, water, and manufacturing environments. Their approach has been low-and-slow: establishing persistence in IT networks, then identifying IT/OT boundary systems that communicate via OPC UA between the enterprise network and the control system network. OPC UA over HTTPS (port 4843) is particularly useful as a traversal vector because it passes through firewalls that permit HTTPS outbound.

INCONTROLLER/PIPEDREAM (the 2022 toolkit attributed to a nation-state actor targeting energy infrastructure) included a module specifically for OPC UA reconnaissance and interaction. The toolkit could enumerate OPC UA server namespaces, read and write node values, and subscribe to data changes — the full capability needed to understand a control system’s structure and potentially manipulate it.

These campaigns establish that OPC UA is not a theoretical threat surface. Adversaries with ICS-targeting capabilities have invested in OPC UA tooling because the protocol’s ubiquity makes it a reliable attack path.

Hardening Guide

1. Disable Security Mode None

This is the highest-impact single change. On every OPC UA server in your environment:

# Example: Forcing minimum security policy in a Unified Automation server config
<Endpoints>
  <Endpoint>
    <SecurityMode>SignAndEncrypt_Basic256Sha256</SecurityMode>
    <!-- Remove any Endpoint with SecurityMode=None -->
  </Endpoint>
</Endpoints>

If legacy clients require None mode to connect, treat those clients as requiring upgrade or replacement. Operating OPC UA with None security mode on a network reachable by any modern threat actor is equivalent to running unencrypted HTTP for authentication.

Operational consideration: Test changes in a staging environment first. Changing security mode on a production OPC UA server without updating all connected clients will cause connectivity failures.

2. Implement Certificate-Based Authentication with a PKI

Stand up a simple PKI (Microsoft CA, EJBCA, or Smallstep) dedicated to OT authentication. Issue application certificates with:

  • 2-year maximum validity
  • Subject Alternative Names matching the application’s hostname and IP
  • Key usage constrained to Digital Signature and Key Encipherment

Distribute the CA certificate to all OPC UA servers as a trusted issuer. This eliminates the need to manage individual self-signed certificates on each server.

Certificate renewal automation: Use a scheduled task or configuration management tool to renew certificates 90 days before expiry. The risk of an expired certificate causing an outage is real; the solution is automation, not disabling checks.

3. Network Segmentation: No Direct IT-to-OT OPC UA

OPC UA servers in the control system network should not be directly reachable from the enterprise IT network. Connections should traverse:

  1. A demilitarised zone (DMZ) with a historian or data diode
  2. Or a unidirectional gateway (Waterfall, Owl, or equivalent) for production-critical read-only data flows

If bidirectional OPC UA communication between IT and OT is operationally required, enforce it through a proxy server in the DMZ that authenticates both sides independently. The proxy logs all sessions and data transfers, creating an audit trail.

4. Firewall Port Restriction

OPC UA default ports (TCP 4840, TCP 4843) should be explicitly firewalled at every network boundary:

# Example ACL: OT network firewall
permit tcp [historian-server] any eq 4840  # OPC UA TCP
permit tcp [historian-server] any eq 4843  # OPC UA HTTPS
deny tcp any any eq 4840
deny tcp any any eq 4843

Allow only the specific historian or integration servers that legitimately need OPC UA access. Block port 4840/4843 everywhere else, including between different OT network zones.

5. Patch and Monitor OPC UA Implementations

OPC UA vulnerabilities are published through CISA ICS-CERT advisories and vendor security bulletins. Establish a monitoring process for:

  • Your OPC UA SDK vendor (Unified Automation, Prosys, OPC Foundation .NET stack, etc.)
  • Your historian platform’s OPC UA implementation (OSIsoft PI, Inductive Automation Ignition, Kepware, etc.)
  • Embedded OPC UA in PLCs and HMIs (check vendor advisories quarterly)

Given the OT patching constraints, not every patch will be deployable immediately. Use virtual patching (ICS IDS rules, firewall rule tightening) for vulnerabilities you cannot patch in the near term.

6. OPC UA Monitoring with ICS IDS

Deploy an ICS-aware intrusion detection system (Dragos, Claroty, Nozomi Networks, or open-source Zeek with the OPC UA analyser module) that parses OPC UA traffic. Configure alerts for:

  • Sessions using Security Mode: None (should be zero in a hardened environment)
  • Authentication failures — especially repeated failures against privileged accounts
  • Write operations outside of approved engineering workstations
  • Unusual NodeId access patterns — reading or writing nodes not accessed during normal operations
  • Large session counts or rapid session establishment (DoS reconnaissance)

Zeek’s OPC UA protocol analyser generates structured logs of every session, service call, and data change, suitable for forwarding to a SIEM for correlation.

Risk Prioritisation for OT Operators

If your organisation cannot address all of the above simultaneously, prioritise in this order:

  1. Disable Security Mode None on internet-adjacent or IT-connected OPC UA servers — these are your highest-exposure assets
  2. Firewall OPC UA ports at the IT/OT boundary — prevents traversal from compromised IT infrastructure
  3. Deploy OPC UA monitoring — even without hardening, visibility lets you detect exploitation attempts
  4. Certificate-based authentication rollout — reduces session hijacking risk, can be phased by site
  5. Full segmentation and PKI — the complete hardened architecture, achievable in 12-24 months for most organisations

OPC UA’s security features are genuinely strong when configured correctly. The gap between what the standard specifies and what gets deployed in production is the OT security industry’s most consistent frustration — and an adversary’s most consistent opportunity.

Tags
OPC-UAICSSCADAindustrial-protocolcertificate-managementauthenticationnetwork-segmentationPLCsCISAhardening