CKR_USER_NOT_LOGGED_IN

What the token is reporting

The operation touches something that requires an authenticated session, and the token does not currently consider you authenticated. Private objects are the usual trigger, and they are invisible rather than forbidden, so a search will simply not find them.

Likely causes

Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.

Nothing ever logged in

Reading public objects and enumerating slots all work without a login, so an application can get a long way before this appears. The first private key operation is where it surfaces.

Check it: Read the session information and look at its state. It names whether the session is a public one or an authenticated one, which is more reliable than tracing where your code thinks it logged in.

Something logged out, or the token ended the session

Logout applies to every session on the token, so one component logging out affects the rest of the process. Idle timeouts on an appliance and token events do the same thing without any call from your side.

Check it: Check whether the failure follows a period of inactivity. A first call that fails after idling and then succeeds once you log in again is an idle timeout, not a bug in your code.

The object is private and you assumed it was public

An object created with the private attribute set requires authentication to be seen at all. A search for it in a public session returns nothing, so the failure often appears as a missing key rather than as a permission problem.

Check it: Search for the object twice, once before login and once after. If it only appears after, the attribute is the answer.

Logged in as the wrong role

The administrator role exists to manage the token rather than to use its keys, and on many tokens it cannot perform ordinary cryptographic operations at all. Being logged in is not the same as being logged in as the role that may do this.

Check it: Check which role the session holds, not merely that it holds one.

Which calls return it

C_Sign, C_FindObjects, C_GetAttributeValue, C_CreateObject

What it is not

It is not about operating system users or file permissions. The state lives on the token and it is the same state for every session your application has open on that token.

Often confused with

• CKR_OBJECT_HANDLE_INVALID: What a search that found nothing turns into a few lines later, when the code uses a handle it never actually received.
• CKR_SESSION_READ_ONLY: The other reason a write is refused, and worth ruling out before changing anything about authentication.

By library

OpenSC

On a card this usually did not come from a login check in the library at all. The card returned status word 0x6982, “security status not satisfied”, the ISO 7816 layer turned that into SC_ERROR_SECURITY_STATUS_NOT_SATISFIED ([iso7816.c](https://github.c om/OpenSC/OpenSC/blob/4fab8b57301f035432191d582922d95d7d426802/src/lib opensc/iso7816.c#L81)), and the translation switch turned that into this code. So the card is saying the operation needed an authentication it did not see, which after a reader reset or a card change is true even when the session believes it is logged in.

SoftHSMv2

Two functions refuse to return it. In C_GetAttributeValue and C_DigestKey, reading a private object without a login produces this code internally and then, because the specification does not list it for those functions, the caller is given the general error instead ([S oftHSM.cpp](https://github.com/softhsm/SoftHSMv2/blob/884cb38f3d2012a0 447bd5f50dbd29c429987c41/src/lib/SoftHSM.cpp#L2084-L2086)). If a private object read fails with the general error on SoftHSM, log in and try again before looking anywhere else.

Sources

• PKCS #11 Specification Version 3.2, OASIS. Read 2026-09-10. Used for constant name and numeric value.

Every description, cause and check on this page is written from scratch. The specification is cited for the constant's name and its number, which are facts, and for nothing else.