![\"OPC](\"https://wiki.aspotomasyon.com/assets/diagrams/opc-ua-discovery-lds-gds.svg\")
OPC UA discovery lets clients find servers and their endpoints through a local discovery server on each host, a multicast extension, or a global discovery server for the whole estate.
A client that connects to an OPC UA server needs three things: a reachable endpoint URL, the security settings the server accepts, and a trust relationship with the server certificate. Discovery services supply the first two, and certificate management supplies the third. On a small system, a saved endpoint may be enough. On a large estate, with many servers, subnets, and certificate renewals, discovery and its global service become part of the operating procedure.
This article explains the discovery services in OPC UA Part 4, the Local Discovery Server and its multicast extension, and the Global Discovery Server defined in Part 12. It then covers security cautions and a troubleshooting sequence. The technical statements are taken from the OPC Foundation online reference pages for Parts 4, 6, and 12, release 1.05.07.
Every OPC UA server has a DiscoveryEndpoint that clients can reach without a session. The specification says discovery endpoints do not require message security, although they may require transport layer security. Clients use GetEndpoints to read the endpoint descriptions, which carry the security settings needed to open a secure channel.
Clients should save the endpoint information they obtain. If a saved connection fails, the server configuration may have changed, and the client must repeat discovery. The specification also allows administrators to disable discovery in production. Clients then rely on cached endpoint descriptions and need a manual update path.
A Local Discovery Server (LDS) keeps the list of servers that registered with it on the same host. Part 12 says each host with OPC UA applications should run an LDS with the multicast extension. Part 6 defines the well-known LDS addresses, including opc.tcp://localhost:4840/UADiscovery for the TCP mapping, and it says administrators must be able to change them.
An LDS with the MulticastExtension, called an LDS-ME, announces its registered applications on the local multicast subnet using multicast DNS (mDNS), and it supports FindServersOnNetwork. Part 12 states that applications shall not rely on multicast DNS, so the mechanism is a convenience and not the only path to a server. A dedicated embedded device with exactly one server may act as its own LDS. The table compares the options.
| Option | Scope | How servers are known | Main limit |
|---|---|---|---|
| Simple discovery | One server, by URL | Entered manually or taken from a saved list | Needs the URL from an out-of-band source |
| LDS | Servers on one host | Register with the LDS on the same host | FindServers returns only servers on that host |
| LDS-ME | Servers on the local multicast subnet | Announced over mDNS after registration | Multicast DNS must not be the only mechanism |
| GDS | Administrative domain | Registered and verified by administrators | Needs roles, trust, and certificate administration |
The Global Discovery Server (GDS) is an OPC UA server that lets clients search for applications within an administrative domain. Part 12 describes it as an authoritative source for applications that administrators verified and that were reached over a secure channel. It can front an existing directory such as LDAP, and it may also act as a certificate manager. Clients query it with the QueryApplications method, which offers more advanced search and filter criteria than FindServers. Certificate design, renewal, and trust lists are covered in OPC UA certificate and trust management and OPC UA certificate renewal without connection failures.
The GDS restricts its methods by role. The DiscoveryAdmin role registers, updates, and unregisters any application, and the SecurityAdmin role changes the GDS security configuration. Certificate changes flow in one of two directions:
Follow an ASP project guide to connect the fundamentals with implementation and acceptance.
A Local Discovery Server runs on one host and lists the OPC UA applications that register with it on that host. A Global Discovery Server is an OPC UA server that covers an administrative domain, holds an authoritative list of applications that administrators verified, and can manage certificates. An LDS finds servers on a machine or subnet, while a GDS supports enterprise-wide discovery and certificate workflows.
The discovery endpoint does not require message security, although it may require transport layer security. Because discovery responses are not trusted on their own, the client compares them with the CreateSession response and checks the server certificate and its host names. The certificate check, not the discovery call, is what establishes trust.
The LDS knows only the servers that registered with it, and in the standard design each server registers with the LDS on its own host. To find servers on other hosts, a client can call FindServersOnNetwork on an LDS-ME, call FindServers on a remote LDS by host name, or query a GDS. Part 12 also says clients can save discovered URLs and skip discovery on later connections.
The specification allows administrators to disable discovery for security reasons, and then clients must rely on cached endpoint descriptions. The trade-off is that a server certificate change needs a manual endpoint update on every client. Disable discovery only when endpoints are stable and documented, and test the manual update path before doing so.
RegisterServer2 lets a server register its discovery URLs and capability identifiers with a discovery server, and it carries the extra information that FindServersOnNetwork needs. Servers try RegisterServer2 first and fall back to RegisterServer when the discovery server returns Bad_ServiceUnsupported. Clients do not call it, and it cannot run over HTTPS, because it needs a secure channel with client authentication.
Browse the related technical library or follow an ASP project guide to plan the implementation sequence.
![\"A](\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\")
Use the original specifications and product documentation for implementation details. Examples in this guide are illustrative engineering scenarios, not published project results.
","markdown":"# OPC UA Discovery: LDS, LDS-ME, and Global Discovery Server Explained\n\n> OPC UA discovery lets clients find servers and their endpoints through a local discovery server on each host, a multicast extension, or a global discovery…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/opc-ua-discovery-lds-gds\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: OPC Solutions\n- Published: 2026-10-11 · Updated: 2026-10-11\n- Reading time: 9 min · Language: English\n\nOPC UA discovery lets clients find servers and their endpoints through a local discovery server on each host, a multicast extension, or a global discovery server for the whole estate.\n\n\n\n*OPC UA Discovery: LDS, LDS-ME, and Global Discovery Server Explained — Find the endpoint → Verify the response → Trust the certificate → Keep a fallback.*\n\nA client that connects to an OPC UA server needs three things: a reachable endpoint URL, the security settings the server accepts, and a trust relationship with the server certificate. Discovery services supply the first two, and certificate management supplies the third. On a small system, a saved endpoint may be enough. On a large estate, with many servers, subnets, and certificate renewals, discovery and its global service become part of the operating procedure.\n\nThis article explains the discovery services in OPC UA Part 4, the Local Discovery Server and its multicast extension, and the Global Discovery Server defined in Part 12. It then covers security cautions and a troubleshooting sequence. The technical statements are taken from the OPC Foundation online reference pages for Parts 4, 6, and 12, release 1.05.07.\n\n## Discovery services in Part 4\n\nEvery OPC UA server has a DiscoveryEndpoint that clients can reach without a session. The specification says discovery endpoints do not require message security, although they may require transport layer security. Clients use GetEndpoints to read the endpoint descriptions, which carry the security settings needed to open a secure channel.\n\n- **GetEndpoints** returns the endpoint descriptions, including the security mode, the security policy, and the user token types.\n- **FindServers** returns the servers known to a server or discovery server. A discovery server returns an empty list when no server matches the filter.\n- **RegisterServer and RegisterServer2** let a server register with a discovery server. Clients do not call them. RegisterServer2 carries the information needed for network discovery, and a server falls back to RegisterServer if the discovery server does not support it.\n- **FindServersOnNetwork** is implemented only by discovery servers. It returns records in batches, so a client can ask for the records that follow the last identifier it received.\n\n### Saving endpoints and disabling discovery\n\nClients should save the endpoint information they obtain. If a saved connection fails, the server configuration may have changed, and the client must repeat discovery. The specification also allows administrators to disable discovery in production. Clients then rely on cached endpoint descriptions and need a manual update path.\n\n## Local Discovery Server and the multicast extension\n\nA Local Discovery Server (LDS) keeps the list of servers that registered with it on the same host. Part 12 says each host with OPC UA applications should run an LDS with the multicast extension. Part 6 defines the well-known LDS addresses, including opc.tcp://localhost:4840/UADiscovery for the TCP mapping, and it says administrators must be able to change them.\n\nAn LDS with the MulticastExtension, called an LDS-ME, announces its registered applications on the local multicast subnet using multicast DNS (mDNS), and it supports FindServersOnNetwork. Part 12 states that applications shall not rely on multicast DNS, so the mechanism is a convenience and not the only path to a server. A dedicated embedded device with exactly one server may act as its own LDS. The table compares the options.\n\n| Option | Scope | How servers are known | Main limit |\n| --- | --- | --- | --- |\n| Simple discovery | One server, by URL | Entered manually or taken from a saved list | Needs the URL from an out-of-band source |\n| LDS | Servers on one host | Register with the LDS on the same host | FindServers returns only servers on that host |\n| LDS-ME | Servers on the local multicast subnet | Announced over mDNS after registration | Multicast DNS must not be the only mechanism |\n| GDS | Administrative domain | Registered and verified by administrators | Needs roles, trust, and certificate administration |\n\n## Global Discovery Server and certificate management\n\nThe Global Discovery Server (GDS) is an OPC UA server that lets clients search for applications within an administrative domain. Part 12 describes it as an authoritative source for applications that administrators verified and that were reached over a secure channel. It can front an existing directory such as LDAP, and it may also act as a certificate manager. Clients query it with the QueryApplications method, which offers more advanced search and filter criteria than FindServers. Certificate design, renewal, and trust lists are covered in [OPC UA certificate and trust management](https://wiki.aspotomasyon.com/article/opc-ua-certificate-management) and [OPC UA certificate renewal without connection failures](https://wiki.aspotomasyon.com/article/opc-ua-certificate-renewal-plan).\n\nThe GDS restricts its methods by role. The DiscoveryAdmin role registers, updates, and unregisters any application, and the SecurityAdmin role changes the GDS security configuration. Certificate changes flow in one of two directions:\n\n- **Pull management** : a client, or an administrative tool acting for it, calls the certificate manager methods to request, renew, or update its certificate and trust list. The channel must be encrypted, and the credentials must be authorized.\n- **Push management** : the registration authority signs a certificate request, and the GDS pushes the new certificate to the server with the UpdateCertificate method. This suits servers that the certificate manager can configure.\n\n## Security cautions\n\n- **Discovery responses are not trusted on their own.** The client compares the discovery results with the CreateSession response, including the application URI, endpoint URL, security mode and policy, and user token types. It also checks the host names in the server certificate. See [OPC UA security best practices](https://wiki.aspotomasyon.com/article/opc-ua-security-best-practices) .\n- **A rogue discovery server can point to a rogue server.** The risk falls when the client verifies trust in the server it connects to. The specification also recommends verifying trust whenever a client connects to a server found through the GDS.\n- **Automatic trust of a GDS certificate is not enough.** A client that uses security but trusts any GDS certificate automatically is not protected from a rogue GDS.\n- **Multicast DNS is not a security control.** Its operations are insecure by nature. Disable them where an attacker on the network could impersonate a host, and rely on OPC UA security with trust lists.\n- **FindServersOnNetwork can be used for denial of service** because it can run without security. Servers should prepare its responses in advance.\n- **RegisterServer2 cannot run over HTTPS.** It needs a secure channel that supports client authentication.\n\n## Troubleshooting discovery problems\n\n1. **Confirm the address and port.** Test the LDS at its well-known address on the host. For the TCP mapping that is port 4840 with the UADiscovery path, unless an administrator changed it. Check the firewall and the server configuration for the same address.\n2. **Separate FindServers from GetEndpoints.** An empty FindServers result means no registered server matches the filter. A failed GetEndpoints call means the discovery endpoint itself is unreachable, disabled, or refusing the transport. Use the [OPC UA connection troubleshooting](https://wiki.aspotomasyon.com/article/opc-ua-connection-troubleshooting) sequence once the endpoint is known.\n3. **Compare discovery with the session.** Match the application URI, endpoint URL, security mode and policy, and the server certificate's host names against the CreateSession response. The specification requires servers to list every host name clients use in the certificate, including IP addresses.\n4. **Check certificate changes against saved endpoints.** If GetEndpoints is disabled and the server certificate changes, clients cannot connect until their endpoint configuration is updated by hand. Update the saved endpoint and trust list, and test the reconnect path.\n5. **Treat multicast results as a hint.** If FindServersOnNetwork returns nothing, check the LDS-ME and the subnet's multicast DNS, then fall back to the configured URL.\n\n**Illustrative example**\n\nAssume a client that connects through a saved endpoint, and a server whose certificate was renewed overnight. The client fails with a trust error. Administrators have disabled the discovery endpoint, so the client cannot refresh its endpoints. The fix is to import the new endpoint description and trust the new certificate, then test a reconnect from a clean start. The sequence is an assumption for illustration, not a measured result.\n\n## Apply this to your project\n\n- List the discovery mechanisms each host and site uses, and whether discovery is enabled in production.\n- Confirm the LDS address and port on each host, including any change an administrator made.\n- Verify that each server certificate includes every host name and IP address that clients use.\n- Compare the discovery results with the CreateSession response on a test client, and record the match.\n- Confirm that multicast discovery is not the only way clients find servers.\n- Document the GDS roles, the trust list owners, and the pull or push workflow for certificate renewal.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n## Frequently asked questions\n\n### What is the difference between an LDS and a GDS?\n\nA Local Discovery Server runs on one host and lists the OPC UA applications that register with it on that host. A Global Discovery Server is an OPC UA server that covers an administrative domain, holds an authoritative list of applications that administrators verified, and can manage certificates. An LDS finds servers on a machine or subnet, while a GDS supports enterprise-wide discovery and certificate workflows.\n\n### Does OPC UA discovery need a certificate?\n\nThe discovery endpoint does not require message security, although it may require transport layer security. Because discovery responses are not trusted on their own, the client compares them with the CreateSession response and checks the server certificate and its host names. The certificate check, not the discovery call, is what establishes trust.\n\n### Why does FindServers return only servers on the same host?\n\nThe LDS knows only the servers that registered with it, and in the standard design each server registers with the LDS on its own host. To find servers on other hosts, a client can call FindServersOnNetwork on an LDS-ME, call FindServers on a remote LDS by host name, or query a GDS. Part 12 also says clients can save discovered URLs and skip discovery on later connections.\n\n### Should OPC UA discovery be disabled in production?\n\nThe specification allows administrators to disable discovery for security reasons, and then clients must rely on cached endpoint descriptions. The trade-off is that a server certificate change needs a manual endpoint update on every client. Disable discovery only when endpoints are stable and documented, and test the manual update path before doing so.\n\n### What does RegisterServer2 do?\n\nRegisterServer2 lets a server register its discovery URLs and capability identifiers with a discovery server, and it carries the extra information that FindServersOnNetwork needs. Servers try RegisterServer2 first and fall back to RegisterServer when the discovery server returns Bad_ServiceUnsupported. Clients do not call it, and it cannot run over HTTPS, because it needs a secure channel with client authentication.\n\n## Continue the engineering work\n\n- [OPC UA Protocol Overview](https://wiki.aspotomasyon.com/article/opc-ua-protocol-overview)\n- [OPC UA Certificate and Trust Management (GDS)](https://wiki.aspotomasyon.com/article/opc-ua-certificate-management)\n- [OPC UA Certificate Renewal Without Surprise Connection Failures](https://wiki.aspotomasyon.com/article/opc-ua-certificate-renewal-plan)\n- [OPC UA Security Best Practices](https://wiki.aspotomasyon.com/article/opc-ua-security-best-practices)\n- [OPC UA Connection Troubleshooting and Performance Tuning](https://wiki.aspotomasyon.com/article/opc-ua-connection-troubleshooting)\n\nBrowse the [related technical library](https://wiki.aspotomasyon.com/category/opc-solutions) or follow an [ASP project guide](https://wiki.aspotomasyon.com/guides) to plan the implementation sequence.\n\n\n\n*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. Examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OPC Foundation — OPC UA Part 4: Services (OPC 10000-4)](https://reference.opcfoundation.org/specs/OPC-10000-4)\n- [OPC Foundation — OPC UA Part 6: Mappings (OPC 10000-6)](https://reference.opcfoundation.org/specs/OPC-10000-6)\n- [OPC Foundation — OPC UA Part 12: Discovery and Global Services (OPC 10000-12)](https://reference.opcfoundation.org/specs/OPC-10000-12)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/opc-ua-discovery-lds-gds (OPC UA Discovery: LDS, LDS-ME, and Global Discovery Server Explained, ASP OTOMASYON, updated 2026-10-11).\n","headings":[{"id":"discovery-services-in-part-4","title":"Discovery services in Part 4"},{"id":"local-discovery-server-and-the-multicast-extension","title":"Local Discovery Server and the multicast extension"},{"id":"global-discovery-server-and-certificate-management","title":"Global Discovery Server and certificate management"},{"id":"security-cautions","title":"Security cautions"},{"id":"troubleshooting-discovery-problems","title":"Troubleshooting discovery problems"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"frequently-asked-questions","title":"Frequently asked questions"},{"id":"continue-the-engineering-work","title":"Continue the engineering work"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[{"question":"What is the difference between an LDS and a GDS?","answer":"A Local Discovery Server runs on one host and lists the OPC UA applications that register with it on that host. A Global Discovery Server is an OPC UA server that covers an administrative domain, holds an authoritative list of applications that administrators verified, and can manage certificates. An LDS finds servers on a machine or subnet, while a GDS supports enterprise-wide discovery and certificate workflows."},{"question":"Does OPC UA discovery need a certificate?","answer":"The discovery endpoint does not require message security, although it may require transport layer security. Because discovery responses are not trusted on their own, the client compares them with the CreateSession response and checks the server certificate and its host names. The certificate check, not the discovery call, is what establishes trust."},{"question":"Why does FindServers return only servers on the same host?","answer":"The LDS knows only the servers that registered with it, and in the standard design each server registers with the LDS on its own host. To find servers on other hosts, a client can call FindServersOnNetwork on an LDS-ME, call FindServers on a remote LDS by host name, or query a GDS. Part 12 also says clients can save discovered URLs and skip discovery on later connections."},{"question":"Should OPC UA discovery be disabled in production?","answer":"The specification allows administrators to disable discovery for security reasons, and then clients must rely on cached endpoint descriptions. The trade-off is that a server certificate change needs a manual endpoint update on every client. Disable discovery only when endpoints are stable and documented, and test the manual update path before doing so."},{"question":"What does RegisterServer2 do?","answer":"RegisterServer2 lets a server register its discovery URLs and capability identifiers with a discovery server, and it carries the extra information that FindServersOnNetwork needs. Servers try RegisterServer2 first and fall back to RegisterServer when the discovery server returns Bad_ServiceUnsupported. Clients do not call it, and it cannot run over HTTPS, because it needs a secure channel with client authentication."}],"references":[{"name":"OPC Foundation — OPC UA Part 4: Services (OPC 10000-4)","url":"https://reference.opcfoundation.org/specs/OPC-10000-4"},{"name":"OPC Foundation — OPC UA Part 6: Mappings (OPC 10000-6)","url":"https://reference.opcfoundation.org/specs/OPC-10000-6"},{"name":"OPC Foundation — OPC UA Part 12: Discovery and Global Services (OPC 10000-12)","url":"https://reference.opcfoundation.org/specs/OPC-10000-12"}],"related":[{"slug":"opc-ua-server-setup-with-kepware","title":"OPC UA Server Setup with Kepware","summary":"This guide walks through the complete process of configuring OPC UA server functionality in Kepware KEPServerEX. Once configured, OPC UA clients can securely…","category":{"slug":"technical-guides","name":"Technical Guides"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-server-setup-with-kepware","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-server-setup-with-kepware.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-server-setup-with-kepware","published":"2026-05-12T12:47:31+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":962,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-server-setup-with-kepware-34ec46e25fac.png"},{"slug":"opc-ua-security-best-practices","title":"OPC UA Security Best Practices","summary":"OPC UA was designed with security as a foundational requirement, not an afterthought.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-security-best-practices","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-security-best-practices.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-security-best-practices","published":"2026-07-21T14:45:28+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":860,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-security-best-practices-8eff8da783a4.png"},{"slug":"opc-da-to-ua-migration-guide","title":"Migrating from OPC DA to OPC UA","summary":"Migrating from OPC DA to OPC UA is one of the most common infrastructure projects in industrial IT. OPC DA (Data Access) has served industry for more than two…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide","markdown_url":"https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-da-to-ua-migration-guide","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":999,"image":"https://wiki.aspotomasyon.com/assets/social/opc-da-to-ua-migration-guide-4dc7a9d57cd5.png"},{"slug":"opc-ua-protocol-overview","title":"OPC UA Protocol Overview","summary":"OPC Unified Architecture (OPC UA) , defined by IEC 62541, is the platform-independent, service-oriented architecture for secure, reliable data exchange in…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-protocol-overview","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-protocol-overview.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-protocol-overview","published":"2026-05-12T12:47:31+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":873,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-protocol-overview-eae98061a685.png"}],"citation":"ASP OTOMASYON. OPC UA Discovery: LDS, LDS-ME, and Global Discovery Server Explained. Updated 2026-10-11. https://wiki.aspotomasyon.com/article/opc-ua-discovery-lds-gds"}}