OPC UA Security Guide: Security Modes, Policies, Application Certificates and GDS

OPC UA has a strong security model on paper, but plants routinely run it with security mode None, deprecated policies, anonymous users and trust lists that accept any certificate. The BSI found no systematic flaws in the OPC UA specification, yet the weakness it did find in a reference implementation could be exploited when security functions were switched off, and the PIPEDREAM (INCONTROLLER) toolkit included a module that connected to OPC UA servers with default or stolen credentials. This guide explains how OPC UA security actually works (SecureChannel, Session, SecurityPolicy, application instance certificates, trust lists and the Global Discovery Server) and how to configure, roll out and monitor it. It is defensive guidance for OT engineers, integrators, and the security teams who own industrial PKI and access control. For the wider IIoT architecture, start with the Industrial IoT (IIoT) Security Guide; this page goes deeper on OPC UA itself.

Key takeaways

• Two layers, two identities. The SecureChannel authenticates applications with application instance certificates; the Session authenticates users with tokens. Hardening one without the other leaves a gap.
• Mode and policy are separate choices. Use Sign or SignAndEncrypt with a current SecurityPolicy; Basic128Rsa15 and Basic256 are deprecated, and a "best available" client setting can still fall back to no security.
• The trust list is the access control list. Every certificate in a server's TrustList (or issued by a CA in it) can open a SecureChannel, so auto-accepting certificates turns authentication off in practice.
• Certificates are non-human identities. Each OPC UA client and server is a machine identity with a private key, an expiry date and an owner; manage them centrally with a GDS or your PKI, not by hand.
• Stacks need patching too. The OPC Foundation published specification and .NET Standard stack advisories as recently as August and October 2026, so track vendor SDK versions in every product.

How OPC UA security works

OPC 10000-2 (Part 2, Security Model, current release 1.05.06 published 22 October 2025) defines the objectives OPC UA supports: authentication, authorisation, confidentiality, integrity, non-repudiation, auditability, availability and, in 1.05, perfect forward secrecy. It splits client/server communication into layers:

• Communication layer (SecureChannel): established with OpenSecureChannel. It provides signing, encryption and application authentication, using each side's ApplicationInstanceCertificate. Symmetric keys are renewed periodically; Part 2 suggests about every two hours for client/server and about every hour for PubSub, depending on message volume.
• Application layer (Session): created with CreateSession and ActivateSession. It carries user authentication (anonymous, user name and password, X.509 user certificate or issued token such as a JWT) and user authorisation through Roles such as Operator, Engineer and Observer mapped to Permissions on nodes.
• Transport: typically opc.tcp (TCP port 4840 by default) or HTTPS and WebSockets. Part 2 notes that HTTPS alone secures the channel but does not provide OPC UA application authentication.
• PubSub: publishers and subscribers share symmetric keys from a Security Key Server. All members of a SecurityGroup trust each other equally, so group design is an access control decision.

Part 2 is explicit that OPC UA does not protect a compromised operating system, and that it operates inside the site's cybersecurity management system: firewalls, zoning, host hardening and patching remain necessary. See the IEC 62443 Guide.

Security modes and SecurityPolicies

A server publishes endpoints, each combining a MessageSecurityMode and a SecurityPolicy. Administrators decide which endpoints exist; clients choose from those offered.

Part 2 states that algorithms must be reviewed periodically because they weaken over time, and the normative profile definitions are published online so they can change faster than the base specification. Check the profile list for your release before fixing policy choices in a site standard. On the client side, avoid a "best available" setting: the OPC Foundation's own companion specification notes that it can result in no security if the server offers None.

Application instance certificates and trust lists

Every OPC UA application instance (each server and each client installation) holds an ApplicationInstanceCertificate whose subject alternative name contains the ApplicationUri. When a SecureChannel opens, each side checks whether it trusts the other's certificate using its TrustList: an administrator-controlled store of trusted certificates, issuer (CA) certificates and certificate revocation lists.

• Never auto-accept in production: many SDKs place unknown certificates in a rejected folder and offer an option to trust them automatically. Use that option only in a lab. CISA's PIPEDREAM advisory recommends enabling application authentication with explicit trust lists.
• Bind certificates to the ApplicationUri and host: validate that the URI and hostnames in the certificate match the application and endpoint. For Reverse Connect, Part 2 requires clients to check that the incoming connection comes from the expected server (ServerUri and EndpointUrl).
• Use real key sizes and good entropy: Part 2 calls for support of 2048, 3072 and 4096-bit RSA keys, cryptographic random number generators, and avoiding certificate generation on first boot of embedded devices before entropy is available.
• Protect private keys: store them with file permissions that only the service account can read, or in a TPM or HSM where the product supports it, and keep the CertificateStore restricted to administrators.
• Revoke, do not just delete: when a laptop running an engineering client is lost, revoke its certificate at the CA and push the CRL, rather than relying on someone remembering to delete it from every server.

Global Discovery Server and certificate lifecycle

OPC 10000-12 (Part 12, Discovery and Global Services, release 1.05.07 published 15 April 2026) defines certificate management in two models.

• Push management: a CertificateManager connects to the server's ServerConfiguration object with the SecurityAdmin role. The recommended order is to update the TrustList first (so new CRLs arrive before the new certificate), then CreateSigningRequest, then UpdateCertificate, then ApplyChanges, which may close endpoints and force clients to reconnect. TrustList changes use Open, Write and CloseAndUpdate.
• Pull management: the application itself connects to the GDS, checks GetCertificateStatus, submits StartSigningRequest (or StartNewKeyPairRequest for devices without enough entropy), collects the result with FinishRequest, and downloads its trust list with GetTrustList, checking LastUpdateTime within twice the UpdateFrequency.
• Roles: SecurityAdmin changes a server's security configuration; CertificateAuthorityAdmin can request or revoke any certificate and update any trust list; RegistrationAuthorityAdmin approves signing requests. These are some of the most powerful identities in the OT estate and deserve privileged access controls. See the OT and ICS Identity and Access Guide.
• Renewal: Part 12 triggers renewal on expiry, administrator action or policy, and servers can raise alarms about expiring CRLs. Expired application certificates stop communication, so treat renewal as an availability control. See the Machine Identity, PKI and Certificate Lifecycle Guide.

User authentication and authorisation

• Disable anonymous access on endpoints that allow writes or method calls. Keep anonymous read-only access only where a risk assessment accepts it.
• Prefer certificate or issued tokens over passwords: X.509 user certificates or JWTs from an identity provider support MFA upstream and central revocation. Part 2 requires servers to validate JWT signatures and enforce roles.
• Never send passwords on an unencrypted channel: user name tokens must be encrypted with the server's certificate; with mode None they cannot be protected properly.
• Map users to Roles and Permissions: use the standard roles (Observer, Operator, Engineer, ConfigureAdmin, SecurityAdmin) and node permissions so that a dashboard account cannot write setpoints. Part 2 advises elevating to SecurityAdmin only while performing those duties.
• Terminate on compromise: Part 2 requires connections using compromised application or user credentials to be terminated, which needs a working revocation path.
• No hardcoded passwords: Part 2 forbids hardcoding; integration clients (historians, MES connectors) should use their own certificate identity, stored securely, not a shared operator login.

Implementation roadmap

1. Discover: list every OPC UA server and client, its endpoints, modes, policies, user token types and SDK version. Passive network monitoring on TCP 4840 and vendor-specific ports, plus each server's GetEndpoints response, gives a quick baseline.
2. Design the trust model: choose CA-signed or GDS-managed certificates per zone, name the CA owner and decide the certificate lifetime and CRL publication interval.
3. Pilot one cell: issue certificates, enable SignAndEncrypt with a current policy alongside the existing endpoint, move clients one by one, and confirm performance on the slowest controller.
4. Remove insecure endpoints: once all clients use the secure endpoint, delete None and deprecated policies, disable anonymous write access and turn off certificate auto-accept.
5. Roll out by zone: repeat per production line during planned maintenance windows, with the old configuration exported as a rollback package.
6. Operate: automate renewal and CRL distribution through the GDS or PKI, subscribe to the OPC Foundation advisories and vendor PSIRTs, and review policies annually.

Rollback: keep the previous server configuration and trust list export for each change. If a client fails after a policy change, restore the previous endpoint for that client only, record it as a time-limited exception and fix the client, rather than re-enabling None for everyone. Small versus large sites: a single machine builder's cell can run a small CA-signed model managed by the integrator; a multi-site manufacturer should standardise on a GDS or enterprise PKI with central monitoring.

Detection and measurement

Part 2 expects clients and servers to audit connection attempts, security negotiation, configuration changes and rejected sessions, and Part 2 clause 6.11 asks for audit events to be protected and persisted. Forward these events to the OT monitoring platform or SIEM.

• Watch for: new certificates appearing in rejected folders (a new or rogue client), sessions using mode None or deprecated policies, anonymous sessions writing values, TrustList or certificate changes outside change windows, BadCertificate and BadSecurityChecksFailed bursts, browse-heavy sessions from unusual hosts (server profiling), and connection floods.

Threats and framework mapping

Common failure patterns

• Mode None left on "for one legacy client": the insecure endpoint stays for years and every new client uses it because it is easiest. The BSI's 2015 analysis found its reference implementation issue was exploitable precisely when security functions were disabled.
• Auto-accepting certificates: enabling "trust all" during commissioning and never turning it off means any machine on the network can open a SecureChannel.
• Shared engineering credentials: one operator account used by HMIs, historians and integrators. INCONTROLLER's OPC UA module connected with default or previously compromised credentials, then read the address space and could write tag values. See the PIPEDREAM ICS Toolkit Guide.
• Certificates that expire silently: ten-year self-signed certificates on some devices and one-year CA certificates on others, with no inventory, lead to sudden line stoppages and pressure to fall back to None. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
• Unpatched embedded stacks: OPC UA SDKs are embedded in PLCs, gateways and software. OPC Foundation advisories include CVE-2024-42513 (authentication bypass via HTTPS in the .NET Standard stack) and an October 2026 .NET Standard stack update for uncontrolled resource consumption from malformed messages; products only become safe when their vendors ship the fixed SDK.
• PubSub groups that are too wide: one SecurityGroup for a whole plant means any publisher's key compromise lets an attacker publish as any other.

Lessons from incidents

The clearest public case is the PIPEDREAM or INCONTROLLER toolkit described in CISA advisory AA22-103A (April 2022), which targeted Schneider Electric and OMRON controllers and OPC UA servers. CISA said the OPC UA threat could be significantly reduced by properly configuring OPC UA security, and recommended application authentication with explicit trust lists, securely stored private keys and passwords, isolation of ICS networks and connections only from approved engineering workstations. The OPC Foundation's 2026 specification advisories add a further lesson: several issues require a stolen client or server private key, so private key protection and revocation are what keep a specification-level weakness theoretical.

Practitioner checklist

• Inventory every OPC UA server and client with endpoints, modes, policies, token types, SDK version and certificate expiry.
• Remove mode None and the deprecated Basic128Rsa15 and Basic256 policies from production endpoints.
• Set clients to a specific secure endpoint, never "best available".
• Turn off certificate auto-accept and manage trust lists explicitly, preferably through a CA or GDS with CRLs.
• Give every client application its own certificate and protect its private key; never share one between machines.
• Disable anonymous write access and map users to Roles and node Permissions.
• Restrict SecurityAdmin, CertificateAuthorityAdmin and RegistrationAuthorityAdmin to named, privileged administrators.
• Forward OPC UA audit events and alert on rejected certificates, insecure sessions and trust list changes.
• Subscribe to the OPC Foundation security advisories and vendor PSIRTs and track SDK versions per product.

Standards and references

• OPC Foundation: OPC 10000-2 OPC UA Part 2 Security Model
• OPC Foundation: OPC 10000-12 OPC UA Part 12 Discovery and Global Services
• OPC Foundation: OPC Security Advisories
• CISA: AA22-103A APT Cyber Tools Targeting ICS/SCADA Devices
• BSI: OPC UA Security Analysis
• MITRE ATT&CK: INCONTROLLER
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Industrial IoT (IIoT) Security Guide · OT and ICS Identity and Access Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Modbus TCP and Modbus Security Guide