Technical Specification & Reference Guide

OPC UA Global Discovery Server (GDS)

GDScout fulfills the ten core functionalities of a fully developed OPC UA Global Discovery Server (GDS) as defined by OPC UA Part 12 (Discovery and Global Services) and Part 2 (Security Model). This section provides technical guidance for automation architects, OT security engineers, and system integrators deploying centralized security and discovery services across industrial facilities.

Centralized Certificate Lifecycle Management

Functional Scope: Replaces manual, decentralized certificate exchanges with a central Certificate Authority (CA) framework that manages the complete security lifecycle of all registered OPC UA clients and servers within an administrative domain.

Lifecycle Phases Covered:

Renewal: Reissuing signed certificates prior to expiration without requiring manual intervention on physical devices.

Revocation: Neutralizing compromised or decommissioned devices immediately across the entire network.

Operational Mechanisms:

Automated Certificate Rotation

Expiration Monitoring: The GDS continuously tracks the validity periods of all registered application certificates. Using methods such as GetCertificateStatus and CertificateExpired alarms, the GDS detects when a certificate approaches its configured renewal threshold.

Proactive Renewal Sequence: Prior to expiration, the GDS initiates an automated renewal workflow. In Pull mode, the client application queries the GDS and submits a Certificate Signing Request (CSR) via StartSigningRequest. In Push mode, the GDS generates or requests the updated certificate and pushes it directly down to the server at runtime without requiring controller restarts.

Security Benefits: Automating certificate rotation allows facilities to adopt short validity periods (e.g., weeks or months instead of 10–20 years), drastically reducing the exploitation window if a private key is ever compromised. Furthermore, it eliminates unplanned production outages caused by unexpected certificate expiration.

Trust List and Certificate Revocation List (CRL) Management

Trust List Distribution: The GDScout maintains and distributes TrustList objects containing trusted root CA certificates, intermediate issuer certificates, and explicitly trusted application certificates across the domain.

CRL Maintenance & Instant Revocation: When a maintenance laptop is misplaced, a sensor is compromised, or a device is decommissioned, an administrator revokes its certificate at the GDScout. The GDScout immediately updates its Certificate Revocation List (CRL) with the revoked certificate serial´s number.

Threat Neutralization: Updated trust lists and CRLs are pushed or pulled across all managed endpoints. During secure connection establishment, receiving devices evaluate the sender´s certificate against the trusted CA chain and the latest CRL. If a certificate appears on the CRL, the connection is instantly rejected.

Individual Certificates per Client and Server

Unique Cryptographic Identities: Each OPC UA application instance receives its own unique X.509 digital certificate containing its globally unique ApplicationURI, hostnames, and IP addresses.

Local Private Key Protection (CSR Workflow): Target devices generate their own private keys locally and submit a Certificate Signing Request (CSR) to the GDScout. This ensures that private keys never cross the network or leave the physical host, maintaining strict zero-trust storage.

Support for Multiple Certificate Types: A single application can be issued distinct certificates for different internal services, including ApplicationCertificateType (for OPC UA binary communications), HttpsCertificateType (for web server interfaces), UserCertificateType (for user authentication), and TlsCertificateType (for transport security).

Group Certificate Management

Certificate Groups Structure: Defined in OPC UA Part 12 under CertificateGroupType objects within the CertificateGroupsFolder. Pre-defined standard groups include DefaultApplicationGroup, DefaultHttpsGroup, and DefaultUserTokenGroup.

Security Domain Segmentation: Allows administrators to organize devices into logical security groups based on physical or operational boundaries (e.g., machine cells, production lines, or plant halls).

Simplified Shared Trust: Devices assigned to the same Certificate Group share trust derived from the group`s specific CA certificate. All devices in the same group automatically trust one another without requiring manual 1-to-1 trust list exchanges.

Lightweight Directory Access Protocol (LDAP) Integration

Standardized Front-End Architecture: GDScout can act as an OPC UA-standardized front-end to existing enterprise directory services such as LDAP or Active Directory. Please contact our consultants if your use case needs this integration.

Protocol Translation: OPC UA clients perform standard OPC UA discovery calls (QueryApplications or FindApplications) against the GDScout address space. The GDScout translates these calls into standard LDAP attribute queries (mapping opcuaApplicationUri, opcuaApplicationType, and opcuaDiscoveryUrl).

Enterprise IT Alignment: Eliminates the need for industrial clients to support proprietary LDAP client libraries, allowing OT assets to be registered, searched, and managed directly within corporate IT Active Directory structures.

Local Discovery Service (LDS) Integration

Complementary Hierarchy: Local Discovery Servers (LDS) and Multicast Extensions (LDS-ME using mDNS) manage local server discovery within a single host or local subnet. The GDScout provides enterprise-wide discovery spanning multiple subnets and locations.

Auto-Population Workflow: GDScout can automatically discover new local servers by periodically calling FindServers or FindServersOnNetwork on registered LDS/LDS-ME instances across host machines.

Administrator Approval Gate: Records populated automatically via LDS/LDS-ME are placed in a pending state and must be approved by an administrator before becoming publicly visible in the GDScout registry or receiving signed certificates.

Web-Based Certificate Administration

Centralized Management Interfaces: GDScout’s comprehensive implementations feature dedicated web administration consoles and configuration dashboards for site administrators.

Operational Monitoring: Displays real-time status overviews, including registered application lists, pending onboarding requests, pending CSR signing requests, certificate expiration countdowns, and trust list synchronization statuses.

Auxiliary Certificate Handling: Manages and pushes secondary certificates for embedded device features, such as controller web server certificates (HTTPS), alongside standard OPC UA application certificates.

Diagnostics Logging of Certificate Lifecycle Events

Audit Event Framework: The GDScout integrates standardized audit event types to log all security-relevant lifecycle operations for compliance and troubleshooting.

Key Standard Audit Events:

Secure-by-Default Deployment in Windows Environments

Isolated Service Architecture: GDScout operates as an isolated background system service (e.g., Windows Service daemon) using restricted OS service accounts rather than interactive user sessions.

Mandatory Encrypted Channels: All client and administrator connections to the GDScout must use encrypted OPC UA channels (MessageSecurityMode set to SignAndEncrypt).

Role-Based Access Control (RBAC): Restricts administrative functions by enforcing strict roles (DiscoveryAdmin for registration, SecurityAdmin for CA operations). Runtime certificate rights are kept strictly separate from general OS user accounts.

Protected Key Storage: Local private keys and CA root certificates stored on the host file system or Windows Certificate Store are protected using strict OS access control lists (ACLs) or integrated Hardware Security Modules (HSMs).

GDScout Key Integrations

  1. Identity, Access Control & Directory Services

    1. Enterprise Directory Services (LDAP / Active Directory / UDDI)

      • Classification: Conditional Mandatory if exposing an external IT directory front-end (Optional for standalone GDS implementations)
      • Functionality: Translates standard OPC UA discovery methods (QueryApplications, FindApplications) into native Lightweight Directory Access Protocol (LDAP) attribute queries . This enables industrial assets to be registered, located, and managed directly within corporate Active Directory structures without requiring OT clients to support non-OPC UA protocols.
      • Audience:
        • Business: Connects plant-floor machinery directly to corporate IT asset management systems, reducing IT overhead.
        • Developer: Maps ApplicationRecordDataType fields (ApplicationUri, ApplicationName, DiscoveryUrls) to LDAP schema attributes
        • Security Engineer: Preserves IT directory boundaries by encapsulating queries behind an encrypted OPC UA channel (MessageSecurityMode:SignAndEncrypt)

      NOTE:We treat LDAP synchronization as a premium enterprise connector. Please reach out to our consultants in the contact section below for further information.

      Specification Grounding: OPC 10000-12, Clause 6.1 and Annex E (LDAP Mapping)

    2. Native GDS Access Control & OAuth2 / Access Tokens / JWT

      • Classification: Conditional (Mandatory for GDS deployments implementing Authorization Services under Part 12 Clause 9)
      • Functionality:Enforces session-level Role-Based Access Control (RBAC) across GDS address space methods. Restricts administrative actions (e.g., RegisterApplication, UpdateCertificate) to specific authenticated roles (DiscoveryAdmin, SecurityAdmin) or scoped privileges (ApplicationAdmin, ApplicationSelfAdmin) . Supports issuing and validating JSON Web Tokens (JWT) for user token authentication.
      • Audience:
        • Business: Ensures strict operational segregation, preventing unauthorized operators from changing device security settings.
        • Developer: Uses RequestAccessToken and GetServiceDescription methods to manage JSON Web Tokens.
        • Security Engineer: Prevents privilege escalation by verifying session identity against pre-assigned GDS NodeIDs and application boundaries.

      Specification Grounding:OPC 10000-12, Clause 6.2 (Table 1) and Clause 9 (Authorization Services)

    3. Key Credential & Broker Credential Management

      • Classification: Conditional (Mandatory when managing PubSub or MQTT secret distribution)
      • Functionality: Acts as a centralized secret vault for industrial brokers. Issues, rotates, and revokes passwords, shared keys, and OAuth secrets required by field nodes to publish/subscribe to cloud brokers or local messaging hubs.

      NOTE: We restrict this scope to X.509 PKI management. Please reach out to our consultants in the contact section below for further information.

      Specification Grounding: OPC 10000-12, Clause 3.1.11, Clause 3.1.12, and Clause 8.4 (KeyCredentialManagementType)

  2. Cryptographic Security & Hardware Protection

    1. Certificate Authority (CA) & PKI Integration

      • Classification: Mandatory (A conformant GDS must manage X.509 certificate lifecycles)
      • Functionality: Functions as a dedicated industrial Certificate Authority (Root or Subordinate CA) or bridges to an enterprise PKI (e.g., Microsoft CA, EJBCA) . Generates, signs, and distributes X.509 v3 digital certificates containing ApplicationURI, SANs (Subject Alternative Names), and specific endpoint IP/DNS addresses
      • Audience:
        • Business: Establishes a verifiable 'Chain of Trust' across the enterprise, preventing rogue hardware from joining the production network.
        • Developer: Interacts with StartSigningRequest and FinishRequest methods to handle Certificate Signing Requests (CSRs)
        • Security Engineer: Enforces RSA (2048/4096-bit) or ECC key generation standards and assigns certificates into discrete CertificateGroups (DefaultApplicationGroup, DefaultHttpsGroup, DefaultUserTokenGroup)

      Specification Grounding: OPC 10000-12, Clause 7 (Certificate Management Overview)

    2. Hardware-Based Key Protection (HSM / TPM)

      • Classification: Recommended / Optional (Industry production best practice; non-mandated by base specification)
      • Functionality: Protects the GDS Root/Intermediate CA private key using Hardware Security Modules (HSM) or cloud KMS . Utilizes Trusted Platform Modules (TPM 2.0) on edge nodes in order to store device private keys locally, ensuring private keys never cross the wire or reside in plain text on host disk storage.

      NOTE: Please contact our consultants below concerning support for OS-level certificate stores, Windows CryptoAPI/CNG and file-based PEM/DER key stores.

      Specification Grounding: Unstated in Part 12 core text (implementation-dependent security architecture)

  3. Certificate Lifecycle & Trust Management

    1. Pull Management Model (CertificateDirectoryType)

      • Classification: Conditional (Mandatory for client applications pulling their own security materials)
      • Functionality: The application acts as an OPC UA client and initiates requests to the GDS . The client periodically invokes GDS methods (GetCertificateStatus, StartSigningRequest, GetTrustList) to poll for updated certificates, trust lists, and CRLs.

      NOTE: This requires the client node to possess active outgoing connectivity to the GDScout and manage its own internal key-rebind logic upon receiving a new signed certificate. Please reach out to our consultants in the contact section below for more details.

      Specification Grounding: OPC 10000-12, Clause 7.5 and Clause 8.4

    2. Push Management Model (ServerConfigurationType)

      • Classification: Conditional (Mandatory for servers/headless PLCs receiving remote certificate updates)
      • Functionality: The GDS acts as an OPC UA client and connects directly to the target OPC UA server's ServerConfiguration object . The GDS calls methods directly on the target server (CreateSigningRequest, UpdateCertificate, ApplyChanges) to push new certificates, trust lists, and revocation lists down to the host at runtime
      • Audience:
        • Business: Achieves 'zero-touch' field device maintenance without requiring system reboots or manual technician interventions.
        • Developer: Implements ServerConfigurationType method handlers on the server side.
        • Security Engineer: Mandates that the GDS session connecting to the server possesses elevated administrative rights (ApplicationAdmin).

      Specification Grounding: OPC 10000-12, Clause 8.3 and Clause 9.6.

    3. Trust List & Certificate Revocation List (CRL / OCSP) Management

      • Classification: Mandatory (A core GDS certificate management requirement).
      • Functionality: Maintains, updates, and distributes TrustList objects containing trusted CA certificates, intermediate issuers, and Certificate Revocation Lists (CRLs). Instantly neutralizes compromised assets by distributing updated CRLs across managed nodes.

      NOTE: Part 12 relies primarily on CRL distribution. Online Certificate Status Protocol (OCSP) real-time querying is not explicitly specified for field-level OPC UA channels. If this is of interest, please reach out to our consultants in the contact section below for further information.

      Specification Grounding: OPC 10000-12, Clause 7.5 and Clause 7.7 (TrustListType).

    4. Application Registration & Onboarding Workflows

      • Classification: Mandatory (Core GDS directory requirement).
      • Functionality: Provides structured onboarding interfaces . Applications invoke RegisterApplication to submit their metadata (ApplicationUri, ProductUri, DiscoveryUrls, ServerCapabilities). Unregistered applications remain isolated until approved by an administrator (DiscoveryAdmin).

      Specification Grounding: OPC 10000-12, Clause 6.5.2(DirectoryType).

  4. Discovery, Network & Messaging Protocols

    1. Local Discovery Service (LDS / LDS-ME) & mDNS / DNS-SD Integration

      • Classification: Conditional (Mandatory for auto-populating GDS registries across multicast subnets)
      • Functionality: LDS handles single-host discovery, while LDS-ME (Multicast Extensions) enables subnet-wide mDNS / DNS-SD discovery . GDScout integrates with local LDS-ME instances by periodically calling FindServersOnNetwork to discover newly connected nodes automatically.
      • Audience:
        • Business: Eliminates manual IP address cataloging when expanding production lines.
        • Developer: Distinguishes local LDS query endpoints (opc.tcp://host:4840/UADiscovery) from enterprise GDS endpoints.
        • Security Engineer: Ensures nodes discovered via mDNS are placed in an 'Unapproved/Pending' state until explicit CA signing occurs.

      Specification Grounding:OPC 10000-12, Clause 5 (LDS-ME) and Clause 6.2.1

    2. Firewall, DMZ & Reverse Connect Integration

      • Classification: Conditional (Mandatoryfor cross-zone and Purdue Model DMZ traversal)
      • Functionality: Enales GDS communications across strict network boundaries without opening dangerous inbound firewall ports . Supports Reverse Connect (RCP capability), allowing an OPC UA server behind an OT firewall to establish an outbound TCP channel to the GDS or client (For further information please contact the consultant).

      Specification Grounding: OPC 10000-12, Clause 4.1, Clause 6.2, and Annex F(Firewalsl).

    3. Messaging Protocols (MQTT / OPC UA PubSub SKS Integration)

      • Classification: Conditional (Mandatory when managing keys for OPC UA PubSub over MQTT/UADP).
      • Functionality: GDScout integrates with a Security Key Service (SKS). The GDScout generates, manages, and distributes symmetric group keys to authorized Publishers and Subscribers. Data payloads remain encrypted end-to-end, preventing untrusted MQTT brokers from inspecting industrial payload contents.

      Specification Grounding: OPC 10000-12, Clause 8 (SecurityKeyService).

  5. Cloud Platforms & External Resource Access Patterns

    1. Cloud Platform Hosting & Multi-Site Federation (Azure IoT / AWS IoT)

      • Classification: Recommended / Optional - (Enterprise deployment pattern; non-mandated by base Part 12)
      • Functionality: Hosts GDS instances within cloud environments (e.g., Azure VM, AWS EC2, Docker containers) to provide multi-site application registry services across global facilities. Federates trust across regions using hierarchical CA trees (Cloud Root CA $\ rightarrow$ Regional Factory Subordinate CAs).

      Specification Grounding: Unstated in Part 12 core text (supported via standard GDS Information Model over opc.tcp or HTTPS transports) .

    2. External Authorization Services & Resource Access Patterns

      • Classification:Conditional (Mandatory when delegating user authentication to external Identity Providers).
      • Functionality: Integrates the GDS with external Authorization Services (AS) using OpenID Connect (OIDC) / OAuth 2 workflows. Clients request token issuance metadata via GetServiceDescription and submit tokens to target OPC UA servers to gain authorized access to specific address space nodes.

      Specification Grounding: OPC 10000-12, Clause 9 (Information Model for Authorization Services).

Standardized Industrial Product Use Cases

Three predominant real-world implementation patterns for OPC UA GDS solution are:

GDScout Core Product Use Cases

Use Case 1: Controller & Application Certificate Lifecycle Management

In high-availability manufacturing environments, GDScout functions as a central Certificate Authority (CA) to automate the complete security lifecycle of X.509 digital certificates across PLCs, HMIs, and SCADA systems. Using the GDS Push management model (ServerConfigurationType), GDScout pushes renewed certificates, updated TrustList objects, and Certificate Revocation Lists (CRLs) directly to runtime field controllers without requiring system reboots or production line stops. Simultaneously, SCADA and client applications utilize the Pull management model (CertificateDirectoryType) to periodically poll for updated trust stores and signed certificates. Devices assigned to standardized CertificateGroups (such as DefaultApplicationGroup) establish mutual trust derived from a shared CA chain, eliminating manual key handling and preventing unplanned downtime caused by expired security credentials.

Use Case 2: Cross-Subnet Application Discovery & Directory Registry

Across multi-cell production facilities spanning separate IP subnets, GDScout provides a centralized, authoritative directory of verified OPC UA applications that extends beyond the single-subnet constraints of Local Discovery Servers (LDS/LDS-ME). Operating as an authenticated OPC UA server, GDScout allows client applications - such as MES, historians, and cloud analytics gateways—to locate active servers via the QueryApplications service using specific ServerCapabilityIdentifier filters. Field devices register their endpoint metadata (ApplicationUri, DiscoveryUrls, ServerCapabilities) through the DirectoryType interface during initial commissioning. Because directory operations require authenticated sessions under DiscoveryAdmin roles, GDScout serves as an administrator-approved registry that prevents rogue or unverified hardware from being discovered or accessed.

Use Case 3: Automated Zero-Touch Field Device Onboarding & Provisioning

During the commissioning of greenfield production lines or the replacement of field hardware, GDScout integrates with the OPC 10000-21 (Device Onboarding) standard to execute automated device provisioning. When a new controller or edge device enters the network in a temporary provisioning state, it submits a local Certificate Signing Request (CSR) to the GDScout CertificateManager. GDScout authenticates the device identity—optionally verifying manufacturer hardware credentials (IEEE 802.1AR / IDevID)—and issues a signed operational certificate along with the initial plant TrustList. This zero-touch workflow provisions production-ready security credentials and assigns the device to its designated CertificateGroup without requiring manual on-site configuration.

Tani GmbH, Freiligrathstr. 12, 90482 Nuremberg, Germany. Phone: +49 911 47766500 Mail: info@gdscout.eu HRB: Amtsgericht Nürnberg 29562, Vat-Id DE 289 906 852 Imprint Data Protection