BadIdentityTokenRejected

BadCredentials

What you actually see

One user's credentials are refused while another user connects successfully to the same endpoint with the same client and settings.

Why it happens

• Wrong password or unknown user nameThe ordinary case. Servers deliberately give the same response for an unknown user and a wrong password so an attacker cannot enumerate accounts, which means the code tells you less than you would like. Verify the credentials somewhere else before assuming a server problem.
• Account disabled, expired or lockedA user disabled in the server's own account store, or in the directory it authenticates against, is rejected with valid credentials. Locking is the variant that matters operationally: repeated failed attempts can lock an account, and then even correct credentials are refused.
• Brute-force lockout triggered by a bulk-connect clientServers commonly cap failed authentication attempts - a default of five is typical - and apply the lockout per certificate. A client that connects many sessions with one application certificate and one wrong credential can trip the counter quickly, and subsequent attempts fail regardless of what you correct.
• User certificate not in the trusted user storeX.509 user tokens are validated against the trusted user and issuer user stores, which are separate from the application trust stores. A user certificate installed into the application trust list instead of the user trust list is rejected, and the mistake is easy to make because the folder names are similar.
• Issued token expired or from an unaccepted issuerA JWT or similar issued token that has expired, or was issued by an authority the server does not accept, is rejected on its content. The issuer configuration is on the server side, so a token that works for one server may be refused by another in the same estate.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Check for a lockout before retryingIf several failed attempts have already occurred, further attempts may be pointless and may extend the lockout. Look at the server's audit events or its own log for a lockout indication, and clear it deliberately rather than by waiting and guessing.
2. Verify the credential out of bandConfirm the user name and password against the server's account store or directory directly, and confirm the account is enabled and not expired. This separates a credential problem from an OPC UA problem in one step.
3. For certificate users, check the user trust stores specificallyA user certificate must be trusted through the trusted user store, with any CA in the issuer user store. These are distinct from the application trusted and issuer stores. Confirm the file is in the right one and that its chain and CRL situation are as valid as an application certificate's must be.
4. Stop the retry loop and back offA client that retries authentication in a tight loop will lock the account and generate an audit flood that obscures the original cause. Fail after one attempt, back off with a long interval, and surface the failure to an operator rather than retrying automatically.
5. Read the server's audit eventsServers that implement auditing raise events for session activation attempts, which usually carry more detail than the status code returns to the client. Where you can subscribe to them as an administrator, the reason for the rejection is often stated plainly.
6. Confirm you are authenticating rather than falling back to anonymousSome clients silently fall back to anonymous when a credential is refused. Check the server's session diagnostics for the identity actually in use; a session that appears to work with the wrong identity causes access problems later that look unrelated.

Where it shows up, by tool and stack

What it looks like in the log

ActivateSession rejected for user 'scada_ro': BadIdentityTokenRejected
Failed authentication attempts 5 of 5 for certificate CN=Collector; further attempts refused
User certificate CN=operator1 not present in trustedUser store

Confirm the fix

Confirm the session activates and that the server's session diagnostics report the intended user identity, then confirm the account's failed-attempt counter has reset rather than sitting near its limit.

Stop it happening again

Never retry authentication in a loop, keep credentials in a secret store rather than in configuration files, use distinct application certificates per collector instance so one bad credential cannot lock a shared identity, and monitor audit events for activation failures.

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.