CKR_DEVICE_REMOVED
Where the general device fault is a shrug, this one is a statement: the library had a token, went to use it, and found it gone. That makes it the most useful device error there is, because it tells you the fault is physical or in the transport rather than anywhere in your code. What it does not tell you is whether the token left for a moment or for good, and those need different responses.
What the token is reporting
Between your last successful call and this one, the slot stopped having a token in it as far as the library is concerned. Everything you were holding against that token is now meaningless: sessions, object handles, and any operation you had in progress.Likely causes
Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.
Somebody unplugged it, or the reader reset
The literal case, and worth ruling out first because it is free to check. On a smartcard or a USB token this covers a pulled card, a dislodged cable, and a reader that reset itself.Check it: Re-enumerate the slots. If the slot is still there but reports no token present, the device really is gone rather than merely unhappy. On Linux, the kernel log will usually have a matching disconnect line.
USB power management suspended the device
A token that is idle long enough can be autosuspended, and some readers come back from that as a new device rather than the one you had. The failure then looks random, because it depends on how long the application sat idle rather than on anything it did.Check it: Check whether the disconnect times correlate with idle periods rather than with load. Disable autosuspend for that device and see whether the failures stop.
A network HSM reset the client link
On a network attached HSM there is no physical device to remove, so this code is the library’s way of reporting that the session on the appliance is gone. A failover, an appliance restart, an idle timeout on the link or a certificate rotation all produce it.Check it: Read the client daemon’s log for the same timestamp. It will name the reason. If the appliance is in an HA group, check whether a member left, because the client can survive that while individual sessions do not.
The token was reinitialized underneath you
An administrator initializing or zeroizing a token produces the same signal as a removal, because from the library’s side the token that was there has ceased to exist.Check it: Check the HSM’s audit or event log for an administrative action at that moment before assuming a hardware fault.
Which calls return it
C_Sign, C_Decrypt, C_GetSessionInfo, C_FindObjects
What it is not
It is not a reason to retry in a tight loop. Whatever took the token away will not be fixed by asking again a millisecond later, and a retry loop on this code is how one unplugged cable turns into a saturated client daemon.Often confused with
CKR_DEVICE_ERROR: The general case. If the library could tell the token had left it would have said so, and this code is it saying so, which makes it the more informative of the two.CKR_TOKEN_NOT_PRESENT: Reported when the slot has no token at the time you asked, rather than when a token you were already using went away. The distinction is whether you ever had it.
See also
By library
OpenSC
OpenSC returns this forSC_ERROR_CARD_REMOVED, a card pulled while the library held it. A reader that was unplugged is a different libopensc error and is translated to the token-not-present code instead, with a comment in the source asking whether it should have been this one ([misc.c](https://github.com/OpenSC/OpenSC/blob/4fab8b57 301f035432191d582922d95d7d426802/src/pkcs11/misc.c#L114)). Two physical events that look the same at the desk arrive as two codes.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.