BadIdentityChangeNotSupported

BadSession identity

What you actually see

An application that connects anonymously and then re-activates with a user's credentials for a privileged action is refused at the re-activation, while a fresh connection with the same credentials works.

Why it happens

• Server does not implement identity change on ActivateSessionActivateSession can be called again on an existing session to change the user identity, but implementing that means re-evaluating every permission, subscription and monitored item against a new identity. Many servers simply refuse rather than doing it, especially embedded ones.
• Client designed to elevate privileges on an existing sessionAn application that browses anonymously and then asks for credentials when the operator attempts a write is a natural design that runs into this. The server's view is that a session belongs to an identity for its lifetime.
• Escalation from anonymous to a named userThe specific case of moving from anonymous to authenticated is the one that appears most often, because it is how a read-only HMI becomes a control HMI. Servers commonly refuse it, so the design must use two sessions from the start.
• Change of token type rather than of credentialsSome servers permit re-activating with new credentials of the same token type but not a change of token type - from anonymous to username, or from username to certificate. The refusal then looks inconsistent until you notice which dimension changed.
• Subscriptions on the session making the change unsafeExisting subscriptions were created under the old identity's permissions. A server that cannot re-evaluate them against a new identity will refuse the change rather than leave notifications flowing under permissions that no longer apply.

How to fix it

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

1. Use one session per identityOpen a separate session for each identity you need: an anonymous or service-account session for continuous data collection, and a short-lived authenticated session for operator actions. This works on every server and makes auditing far clearer, since each action is attributable.
2. Close the elevated session promptlyCreate the authenticated session on demand, perform the action, verify the result, and close it. A long-lived privileged session is both a security exposure and a consumer of the server's session limit.
3. Do not rebuild subscriptions for the elevated actionKeep monitored items on the collection session. The privileged session needs only to perform its write or method call, so it costs one session slot briefly and no subscription capacity at all.
4. Account for the extra sessions against the server's limitEvery additional session counts against MaxSessionCount, and session establishment is CPU-bound on the certificate handshake. On a small embedded server, an HMI that opens a privileged session on every operator action can be a noticeable load - pool or reuse within a short window rather than per click.
5. Check whether the server supports the change before designing around itWhere re-activation with a new identity genuinely works on the target server, it is legitimate to use. Test it explicitly during design rather than assuming either way, and record the answer per server product because it will differ.
6. Keep the audit trail intactServers that implement auditing raise events for session activation. One session per identity gives you a clean record of who did what; identity switching on a shared session muddies it even where the server allows it.

Where it shows up, by tool and stack

What it looks like in the log

ActivateSession with new identity on existing session: BadIdentityChangeNotSupported
Escalation from anonymous to user 'operator1' refused; opening separate session
Privileged session opened for write, closed after 1.2 s

Confirm the fix

Confirm the separate authenticated session activates, that the privileged operation succeeds and its effect is visible by read-back, and that the session is closed afterwards rather than left open.

Stop it happening again

Design for one session per identity from the outset, keep collection and control on separate sessions, close elevated sessions immediately after use, and record per server product whether in-place identity change is supported so nobody rediscovers it.

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.