OPC UA's security model is built on X.509 certificates: every application instance has an application certificate, and trust is expressed by which certificates are installed in each application's trust store. This design is robust — but it puts the burden of certificate lifecycle management on the integrator. In a plant with dozens of clients and servers, manual certificate handling becomes the dominant OPC UA operations cost. The standard's answer is the Global Discovery Server (GDS) with certificate push management, defined in OPC 10000-12 (Discovery) and OPC 10000-21 (Part 21: GDS).
How Trust Works in OPC UA
When two OPC UA applications connect with security enabled:
- Each side presents its application certificate during the handshake.
- Each side validates the peer's certificate: signature chain, validity period, and — crucially — membership in the local trust store (trusted list or trusted issuer CA).
- If validation fails, the connection is rejected unless the receiving side has an explicit exception (e.g., trust-on-first-use is enabled in that application).
The trust model supports two styles:
- Direct trust — each peer's exact certificate is in the trusted list (simple, brittle: every renewal touches every peer).
- CA-based trust — applications trust the CA (or intermediate) that issues peer certificates (scalable: renewals work without touching peers, as long as the CA stays valid).
CA-based trust is the right architecture for anything beyond a handful of permanently installed applications.
Certificate Lifecycle in Practice
An application certificate has a lifecycle that someone must operate:
- Creation — generated with a proper key length (RSA 2048/3072 or ECC P-256), a meaningful subject, and a SubjectAltName URI matching the server's endpoint hostname.
- Distribution — the certificate is exported to every peer's trust store (and the CA certificate to trusted-issuer stores).
- Renewal — before expiry (or immediately after key compromise), a new certificate is issued; with CA-based trust, distribution is limited to updating the application instance itself.
- Revocation — for compromised keys, the CA publishes a CRL; applications supporting revocation check it — enable and test this, most deployments never do.
- Retirement — remove expired certificates from trust stores; accumulated dead certificates silently broaden trust.
The GDS and Push Management
The GDS centralizes these operations. It provides:
- Discovery — applications register with the GDS; clients can query "which servers are available?" (LDAP-style and OPC UA style registration).
- Certificate management — the GDS issues certificates from a configured CA on behalf of applications (with offline approval workflow), and distributes trust lists.
- Push management (Part 21) — the GDS pushes updated certificates and trust lists to registered applications over a secure channel, so a plant-wide trust update is one operation instead of a maintenance window per machine.
Deploying a GDS (e.g., the OPC Foundation's reference GDS, or vendor implementations integrated into Kepware, Ignition, and platform products) requires planning: the GDS itself is a high-value target, so it belongs in its own security zone with strong access control and auditing.
Practical Deployment Guidance
- Start with a clear trust policy: what is allowed to connect, from where, and with which security policy (minimum: Basic256Sha256; prefer the newer Aes128Sha256RsaOaep where supported).
- Use CA-based trust wherever the software supports it; keep direct trust only for legacy devices that cannot be updated.
- Give every application a certificate with a stable identity: hostname/URI, role, and owner in the subject fields.
- Automate renewal with a GDS or a scheduled certificate task; track expiry dates in the asset register — expired certificates are the #1 cause of mystery connection failures after maintenance windows.
- Enable and test revocation, at least for the CA you control.
- Document the trust topology (who trusts whom, which CA issues what) as a diagram in the OT documentation set, and review it annually.
Summary
OPC UA security is only as good as the certificate lifecycle behind it. Design for CA-based trust, operate the lifecycle deliberately (create, distribute, renew, revoke, retire), and centralize with a GDS when the fleet grows beyond manual reach. Certificates are not an IT nuisance — they are the access control mechanism of the OT data plane, and they deserve the same rigor as passwords.