At 02:14 on a Tuesday, a pharmaceutical filling line stops. No alarm, no fault light — the PLC is running, the drives are enabled, the sensors are reporting. What died was the OPC UA session between the line controller and the site MES. The certificate on the controller expired at midnight UTC. The MES server, configured to reject connections with expired certificates, dropped the session. The line was down for three hours while a controls engineer, a network administrator, and a security analyst sorted out who was authorized to sign a new certificate — and how.
This is not a hypothetical. Certificate expiry is the single largest cause of unplanned OPC UA session loss in production environments. The technology for managing certificates exists. What is missing in most deployments is a process.
Why does OPC UA rely on X.509 certificates at all?
OPC UA was designed from the ground up with security embedded in the protocol, not bolted on as a tunnel or wrapper. Every OPC UA application instance — every server, every client, every discovery server — has a unique X.509 digital certificate and an associated private key. Before two OPC UA applications can exchange data, they must mutually authenticate using these certificates, establish an encrypted channel, and authorize the level of access. This is not optional: an OPC UA client and server without valid, mutually trusted certificates cannot form a session. In industrial communication networks where OPC UA connects the plant floor to higher-level systems, certificate trust is the foundation on which all data exchange rests.
What makes certificate management hard at production scale?
A medium-sized plant with 40 machines, each running an OPC UA server, plus 8 client applications (MES, historian, batch manager, OEE dashboard, maintenance scheduler, energy monitor, quality lab, and a remote-access gateway) has 320 trust relationships. Each certificate has a finite validity period — typically 2–5 years. Each certificate must be issued by a Certificate Authority (CA) that all parties trust. When a certificate is renewed, the new certificate must be distributed to every application that trusts the old one before the old one expires. Miss one distribution, and that application loses its connection. At scale across a multi-line facility, the number of certificate expiry dates that a plant must track equals the number of OPC UA application instances — and it grows with every new machine.
The GDS approach: centralized certificate lifecycle automation
The OPC Foundation addressed this with the Global Discovery Server (GDS) and Certificate Management service, defined in OPC UA Part 12. A GDS acts as the central certificate authority for an OPC UA deployment. It provisions initial application certificates (replacing self-signed certificates with CA-signed ones), pushes renewed certificates to applications before expiry, maintains the trust list that defines which certificates are trusted across the plant, and revokes compromised certificates. With a GDS, a plant administrator approves a certificate renewal once; the GDS handles distribution to every application in the trust network. Without a GDS, each renewal requires manual file transfer to every client that trusts that server — a task that grows O(n²) with the number of applications.
Push vs pull: two modes of certificate distribution
The GDS supports two distribution models. In push mode, the GDS actively connects to each OPC UA application and writes the new certificate to its trust store — this requires each application to expose the ServerConfiguration node and accept write access from the GDS. In pull mode, each application periodically polls the GDS for certificate updates — this is simpler to deploy behind firewalls and NAT boundaries but introduces a polling lag during which the old and new certificates may overlap. A robust deployment uses push for always-online applications (servers, HMIs) and pull for intermittently connected clients (laptops, portable diagnostic tools).
The Honeywell ControlEdge PLC integrates universal I/O with native OPC UA server functionality — the kind of controller where certificate lifecycle management directly impacts production uptime.
What happens when you ignore certificate expiry?
When an OPC UA certificate expires, the behavior depends on the receiving application's configuration. In strict mode, the connection is rejected immediately — the server or client sees an untrusted certificate and closes the secure channel. In lenient mode, the application emits a warning but allows the connection, which is operationally forgiving but defeats the purpose of certificate-based security. Most production sites configure strict mode, because the alternative means an attacker with a compromised, expired certificate could still establish a session. The paradoxical result: the more security-conscious the plant, the more vulnerable it is to a certificate-expiry outage. The fix is not to weaken the security configuration; it is to manage the certificates.
What a minimal certificate management process looks like
For plants without a GDS, the minimum viable process is: maintain a central inventory of every OPC UA application instance and its certificate expiry date (an Excel sheet works for under 50 instances); set a renewal trigger 90 days before expiry; generate the new certificate from the plant CA; distribute the new certificate to every trust store that references the old one; verify connectivity before the old certificate expires; and revoke the old certificate once all sessions are established with the new one. The weak link in this manual chain is step 4 — distribution — and that is precisely the step a GDS automates.
Can you run OPC UA without certificates?
Yes — OPC UA defines a "None" security policy that disables authentication and encryption. It exists for testing and for air-gapped, physically secured networks where certificate management overhead is deemed unnecessary. A machine network inside a locked enclosure with no external connectivity is a valid use case for None security. But any OPC UA traffic that crosses a network boundary — from a machine cell to a plant network, from a plant network to a corporate LAN, or (especially) from an Edge gateway to a cloud application — must use signed and encrypted sessions. Certificates are the price of crossing that boundary.
OPC UA certificate management is not a cybersecurity project. It is an automation reliability project with a security component. When a certificate expires and a production line stops, the root cause is not a security breach — it is a gap in the plant's lifecycle management process for the digital identities its automation systems depend on. Whether managed through a GDS or a manual process, certificate expiry tracking is as essential to production uptime as pressure transmitter calibration or VFD capacitor replacement.
