OPC UA Security Archives

In the previous article, "OPC UA Discovery Explained: Understanding LDS and GDS," we introduced the role of discovery services in OPC UA and compared the Local Discovery Server (LDS) with the Global Discovery Server (GDS). While the LDS mainly focuses on discovering OPC UA servers running on a single machine, GDS provides centralized management of OPC UA applications across an enterprise while automating certificate lifecycle management, which is one of the most challenging aspects of industrial cybersecurity. For organizations operating dozens or even hundreds of OPC UA clients and servers, manually managing certificates quickly becomes impractical. GDS was introduced by the OPC Foundation to solve this problem by providing a scalable, standardized approach to application discovery and trust management. In this article, we explore how GDS works, why it matters, and how it simplifies secure OPC UA deployments. Why Certificate Management Matters Unlike OPC Classic, OPC UA was designed with security built into the protocol itself. Every OPC UA application, whether a client or a server, uses an Application Instance Certificate to establish its identity. When two OPC UA applications communicate, they must verify each other's certificates before creating a secure channel. For a small system with only a few devices, exchanging certificates manually may be manageable. Now imagine an enterprise with: 100 PLCs exposing OPC UA servers 10 SCADA servers Multiple historians MES applications Cloud gateways Edge computing platforms Engineering workstations Third-party OPC UA clients Without centralized management: Every client must trust every server. Every server must trust every client. New applications require manual certificate distribution. Expired certificates interrupt communications. Revoking compromised certificates becomes a manual process. As deployments grow, certificate management becomes one of the largest maintenance burdens. What Is an OPC UA Global Discovery Server? The Global Discovery Server (GDS) is a centralized OPC UA server service, defined by the OPC Foundation n in Part 12, that manages both application discovery and certificate lifecycle management across an OPC UA environment. Think of it as the administrative control center for your OPC UA ecosystem. GDS enables organizations to: Register OPC UA applications Discover applications across the enterprise Issue application certificates Renew certificates Revoke certificates Manage trust lists Distribute trusted certificates Automate certificate enrollment Rather than manually configuring trust relationships between every client and server, applications interact with the GDS to obtain the information they need. The Two Primary Responsibilities of a GDS Although the GDS performs several functions, the 2 major categories are: 1. Enterprise Application Discovery The GDS maintains a centralized registry of OPC UA applications. Applications can register information such as application name, application URI, product URI, discovery URL, endpoint URLs, supported security policies and transport profiles. This allows OPC UA client applications to locate available OPC UA servers throughout an organization without maintaining manual endpoint lists. For a deeper look at how this discovery mechanism works alongside the Local Discovery Server, see our related article: OPC UA Discovery Explained: Understanding LDS and GDS 2. Certificate Lifecycle Management The second role of the GDS is managing the complete lifecycle of OPC UA application certificates. This includes certificate enrollment, certificate issuance, certificate renewal, trust list distribution, certificate revocation and certificate replacement. For large deployments, this dramatically reduces engineering and maintenance efforts while improving security. Understanding the Certificate Lifecycle Every OPC UA application follows a lifecycle similar to the one below. Figure 1: Certificate Lifecycle Without a GDS, most of these steps require manual intervention. With a GDS, they can be automated. Certificate Enrollment When a new OPC UA application is installed, it first needs an application certificate. Instead of generating and distributing certificates manually, the application can submit a certificate signing request (CSR) to the GDS. The GDS verifies the request according to the organization's policies and issues a signed certificate. This process ensures: Consistent certificate policies Trusted certificate issuance Reduced manual configuration Faster deployment of new applications Trust Lists One of the most time-consuming aspects of OPC UA security is maintaining trust relationships. Each OPC UA application maintains a trust list, which contains certificates it considers trustworthy. Without centralized management, administrators must manually copy certificates between every client and server. As systems grow, this quickly becomes unmanageable. GDS solves this by maintaining centralized trust lists that can include: Trusted Certificate Authorities (CAs) Trusted application certificates Issuer certificates Certificate Revocation Lists (CRLs) Applications periodically synchronize their trust stores with GDS, ensuring they always have the latest trusted certificates and revocation information. Automatic Certificate Renewal Certificates have finite validity periods. If a certificate expires, secure communication may fail until a replacement certificate is installed. Manual renewal introduces several risks such as unexpected communication failures, production downtime, forgotten renewal dates and human error during replacement. GDS can automate this process by: Monitoring certificate expiration dates. Generating replacement certificates before expiration. Delivering the new certificates to applications. Updating trust lists automatically. Automation helps maintain continuous operation while reducing administrative overhead. Push and Pull Certificate Management The OPC UA specification, Part 12, defines two models for how a GDS delivers certificates and trust list updates to applications: Push Management - the GDS pushes new certificates and updated trust lists directly to a running server or client. This requires the connecting client to hold the SecurityAdmin role over an encrypted channel, and the GDS will only deliver an update over a channel at least as strong as the certificate being installed. It will not push a 4096-bit certificate down a connection secured with a weaker policy. Pull Management - the application periodically connects to the GDS and requests (pulls) certificate and trust list updates on its own schedule. In practice, server applications more commonly use Push, since they can expose the methods needed to receive updates, while client applications more commonly use Pull. Certificate Revocation Sometimes certificates must be invalidated before they expire. Common reasons include: A device has been decommissioned. A private key has been compromised. An application has been replaced. Unauthorized software has been detected. Rather than waiting for the certificate to expire naturally, administrators can revoke it. GDS updates its Certificate Revocation List (CRL), and applications receive the updated revocation information during trust list synchronization. This helps prevent compromised applications from participating in secure communications. Acting as a Certificate Authority A GDS implementation can operate as a Certificate Authority (CA) or integrate with an existing CA. As a CA, GDS can: Issue certificates Sign certificate requests Renew certificates Revoke certificates Publish CRLs It is worth noting that dedicated, production-ready GDS products are still relatively limited compared to the broader PKI market. Many organizations today rely on reference implementations, vendor-specific GDS features built into PLC or SCADA platforms, or integration with an external CA rather than a standalone, full-featured GDS product. Organizations should verify the capabilities of their chosen GDS implementation, as features can vary significantly between vendors. Integrating with Enterprise PKI Many organizations already operate a Public Key Infrastructure (PKI), often based on solutions such as Microsoft Active Directory Certificate Services (AD CS). Rather than replacing the existing PKI, a GDS can often integrate with it. A common architecture looks like this: Figure 2: Integrating OPC UA GDS with Enterprise PKI In this model: The enterprise PKI remains the root of trust. GDS manages OPC UA application certificates. Corporate certificate policies continue to apply. Certificate enrollment becomes automated. This approach aligns industrial security with enterprise IT governance. Benefits of Using a GDS Implementing a GDS provides several important advantages. Improved Security Centralized certificate management reduces inconsistent trust configurations and helps ensure that only authorized applications participate in OPC UA communications. Reduced Administrative/Maintenance Overhead Administrators manage certificates from a central location rather than configuring trust individually on every client and server. Simplified Deployment New OPC UA applications can automatically: Register with GDS Request certificates Receive trust lists Join the existing security infrastructure This significantly accelerates commissioning. Consistent Security Policies Organizations can enforce standardized certificate lifetimes, signing algorithms, and trust policies across all OPC UA applications. Better Scalability The larger the deployment, the greater the benefits of centralized certificate lifecycle management. When Should You Deploy a GDS? GDS is especially valuable when: Managing dozens or hundreds of OPC UA applications Operating multiple production sites Integrating OT with enterprise IT Implementing Industrial IoT architectures Connecting cloud platforms Supporting multiple engineering teams Enforcing centralized cybersecurity policies Small standalone systems may not require a GDS, but enterprise deployments typically benefit significantly from its capabilities. GDS in Practice GDS support is picking up and appearing as a built-in capability in industrial software platforms rather than requiring a separate standalone product. For example, recent PLC platforms have added native "GDS Push" toggles that let an external GDS manage a server's certificate and trust list automatically once enabled. This is turning what used to be a manual, per-application configuration step into a centrally managed one. This trend reflects the direction GDS adoption is heading: less a bolt-on tool, and more a standard feature of the platforms already running on the plant floor. Implementation Best Practices for GDS Deployments Integrate with your enterprise PKI whenever practical. Protect the GDS using strong authentication and role-based access control. The GDS holds privileged access to your entire certificate infrastructure, so it should be treated as a Tier-0 security asset, not a general-purpose server. Monitor certificate expiration proactively. Maintain a local rejected-certificate log on each OPC UA application even when using a GDS. Centralized trust management should not remove your ability to see and investigate what tried to connect at the individual application level. This local visibility is what lets you identify a misconfigured or unauthorized device quickly. Audit certificate issuance and revocation events, and forward those logs to your SIEM or central logging platform rather than leaving them only on the GDS. Test certificate renewal procedures before production deployment. Consider redundant GDS instances for high-availability . Keep GDS software updated to address security vulnerabilities and maintain compatibility with evolving OPC UA specifications. Plan for crypto agility by choosing a GDS and PKI architecture that can move beyond current algorithms (e.g., RSA-based suites) toward newer, stronger options as OPC UA security policy recommendations evolve, rather than hard-coding today's algorithms into your infrastructure. Frequently Asked Questions