Connecting a client to an OPC UA server takes more than an address - it takes the right endpoint, and an endpoint bundles the network address together with the exact security settings the connection will use. The address usually looks like opc.tcp://host:4840, but the same server often offers several endpoints that differ in how they secure the session. This guide explains what an OPC UA endpoint is, how discovery lets a client list what a server offers, and why picking an endpoint whose security the client cannot satisfy quietly blocks the connection.
OPC UA Endpoint URL in one line: An OPC UA endpoint is a specific way to connect to a server, described by an endpoint URL - typically opc.tcp://host:4840 - together with a security policy and a message security mode. The URL names the transport, host, and port, while the security policy names the cryptographic algorithms and the message security mode says whether traffic is unsecured, signed, or signed and encrypted. A server usually publishes several endpoints, and a client must choose one whose security requirements it can meet or the connection will fail.
The most visible part of an endpoint is its URL, and for the native OPC UA binary transport it begins with the opc.tcp scheme rather than http. A typical endpoint URL is opc.tcp://plc-gateway.example:4840, where opc.tcp selects the efficient binary TCP transport designed for OPC UA, the host portion identifies the server on the network, and 4840 is the registered default port for OPC UA. A server can be configured on a different port, but 4840 is the conventional one and the first thing to try.
The URL alone gets a client to the server's front door, but an endpoint is more than a URL. Each endpoint the server advertises couples that network address with a particular security configuration, so two endpoints can share the same host and port yet represent genuinely different ways to connect - one that encrypts everything and one that does not. This is why an endpoint is described as a URL plus its security settings, not just an address; the address tells you where, and the security settings tell you how.
There is also an OPC UA HTTPS transport for some deployments, but the opc.tcp binary transport is the common case in industrial settings because it is compact and efficient. Whichever transport is used, the endpoint URL is the string a client is ultimately given or discovers, and it is the anchor everything else about the connection hangs from. Getting the host and port right is necessary but, as the next sections show, not by itself sufficient.
Every endpoint carries a security policy, which names the set of cryptographic algorithms the connection will use for signing and encrypting messages and for exchanging keys. Policies range from None, meaning no security, up through named policies that specify particular algorithm suites. A server advertises which policies it supports on which endpoints, and a client and server must agree on one; if the client cannot use any policy the chosen endpoint offers, they cannot establish a secure channel.
Alongside the policy, each endpoint has a message security mode that determines how much protection is actually applied to messages: None for no protection, Sign for messages that are cryptographically signed so tampering is detectable, and SignAndEncrypt for messages that are both signed and encrypted so they are also confidential. A server commonly exposes several endpoints spanning these modes - perhaps a None endpoint for a trusted local network and a SignAndEncrypt endpoint for connections crossing untrusted links - leaving the operator to choose the appropriate one.
Security in OPC UA also rests on certificates. When an endpoint requires signing or encryption, the client and server exchange application certificates, and each side must trust the other's certificate for the secure channel to come up. This means a correctly chosen endpoint can still fail if the client's certificate is not trusted by the server or the server's certificate is not trusted by the client. The endpoint defines the security contract; the certificates are how each party proves it can honor that contract.
Rather than guess an endpoint's exact settings, a client can ask the server to describe them. OPC UA discovery lets a client connect to a server's discovery endpoint and request the list of endpoints it offers; the server returns each endpoint's URL, security policy, message security mode, and the certificate the client will need to trust. Armed with that list, the client picks the endpoint matching its own security requirements and capabilities, rather than blindly attempting a connection with assumed settings.
This matters because choosing the wrong endpoint is a common and confusing failure. If a client tries an endpoint that requires SignAndEncrypt but the client is configured for no security, or selects a security policy it does not support, or reaches an encrypted endpoint whose certificate it does not trust, the connection is refused before any data flows. The symptom is often just a failed connect with a security-related error, and to someone who confirmed the host and port are reachable it can look baffling - the network is fine, yet the session will not open.
For a cloud SCADA such as Merobix connecting to a facility's OPC UA server, the endpoint is the whole connection contract: the opc.tcp URL and port, the security policy, the message security mode, and the certificate trust between platform and server. Merobix discovers the server's endpoints and connects on one whose security both sides can satisfy, and setting up that trust - installing and trusting certificates on each side - is part of commissioning the link. Getting the endpoint choice and its security right once is what turns a reachable server into a working data source; a mismatch there leaves the values invisible even though the server is plainly on the network.
The registered default port for OPC UA is 4840, and endpoint URLs for the binary transport typically look like opc.tcp://host:4840. A server can be configured to use a different port, but 4840 is the conventional one. The opc.tcp scheme selects OPC UA's efficient binary TCP transport, which is the common choice in industrial deployments.
Usually because the chosen endpoint's security settings and the client's do not match. If the endpoint requires signing or encryption the client is not configured for, uses a security policy the client cannot support, or requires a certificate the client does not trust, the session is refused even though the host and port are reachable. Discovering the server's endpoints and picking a compatible one, then establishing certificate trust, resolves it.
Discovery lets a client ask a server to list the endpoints it offers, each with its URL, security policy, message security mode, and certificate. The client then chooses an endpoint whose security requirements it can meet rather than guessing. This avoids the common mistake of attempting a connection with assumed security settings that the server does not accept.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.