Initialize Nitrokey HSM Device Blocked

I am trying to re-initialize my HSM key, but it doesn’t work anymore.
Entering: sc-hsm-tool --initialize --so-pin 3537363231383830 --pin 648219
Using reader with a card: Nitrokey Nitrokey HSM (DENK01022960000 ) 00 00
sc_card_ctl(*, SC_CARDCTL_SC_HSM_INITIALIZE, *) failed with PIN code or key incorrect
Running: sc-hsm-tool:
Using reader with a card: Nitrokey Nitrokey HSM (DENK01022960000 ) 00 00
Version : 3.2
Config options :
User PIN reset with SO-PIN enabled
SO-PIN tries left : 7
User PIN tries left : 2

Question: What can I do to factory reset the key and using which command?
I don’t remember having changed any of the PIN. All commands came from OpenSC (

Thank you


Unfortunately Nitrokey HSM does not have factory-reset. Once the SO-PIN is lost, and all attempts are used up for User PIN as well, device becomes blocked and unusable.


The SO-PIN has a retry counter of 15 and can not be unblocked. Blocking the SO-PIN will prevent any further token initialization or PIN unblock.

Potentially, in case the SO PIN was ever changed, perhaps the format was wrong as in: Nitrokey HSM SO-PIN conversion.
Other problem with the PIN might be its invalid length, like here: Nitrokey HSM - keypairgen fails with 16-digit user PIN (edit: apparently only with OpenSC older than v0.16).

As a last resort, you can look at forum search - perhaps this would remind you anything:

Also please make sure you are using the latest OpenSC package, which is 0.19.

Related to this topic, is there a way for a future update/upgrade so we can be able to reset a Nitrokey HSM2 if the device is blocked or SO-PIN lost?

That feature will not be added, because it would violate a security mechanism: Initializing the device does not change device authentication, which is used for authenticating the device as 2FA and for public key attestation. Without authentication, an attacker would be able to reset the device and get full access to authentication configuration. He could then set his own password and circumvent any login mechanisms that utilize device authentication.

The PKI-as-a-Service portal uses this scheme and asserts during login, that the device is authenticated and user authentication has been performed at the device (by PIN or biometric). With that scheme, no secret PIN code or login credentials need to be stored at the server (and thus can’t get lost).

In the security model of the HSM, the SO-PIN (or Initialization Code) is the mechanisms to place the device under sole control of the security officer. He can then delegate control to the final user by setting a User-PIN (or Transport-PIN). With this delegation he relinquishes control of cryptographic material. His only capability, is to reset the device and thereby clear cryptographic material (If configured during initialization, he could as well reset the User-PIN’s retry counter or set a new PIN value, but that is for convenience only).

Hello. Just ran into this issue. Would you shortly explain why couldn’t initialization erase everything from the token, including all cryptographic material and authentication configuration? An initialized token would be as good as any other other empty token to an attacker.


Because the device authentication key and certificate is generated during production of the device (i.e. when loading the firmware). That key and certificate does not change during initialization, but it is used to authenticate the device in remote management processes (like login into the PKI-as-a-Service Portal).

If the SO-PIN is lost and thus the device can no longer be reset, then the only way to fix the situation is to update the firmware and get a new device key and certificate generated.