BadSessionNotActivated
BadLifecycle
BadSessionNotActivated means CreateSession succeeded but ActivateSession never did, so the session carries no verified user identity and the server refuses all other services. Send ActivateSession with a valid client signature and UserIdentityToken before any Read, Browse or CreateSubscription call.
What you actually see
The connection appears to come up - no certificate error, no timeout - but the first real request, usually a Browse of the root folder, fails with BadSessionNotActivated.
Why it happens
- The client skipped ActivateSessionSession establishment is four stages: TCP accept, OpenSecureChannel, CreateSession, then ActivateSession. Hand-rolled clients and scripted service calls frequently stop after CreateSession because it returns a SessionId that looks usable. Only ActivateSession verifies the client signature and the user identity.
- ActivateSession was attempted and failed, and the client carried onIf ActivateSession returns BadIdentityTokenRejected, BadUserAccessDenied or BadApplicationSignatureInvalid and the client swallows that error, the session stays in the created-but-not-activated state. The next service call then reports BadSessionNotActivated, which masks the real cause.
- Activation sent on a different secure channelActivateSession must be sent on a channel the server accepts for that session. A client that opens a second channel, or lets a channel renewal complete between CreateSession and ActivateSession, can end up activating nothing while the created session waits.
- Race between session creation and worker threadsIn async clients it is easy to start subscription or read tasks as soon as the SessionId is known. Those tasks reach the server before activation completes and get BadSessionNotActivated, then retry successfully a moment later - a confusing intermittent.
- Server requires a user token the client did not supplyIf the endpoint offers only UserName or Certificate user token policies and the client sends Anonymous, activation is refused. Some clients then continue with an unactivated session rather than surfacing the identity error.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Confirm ActivateSession was actually sent and what it returnedTurn on stack-level tracing or capture with the Wireshark OPC UA dissector on port 4840. You are looking for an ActivateSessionRequest and its response StatusCode. If there is no request, that is your bug.
- Fix the underlying activation error, not this oneBadSessionNotActivated is nearly always a downstream symptom. Chase the ActivateSession status: identity token problems, a bad client signature over the server nonce, or a user access denial.
- Check the endpoint's UserIdentityTokens listCall GetEndpoints with security None and read UserIdentityTokens on each EndpointDescription. If Anonymous is not offered, supply a UserName or Certificate token that matches an advertised policy id.
- Serialise activation before any other requestDo not start subscription creation, browse or read work until the ActivateSession response has been processed. Gate worker startup on an activated event rather than on session creation.
- Keep activation on the same secure channelComplete CreateSession and ActivateSession back to back on one channel. If your stack renews channel tokens aggressively, avoid long pauses - for example prompting a user for a password - between the two calls.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | Session.Create performs CreateSession and ActivateSession together, so this code usually means hand-written service calls against SessionClient rather than the managed Session helper. |
| open62541 (C) | UA_Client_connect and UA_Client_connectUsername drive both stages. If you build the requests manually with the low-level service API, you must send ActivateSession yourself and check its response header. |
| node-opcua | client.createSession() covers activation. Calling low-level service requests directly, or reusing a session object across a client.disconnect(), can leave you addressing an unactivated session. |
| asyncua (Python) | Client.connect() runs the whole sequence. If you use the lower-level UaClient interface, call activate_session explicitly and inspect the returned status before doing anything else. |
| Compliance Test Tool (UACTT) | The session test cases deliberately probe services on an unactivated session and expect this exact code, which makes it a useful reference for what a conformant server should return. |
What it looks like in the log
BrowseRequest rejected: BadSessionNotActivated
CreateSession succeeded (sessionId=ns=1;i=1042) but ActivateSession has not completed
ActivateSession failed with BadIdentityTokenRejected; session remains unactivatedConfirm the fix
Capture one clean connect and confirm the order TCP, OpenSecureChannel, CreateSession, ActivateSession with a Good status on activation, then a successful Browse of i=84.
Stop it happening again
Use your SDK's high-level connect helper rather than assembling service calls by hand, and make activation failures fatal in client code so the real identity error surfaces instead of this one.
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.