OPC UA Security
OPC UA (Open Platform Communications Unified Architecture) is the standard machine-to-machine protocol for industrial automation — the reference protocol of Industry 4.0/RAMI 4.0 — letting PLCs, SCADA systems, and devices from different vendors exchange data and control commands. Unlike legacy ICS protocols (Modbus, Profinet), it was designed with security: authentication, signing, and encryption are in the spec. The recurring failure is the gap between “built in” and “turned on” — 92% of internet-reachable servers show configuration issues and 44% allow unauthenticated access (Dahlmanns et al. 2020). 1
Protocol shape (on the wire)
- Transport: binary
opc.tcpon port 4840 (default). Also HTTPS bindings (4843/443) and vendor listeners: 49320 (KepServerEX), 62541 (OPC Foundation reference stack), 48050 (UaGateway). Multiple endpoints per host. - Message types: HEL (hello), OPN (OpenSecureChannel), MSG, CLO.
- Endpoint model: each endpoint advertises a triple chosen independently:
- SecurityMode: None / Sign / SignAndEncrypt
- SecurityPolicy: crypto suite (Basic128Rsa15 and Basic256 are deprecated; floor is Basic256Sha256, modern is Aes128_Sha256_RsaOaep / Aes256_Sha256_RsaPss)
- UserIdentityToken: Anonymous / Username&Password / Certificate
- Discovery is unauthenticated: FindServers, FindServersOnNetwork, GetEndpoints must work without security — they leak ApplicationUri, product/vendor strings, endpoints.
- Application authentication is certificate-based with a per-application Trustlist; user authentication is a separate layer on top. Anonymous user access is far less dangerous when application auth is enforced — many deployments disable the wrong layer.
- Address space: hierarchical nodes. Start browsing at ObjectsFolder (i=85). Useful NodeIds: i=2253 (Server — vendor strings), i=2256 (ServerStatus), i=2267 (ServerDiagnosticsSummary — session counts). 2
Why deployments fail (Erba et al. 2021, 48 artifacts)
38 of 48 products/libraries had security issues; 7 supported no security at all. The failures cluster in Trustlist (certificate) management — three recurring patterns:
- Missing Trustlist support — signing/encryption offered but no cert validation → MitM always possible.
- Trustlist disabled by default / auto-accept — e.g., node-opcua’s
automaticallyAcceptUnknownCertificate=true; Siemens/Bachmann instructions default to accept-all. A “secure” connection that’s actually wide open. - Certificate exchange over unauthenticated OpenSecureChannel — vendor instructions (ABB, Beckhoff, Bosch Rexroth, Codesys, Eaton, GE, Hitachi, Lenze, Panasonic, Wago) tell users to push certs over the insecure channel then trust them → attacker installs a rogue client cert. Codesys propagation potentially touches 400+ manufacturers.
Demonstrated consequences: Rogue Server, Rogue Client, and Middleperson attacks that steal credentials (even across “encrypted” sessions), eavesdrop on process data, manipulate sensor/actuator values, and blind operators (screens show normal). The standard itself permits these insecure behaviors — partly a specification flaw.
Assessment playbook (detect / confirm / remediate)
- Discover:
nmap -sV -Pn -n --open -p 4840,4843,49320,48050,53530,62541 <target>. Shodan:port:4840,product:"opc ua",ssl:"urn:opcua". - Fingerprint: GetEndpoints per transport — capture SecurityPolicyUri, SecurityMode, UserTokenType. Any endpoint offering SecurityMode None or policy Basic128Rsa15 is a finding.
- Confirm anonymous access: connect with an anonymous UserIdentityToken, browse from
i=85. If allowed, test
Callon maintenance Method nodes (e.g.,ns=2;s=Reset) — vendors often forget role bindings on custom methods. - Confirm cert validation: connect with a self-signed throwaway cert — if the server accepts it, the Trustlist is disabled/auto-accept (the Erba et al. finding).
- Scan:
opalopc -vv opc.tcp://<target>:4840— flags anonymous logins, weak policies, cert validation errors, writable variables. Securaopcattacktests Basic128Rsa15 padding oracles and HTTPS reflection bypasses. - Known CVEs to check: open62541 ≤1.4.6 (CVE-2024-53429, pre-auth UAF crash); OPC Foundation .NET stack <1.5.374.158 (CVE-2024-42512/13); Softing SDK (CVE-2025-7390, CN-replay cert bypass).
Remediation priorities
- Kill SecurityMode None on anything carrying process data; enforce SignAndEncrypt.
- Remove deprecated policies (Basic128Rsa15, Basic256); floor = Basic256Sha256.
- Enforce the Trustlist — auto-accept off; root of trust established out-of-band, never via unauthenticated SecureChannel exchange. One cert per instance from a company CA (GDS-managed at scale); never trust a public CA root.
- Enforce both authentication layers: application (certs) + user (no anonymous) with RBAC.
- Segment; consider Reverse Connect (server dials out — OPC UA Part 6) so no inbound firewall ports stay open. Note Reverse Connect widens the client-side attack surface (rogue server → client RCE), so clients must validate ServerUri, EndpointUrl, and server certs strictly.
- Keep auditing on and watched; patch the stack and gateways; verify config matches policy by testing (connect with an invalid cert and confirm rejection).
Cross-references
- ntlm-relay-attacks — the Windows-domain analogue: another protocol where security is optional-by-default and the fix is enforcement, not new crypto
- windows-server-2012-r2-security-assessment — likely co-present on the same engagement
- institutionally-constrained-technology-adoption — OT security debt as an institutional phenomenon: organizations rationally under-invest in enforcement
- cooperation-and-defection — vendor instruction quality as a norm-enforcement failure (Erba et al.’s “misleading instructions” finding)
See Also
Sources
- Alessandro Erba, Anne Muller, Nils Ole Tippenhauer (CISPA) 2021 — Security Analysis of Vendor Implementations of the OPC UA Protocol for Industrial Control Systems
- 4840 - Pentesting OPC UA (HackTricks)