What is an OPC UA GDS? Certificate management explained

OPC UA is one of the few industrial protocols where security is mandatory, not optional. Every connection requires X.509 certificates for authentication and encryption. That's excellent for security — and a nightmare for operations when you have 50, 500, or 5,000 devices.

How do you issue certificates? How do you renew them before they expire? How do you revoke a compromised device? How do you distribute trust lists across hundreds of servers?

The answer is the Global Discovery Server (GDS).

The problem: certificate management at scale

In a small OPC UA deployment — say, two servers and five clients — you can manage certificates manually. Generate a self-signed cert for each application, copy it to the trusted folder of every peer, and you're done.

Now scale that to a factory floor with 200 OPC UA servers, 50 clients, and 30 gateways. Every time you add a device, you need to distribute its certificate to every application that should trust it. Every time a certificate expires (typically every 1–2 years), you need to renew it and redistribute the new one. Every time a device is decommissioned, you need to remove its certificate from every trust store.

The math is brutal. With n applications, you have up to n×(n−1) trust relationships to manage. At 200 devices, that's nearly 40,000 potential certificate operations.

Nobody does this manually. And if they try, they end up disabling security entirely — which is exactly what attackers count on.

What is a GDS?

The Global Discovery Server is defined in OPC UA Part 12: Discovery and Global Services. It serves three functions:

1. Server registry

The GDS maintains a central list of all OPC UA servers and clients in the network. Applications register themselves with the GDS when they start, and other applications can query the GDS to discover available servers — similar to DNS for the web.

2. Certificate authority (CA)

The GDS acts as a Certificate Authority. It can issue, renew, and revoke X.509 certificates for OPC UA applications. Instead of each device generating its own self-signed certificate, the GDS issues certificates signed by a common CA — establishing a chain of trust across the entire deployment.

3. Trust list manager

The GDS manages trust lists centrally. When you trust a new device, you update the GDS once. The GDS then distributes the updated trust list to all applications — automatically. No manual copying of certificates between machines.

How it works: Push and Pull

OPC UA Part 12 defines two models for certificate management:

GDS Pull model. Applications periodically contact the GDS to check for updated trust lists and new certificates. This is simpler to implement but introduces a delay — devices only pick up changes on their next polling cycle.

GDS Push model. The GDS proactively pushes certificates and trust lists to applications. This is more responsive — changes take effect immediately — but requires the GDS to maintain a connection to every managed application.

In practice, most deployments use a combination: Push for critical updates (certificate revocation) and Pull for routine operations (trust list sync).

The certificate lifecycle

A GDS manages the full certificate lifecycle:

Enrollment. A new device joins the network and requests a certificate from the GDS. The GDS verifies the request (typically by checking a pre-shared registration token), generates a signed certificate, and returns it to the device.

Distribution. The GDS adds the new device's certificate to the trust lists of all applications that should communicate with it. Those applications receive the updated trust list via Push or Pull.

Renewal. Before a certificate expires, the GDS generates a new one and distributes it. The old certificate remains valid during a transition period to avoid service interruptions.

Revocation. When a device is compromised or decommissioned, the GDS revokes its certificate and publishes an updated Certificate Revocation List (CRL). All applications that trust the GDS CA will reject the revoked certificate on their next connection attempt.

Why you need a GDS

Compliance

The Cyber Resilience Act (CRA) and IEC 62443 require documented, auditable security practices. A GDS provides centralized certificate management with full logging — exactly what auditors want to see. Managing certificates manually with screenshots and spreadsheets does not pass a serious audit.

Operational sanity

Without a GDS, certificate renewal is a ticking time bomb. When a certificate expires, the connection fails silently. In a factory with hundreds of devices, expired certificates cause random communication failures that are extremely difficult to diagnose.

A GDS tracks expiry dates centrally and renews certificates automatically — before they expire.

Zero-touch provisioning

With a GDS, adding a new device to the network is a single registration step. The GDS issues the certificate, distributes the trust list, and the device is operational. Without a GDS, adding a device means manually copying certificates to every application that needs to trust it.

Architecture patterns

Small deployment (< 50 devices)

A single GDS instance manages all certificates. The GDS runs on the same machine as your engineering workstation or edge server. Pull model is sufficient.

Medium deployment (50–500 devices)

A dedicated GDS server with Push capability. The GDS runs on a hardened machine with backup. Certificates are backed up and the CA private key is stored securely (ideally in an HSM or at minimum in a secure key store).

Large deployment (500+ devices)

Hierarchical GDS architecture. A root CA GDS issues intermediate CA certificates to zone-level GDS instances. Each zone GDS manages the devices in its area. This limits the blast radius if a zone GDS is compromised and reduces network traffic.

Common mistakes

Disabling security. The most common "solution" to certificate management pain is to disable OPC UA security entirely. This bypasses the GDS problem — and opens the door to man-in-the-middle attacks, data tampering, and unauthorized access.

Using self-signed certificates everywhere. Self-signed certificates work for development but create an unmanageable web of trust at scale. Every device trusts itself, and every peer must explicitly trust every device. A GDS with a proper CA eliminates this by establishing a single chain of trust.

Ignoring certificate expiry. Certificates expire. If you don't track and renew them proactively, your OPC UA connections will fail. A GDS automates this.

Key takeaways

1. A GDS is the centralized certificate authority and server registry for OPC UA networks.
2. It solves the n×m trust management problem that makes manual certificate management impossible at scale.
3. It supports Push and Pull models for distributing certificates and trust lists.
4. It is required for compliance with IEC 62443 and the CRA.
5. Without a GDS, teams either spend excessive time on manual certificate management — or disable security entirely.

Go deeper: download the whitepaper

This article covers the fundamentals. For a deeper dive into GDS architecture, PKI design patterns, HSM integration, and IEC 62443 compliance mapping, download our technical whitepaper.

References

1. OPC Foundation — OPC UA Part 12: Discovery and Global Services. opcfoundation.org
2. OPC Foundation — OPC UA Part 4: Services (SecurityPolicy). opcfoundation.org
3. IEC 62443 — Industrial communication networks – Network and system security. iec.ch
4. European Commission — Cyber Resilience Act (CRA). digital-strategy.ec.europa.eu

Sterfive builds OPC UA GDS — a production-ready Global Discovery Server that integrates with your existing PKI infrastructure. If you're planning a secure OPC UA deployment, talk to our engineers.