Status code · Security
BadNonceInvalid
BadNonce
BadNonceInvalid means the nonce supplied in the handshake is the wrong length or is not acceptable as a random value. The required length is tied to the negotiated security policy, so a zero-length or fixed nonce sent when a secure policy is in force is rejected. Update the offending client or server stack.
Defined behaviour: The nonce does appear to be not a random value or it is not the correct length. (our description of the condition this code reports)
What you actually see
One particular client or server pairing fails at OpenSecureChannel or ActivateSession while both applications work perfectly against every other peer.
Why it happens
- A zero-length or short nonce from an older implementationSome older or embedded implementations send an empty nonce, or a nonce sized for a different policy, when they should send one matching the negotiated policy's key length. A peer that validates strictly refuses it, which is why the pairing fails while each side works elsewhere.
- Nonce length not updated after the policy changedThe required nonce length follows the security policy. An implementation that hard-codes a length appropriate for one policy and then negotiates another sends a correctly formed but wrongly sized nonce.
- A nonce reused across attemptsNonces exist to bind each handshake to that handshake. A client that caches and replays a nonce on reconnect, or a test harness that pins the value for reproducibility, produces a value the peer will not accept.
- A nonce that fails a randomness checkA predictable value such as all zeroes, or one produced by an uninitialised random source on an embedded target, can be rejected outright. Devices with no entropy source at early boot are the usual culprits.
- Nonce omitted because security was expected to be NoneWhere one side believes the channel is unsecured and the other has negotiated a secure policy, the nonce is absent or empty on one side and required on the other, and the mismatch is reported as an invalid nonce.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Establish which side generates the rejected nonceThe client nonce is sent in OpenSecureChannel and in ActivateSession; the server nonce comes back in the responses. Note which service failed and in which direction, because the fix belongs to whoever produced the bad value.
- Confirm the negotiated security policyRead SecurityPolicyUri from the endpoint you connected to. Nonce length requirements follow the policy, so a policy change is often the event that introduced the failure even though nothing about the nonce code changed.
- Update or patch the offending stackThis is an implementation defect rather than a configuration mistake. Move the failing side to a current release of its SDK, or to the vendor's current firmware, since nonce handling has been tightened over time in most stacks.
- Check entropy on embedded targetsOn a device with no hardware random source, verify the random number generator is seeded before the OPC UA stack starts. Connections attempted immediately at boot can produce weak or constant nonces that later attempts do not.
- Confirm with a known-good peerConnect the suspect application to a public reference server such as opc.tcp://opcua.umati.app:4840 or opc.tcp://milo.digitalpetri.com:62541/milo with the same policy. If it fails there too, the defect is on your side and you have a reproducible case to report.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| open62541 (C) | Nonce generation goes through the crypto backend, so a build with a weak or unseeded random source on an embedded target is the realistic cause. Verify the platform layer provides real randomness before the first connection. |
| UA-.NETStandard (C#) | The server validates nonce length against the negotiated policy and rejects mismatches rather than tolerating them. A third-party client that worked against older servers can start failing after the server is updated. |
| node-opcua | Nonce handling is internal to the channel implementation. If a specific peer fails only against node-opcua, capture the handshake and raise it with the peer's vendor rather than trying to configure around it. |
| Eclipse Milo (Java) | The channel implementation checks nonce length as part of the security header validation, and the exception message usually reports the length it received against the length it expected, which is unusually helpful here. |
| Wireshark OPC UA dissector | The OpenSecureChannel request and response are visible in plaintext structure, so you can see whether a nonce field is present and how long it is even without any keys. |
| Siemens S7-1500 | Where a PLC-embedded server pairs badly with one client stack and fine with others, firmware is the variable to change. Test the same client against a soft server first to confirm which side is producing the rejected value. |
What it looks like in the log
OpenSecureChannel failed: BadNonceInvalid - client nonce length 0, expected length for the negotiated policy
ActivateSession rejected: nonce is not a valid random value
The nonce does appear to be not a random value or it is not the correct lengthConfirm the fix
Connect the same application to a public reference server on the same policy and confirm the handshake completes, then repeat against the original peer after the update.
Stop it happening again
Keep SDK versions current on both sides and include a handshake test against a reference server in commissioning, so nonce and signature defects are found before the device is in a plant.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →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.