Nonce
In OPC UA, a nonce is a single-use random value exchanged during OpenSecureChannel and ActivateSession. Channel nonces are the input to symmetric key derivation and must be fresh for each token renewal; the session nonce is what a client signs to prove possession of its private key, which is what stops a replayed handshake.
Two nonces, two different jobs
In OpenSecureChannel the client sends a client nonce and the server returns a server nonce, and both sides derive the symmetric signing and encryption keys from them. Each nonce must be cryptographically random, unpredictable, and of the length the active security policy requires. On every security-token renewal the exchange repeats with fresh nonces, so the keys change over the life of a long-lived channel.
The session nonce proves possession
CreateSession returns a server nonce, and in ActivateSession the client signs it with the private key of its application instance certificate, and again with the user private key if it is presenting an X509 identity token. That signature is what proves the client actually holds the keys rather than merely having a copy of the certificate. A bad application signature is BadApplicationSignatureInvalid and a bad user signature is BadUserSignatureInvalid - both usually mean a key and certificate mismatch, not a network problem.
When you actually see BadNonceInvalid
The common causes are a client that sends a nonce shorter than the policy requires, a client that reuses the previous nonce on renewal because its implementation cached it, and a client that omits the nonce entirely on an endpoint where it is required. It is almost always a client-side implementation or configuration issue, and it appears at the handshake, before any address space is touched - so it is not a certificate trust problem however much the timing suggests one.
PubSub has no nonce, and that shapes its security
There is no handshake in PubSub, so there is nothing to nonce. Freshness is enforced instead by message sequence numbers and a replay window, with symmetric group keys from a Security Key Service. That is a real difference in security properties, not just in mechanism: a group key authenticates membership of the group, where a nonce-based handshake authenticates a specific peer and a specific session.
Example
Where each nonce appears in the connect sequence
OpenSecureChannel client -> clientNonce
server -> serverNonce
both derive symmetric keys from the pair
... repeated on every token renewal, fresh nonces each time
CreateSession server -> serverNonce
ActivateSession client -> signature over (serverCertificate + serverNonce)
with its application private key
-> plus a user signature over the same, for an X509 token
failures: BadNonceInvalid nonce missing, short or reused
BadApplicationSignatureInvalid application key does not match its certificate
BadUserSignatureInvalid user key does not match the user certificateDefined in: Part 4 - Services, OpenSecureChannel and ActivateSession; Part 6 - Mappings for key derivation.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.