TwinCAT OPC UA Certificate Rollout: Treat GDS Enrollment as a SCADA Change

Enrolling a TwinCAT OPC UA server with a Global Discovery Server
changes the certificate-management relationship behind a SCADA
connection. Registration success does not prove that the intended
certificate has been issued, that revocation information is available,
or that every existing SCADA client will accept the resulting server
identity.

Use a planned certificate rollout with separate acceptance conditions
for those outcomes. This discussion pins the TF6100 server manual
version 1.6.0, dated 2 September 2026, and distinguishes its
implementation from OPC UA Part 12 v1.05.07. No certificate, trust list,
credential or running server was changed.

Original certificate-rollout model. It represents required evidence,
not an executed enrollment or a guaranteed interruption duration.

Choose
the management relationship before the maintenance window

TwinCAT supports GDS Push and Pull models. In Push, a capable
administrative client works on behalf of the server; the vendor requires
an account with administrator rights on that server. In Pull, the server
contacts the GDS itself. TwinCAT
GDS overview and Push requirements, Push.

The choice determines which component needs approved connectivity and
authority. Document that owner, the intended certificate issuer and the
SCADA applications affected by the change. Do not let an engineering
workstation become an undocumented permanent dependency simply because
it was convenient during commissioning.

The maintenance scope should distinguish the server’s application
certificate from user authentication. Replacing the former does not
automatically authorize a different SCADA user, change that user’s
permissions or justify relaxing endpoint security.

Track
enrollment, issuance and revocation information separately

In TwinCAT’s Pull flow, registration requests a certificate, but the
GDS may require administrator approval before issuing it. Beckhoff
exposes RegistrationState, CertificateState and CrlState as separate
observations. After registration and receipt of the certificate, the
server reinitializes its endpoints, temporarily interrupting connected
clients. GDS
Pull behavior

An acceptance record therefore needs more than a successful Register
operation. Identify the issued certificate, its intended application and
validity period; establish the relevant revocation-information state;
then verify the deployed server endpoint through an authorized
client.

For each SCADA consumer, determine the trust relationship its
configured certificate store actually establishes. A client that trusted
the previous certificate is not automatically evidence that the
replacement is acceptable. Preserve normal validation and review the
intended issuer chain or application-certificate trust explicitly.

The TF6100
manual, certificate exchange section requires mutual client/server
trust for secure communication. It is the newly deployed relationship,
rather than the historical fact that the old connection worked, that the
rollout must establish.

Separate initial
activation from later renewal

The documented endpoint reinitialization above belongs to the
enrollment-and-certificate-receipt sequence. Do not turn that statement
into a universal duration or behavior for every later renewal.

TwinCAT also documents an on-demand certificate-update request and
separate certificate-check and CRL-update intervals. Those settings
define maintenance activity; they are not a complete client-cutover
guarantee. Confirm the deployed version’s renewal behavior in a
controlled qualification before relying on unattended renewal across
production SCADA clients.

OPC UA Part 12’s ApplyChanges
definition explains that changed certificates or trust lists can
require affected channels to renegotiate; implementations can also shut
down more broadly. This is a standards-level boundary, not evidence that
TwinCAT implements every v1.05.07 transaction feature. Do not mix a
vendor’s GDS request method with a similarly named standard method
without checking its object and signature.

Define completion at
the SCADA consumer

During an approved maintenance fixture, observe the certificate
activation, connection interruption where applicable, validated
reconnection and resumption of the required monitored data. Keep
certificate rejection distinct from a network failure or a
user-permission failure. Never accept an invalid certificate merely to
make the recovery indicator green.

The release record should identify which clients passed, which remain
pending and which certificate each accepted. It should also identify the
owner of future renewal and revocation checks. That makes certificate
management part of the industrial integration contract rather than a
one-time registration screen that nobody revisits.