OPC UA does not just encrypt traffic; it verifies who is on each end of a connection. Every client and every server carries an application instance certificate that identifies it, and a connection is only allowed when each side has been told to trust the other's certificate. This guide explains how that mutual authentication works, the slightly awkward first-connect rejection dance that trips up nearly everyone new to OPC UA, the difference between self-signed and CA-issued certificates, the role of the rejected-certificates folder, and the certificate-expiry pitfall that can silently break a link that has run reliably for years.
Application Instance Certificate in one line: An OPC UA application instance certificate is a digital certificate that uniquely identifies a specific client or server application. OPC UA uses these for mutual authentication: a connection succeeds only when each side has placed the other's certificate in its trust list. On a first connection, each side typically rejects the unknown certificate and files it in a rejected-certificates folder; an administrator then moves it to the trusted list, after which the two can connect.
In OPC UA, both ends of a connection prove their identity, not just the server. Each application - a client and a server alike - holds its own application instance certificate, a certificate that identifies that particular application instance rather than a person or a machine in general. When they establish a secure channel, they exchange certificates, and each side checks whether it actually trusts the certificate the other presented. Only if both checks pass does the channel form. This is mutual authentication: the client verifies the server, and the server simultaneously verifies the client.
Trust is decided by a trust list. Each application maintains a set of certificates it is willing to accept, and a presented certificate is honored only if it appears in that trusted set, either directly or through a trusted certificate authority that issued it. If the presented certificate is not in the trust list and was not issued by a trusted authority, the receiving side rejects the connection outright, regardless of whether the cryptography itself is sound. The certificate can be perfectly valid and the encryption perfectly strong, and the connection will still fail purely because trust has not been established.
This is a stronger model than the one-sided authentication common on the public web, where a browser checks a website's certificate but the website does not check the browser's. In an industrial setting, where a client is issuing commands that move equipment, it matters just as much that the server can confirm the client is authorized as it does that the client can confirm it is talking to the right server. Requiring both certificates to be mutually trusted is how OPC UA enforces that two-way assurance.
The behavior that surprises almost everyone the first time is that a brand-new client and server will refuse to connect to each other, even when everything is configured correctly. That is by design. On the very first attempt, neither side has the other's certificate in its trust list, so each side does exactly what it is supposed to do: it rejects the unknown certificate. The connection fails, but not because anything is broken - it fails because trust has not yet been established, which is precisely the safe default.
What makes this recoverable is the rejected-certificates folder. When an application rejects an unknown certificate, it does not simply discard it; it saves a copy into a designated rejected folder. An administrator setting up the link goes to that folder, inspects the certificate that was rejected, confirms it belongs to the application that should be trusted, and moves it into the trusted list. Once both sides have done this - each having moved the other's certificate from rejected to trusted - the next connection attempt succeeds. This move-from-rejected-to-trusted step is the standard OPC UA commissioning ritual, and knowing it exists turns a confusing first-connect failure into a routine two-minute task.
The choice between self-signed and CA-issued certificates changes how much of this you do by hand. A self-signed application instance certificate is generated by the application itself and trusted individually, which is simple for a handful of connections but means every pairing must be approved one by one. Certificates issued by a shared certificate authority let applications trust the authority once, so any certificate that authority signs is accepted without a manual per-connection approval. At larger scale, a Global Discovery Server can automate issuing and distributing these certificates across many applications, which is how big deployments avoid drowning in manual trust decisions.
Certificates expire, and that is the pitfall that catches long-running OPC UA links. An application instance certificate has a validity period, and when it passes its expiry date the other side will start rejecting it - the same way it would reject any untrusted certificate. The failure mode is especially nasty because it strikes a connection that has worked flawlessly for a long time: nothing in the configuration changed, no one touched the network, and yet one day the link stops forming because a certificate quietly reached its expiry date. Teams that do not track certificate lifetimes can spend a long time hunting for a cause that turns out to be a calendar date passing.
Avoiding this means treating certificate lifecycle as something to monitor, not set and forget. Certificates need to be renewed and re-trusted before they expire, and in a deployment with many applications that is a real administrative task. Doing it reactively - waiting for a link to break and then discovering the expiry - is how outages happen; doing it proactively, with visibility into when each certificate is due, is how they are avoided. This is exactly the kind of quiet infrastructure detail that determines whether an OPC UA integration stays healthy over years or fails in a confusing way at an inconvenient moment.
For a cloud SCADA platform such as Merobix connecting as an OPC UA client to servers across many sites, certificate trust and expiry are part of the operational picture rather than a one-time setup step. The platform holds its own application instance certificate, establishes mutual trust with each server it connects to, and benefits from tracking certificate validity so that a looming expiry surfaces as something to act on before it silently drops a link. Handled well, the certificate model gives strong, two-way, per-application authentication; handled carelessly, the same model turns an expiry date into an unexplained outage - which is why understanding trust lists, the rejected folder, and expiry is as important as understanding the encryption itself.
Because neither has the other's certificate in its trust list yet, so on the first attempt each side correctly rejects the unknown certificate and saves it to a rejected-certificates folder. This is the intended safe default, not a fault. An administrator moves each certificate from the rejected folder into the trusted list on both sides, and after that the connection succeeds.
A self-signed application instance certificate is generated and trusted individually, which is simple but requires approving every client-server pairing by hand. A CA-issued certificate is signed by a certificate authority, so applications can trust that authority once and automatically accept any certificate it signs. Self-signed suits a few connections; CA-issued certificates, often managed by a Global Discovery Server, scale far better across many applications.
A common cause is certificate expiry. Application instance certificates have a validity period, and once one expires the other side rejects it just like any untrusted certificate, even though nothing else changed. Because the failure appears out of nowhere on a previously reliable link, it is easy to misdiagnose. Tracking certificate lifetimes and renewing before expiry prevents this class of silent outage.
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.