Global Discovery Server
In OPC UA, a Global Discovery Server is the Part 12 infrastructure server that holds an enterprise-wide register of applications and acts as their certificate authority. It issues application instance certificates, distributes trust lists and CRLs, and is the answer to PKI at fleet scale. It advertises the capability code GDS.
Two jobs, often confused with a third
A GDS does registration and discovery across a whole site or enterprise, and it does certificate management. It is not a Local Discovery Server: an LDS is a small per-host service that owns port 4840 and answers FindServers, RegisterServer and FindServersOnNetwork for the servers on that machine, advertising the Local Discovery Server 2017 facet. LDS is per host, GDS is per site, and a deployment can have both.
Pull and push certificate management
In the pull model the device asks: it requests a certificate group, submits a signing request or asks for a new key pair, and collects the issued certificate and trust list. In the push model the GDS writes to the device, using the ServerConfiguration object and its TrustList object in the device's own address space. Pull suits devices that can reach out; push suits devices that cannot, and requires the device to expose the configuration model. Both handle RSA and ECC certificate types, CRLs and sub-CA revocation.
The two services people miss
Part 12 also defines a KeyCredentialService, which issues credentials for services that are not OPC UA at all - an MQTT broker, a REST API - so a device can get its broker credentials through the same trusted channel as its certificate. And an AuthorizationService, which issues access tokens in an OAuth2-shaped flow with StartRequestToken and FinishRequestToken. Together with the Security Key Service for PubSub group keys, that makes the GDS the natural single place where machine identity lives.
What to expect in the field
The specification is mature and implementations exist, including in the reference stack samples, but a GDS is real infrastructure with a real CA behind it and it is not a weekend task. Most plants are still on hand-managed trust lists or a small internal CA. The pragmatic staging is: self-signed on the bench, an internal CA with the issuer store for a line, a GDS when device count and turnover make manual trust management the bottleneck.
Example
Which mechanism handles which problem
LDS (per host, port 4840) FindServers, RegisterServer, FindServersOnNetwork
capability code: LDS
GDS (per site) application register + certificate authority
pull device -> GDS request certificate group, submit CSR, fetch cert + trust list
push GDS -> device write via ServerConfiguration / TrustList in the device address space
also KeyCredentialService credentials for non-OPC-UA services (MQTT broker, REST)
AuthorizationService access tokens, StartRequestToken / FinishRequestToken
capability code: GDS
SKS (PubSub) symmetric group keys per SecurityGroupId
capability code: SKSDefined in: Part 12 - Discovery and Global Services.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.