Certificate push vs pull

Pull: the device is the client

The device connects out to the GDS certificate directory and drives the process: it lists its certificate groups, then either submits a signing request for a key pair it generated itself or asks the GDS to generate a new key pair, then collects the issued certificate along with the trust list and CRLs. The private key never has to leave the device if you use the signing-request variant, which is the better hygiene. Pull needs the device to be able to reach the GDS and to have a client stack.

Push: the device is the server

Push inverts it. The device exposes a ServerConfiguration object with methods such as CreateSigningRequest, UpdateCertificate and GetRejectedList, and a TrustList object that is written as a file and committed with CloseAndUpdate. An administration tool or the GDS connects in as a client with the SecurityAdmin role and installs the new certificate and trust list. No outbound connectivity is needed, which suits a device on an isolated cell network.

Which one you can actually use

This is decided by the device, not by you. Push requires the server to implement the ServerConfiguration and TrustList objects, and most PLCs and embedded servers do not - the failure mode is simply a method that is not there. Pull requires a client stack and outbound reach to the GDS, which many embedded servers also lack. Survey what each device family supports before designing the provisioning process, and confirm it with the vendor rather than assuming from a feature list.

The operational difference that matters

Push is a change made to a running device and takes effect by restarting the endpoints, so it interrupts sessions - schedule it. Pull is initiated by the device and fits naturally into a startup or renewal timer, which makes automated rotation feasible. Whichever you use, remember that installing a new certificate is only half the job: every peer's trust list has to accept the new issuer, and if you changed CA rather than just renewing, that is a fleet-wide operation.

Example

The two flows, and where the private key lives in each

PULL   device --(client)--> GDS CertificateDirectory
         GetCertificateGroups
         StartSigningRequest      # device keeps its private key
           or StartNewKeyPairRequest   # GDS generates the key - it travels to the device
         FinishRequest -> certificate + issuer certs
         GetTrustList  -> trusted list + CRLs

PUSH   admin/GDS --(client)--> device ServerConfiguration
         CreateSigningRequest     # device keeps its private key
         UpdateCertificate        # install the signed certificate
         TrustList: Open / Write / CloseAndUpdate
         GetRejectedList          # read what the device refused
       -> endpoints restart, existing sessions drop

Defined in: Part 12 - Discovery and Global Services, certificate management.

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.