Backup Yubikey

Posted on 2 2026

This page exists because losing your only Yubikey is genuinely unpleasant. Depending on how far through this series you have gone, a lost or damaged Yubikey without a backup could mean: no SSH access to your servers, no GPG signing or decryption, no LUKS disk unlock without a recovery key, and no desktop login if PAM is configured to require the key. That is a bad afternoon.

The solution is simple and should have been in place before you moved any key material to hardware: a second Yubikey, configured identically to the primary, stored somewhere physically separate. This page covers how to set one up.

What can and cannot be backed up

This is the most important thing to understand about Yubikey backup, and it differs from what most people assume.

GPG subkeys cannot be cloned from the card. When you ran keytocard in the GPG section, the private key moved to the card and the on-disk copy became a stub. It is not possible to extract the private key from the Yubikey. The only way to load the same GPG keys onto a second Yubikey is from the offline backup created during key generation, before keytocard was run.

PIV keys cannot be cloned from the card. Keys generated directly on the card using ykman piv keys generate are non-exportable by design. If you generated the PIV key on the card, you cannot put the same key on the backup Yubikey. You can load the same certificate (the public half) and generate a new key, which means the backup key will have a different private key but can be enrolled separately on servers and services.

FIDO2 credentials cannot be cloned. Each registration of a FIDO2 key produces a unique credential tied to that specific device. The backup Yubikey must be registered separately with each service.

U2F PAM mappings are per-key. The pamu2fcfg registration in the PAM section produces a mapping specific to the key that was registered. The backup key must be added to the same mapping file using the -n append flag, which was covered in the PAM section.

What this means in practice: setting up a backup Yubikey is not a clone operation. It is a parallel setup. The backup key gets the same GPG subkeys loaded from the offline backup, its own PIV keys generated fresh with the same certificates loaded, and separate FIDO2 and PAM registrations added alongside the primary key.

What you need

  • Your second Yubikey 5 (same model as the primary)
  • Your offline backup storage (encrypted USB drive with the GPG private key export)
  • Access to the offline backup passphrase
  • KeePassXC open with the PIV management key, PIN, and PUK for the primary key as reference
  • Time: allow an hour for a complete setup without rushing

Step 1: Configure the OpenPGP application

Set PINs

Open card edit mode with the backup Yubikey inserted:

gpg --edit-card

gpg/card> admin
gpg/card> passwd

Change the User PIN from 123456 to the same PIN used on the primary key. Change the Admin PIN from 12345678. Set the Reset Code. Use the same values as the primary key for consistency, so you only need to remember one set of credentials across both cards.

gpg/card> quit

Import the private key from offline backup

Mount your encrypted offline storage and import the GPG private key backup:

gpg --verbose --import-options restore --armor \
    --import /media/${USER}/SafeStorage/OpenPGP/${GPGKEY}.private.asc

gpg --verbose --import-options restore --armor \
    --import /media/${USER}/SafeStorage/OpenPGP/${GPGKEY}.asc

gpg --verbose --import-ownertrust \
    < /media/${USER}/SafeStorage/OpenPGP/OwnerTrust.db

Verify all three subkeys are present and available:

gpg --list-secret-keys $GPGKEY

All subkeys should show as ssb without the > stub indicator, confirming the private key material is back in the local keyring temporarily.

Move subkeys to the backup card

Follow the same keytocard process as for the primary card. With the backup Yubikey inserted:

gpg --edit-key $GPGKEY

gpg> key 1
gpg> keytocard
# Select signature slot (1)
gpg> key 1
gpg> key 2
gpg> keytocard
# Select encryption slot (2)
gpg> key 2
gpg> key 3
gpg> keytocard
# Select authentication slot (3)
gpg> save

Verify the result:

gpg --card-status

All three slots should show the correct key fingerprints.

Enable touch confirmation

ykman openpgp keys set-touch sig on
ykman openpgp keys set-touch enc on
ykman openpgp keys set-touch aut on

Enter the Admin PIN when prompted.

Remove the private key from disk again

The private key was temporarily back on disk during this process. Remove it again, leaving only the card stub:

gpg --export-secret-subkeys $GPGKEY > /tmp/subkeys.gpg
gpg --delete-secret-key $GPGKEY
gpg --import /tmp/subkeys.gpg
rm /tmp/subkeys.gpg

Verify:

gpg --list-secret-keys $GPGKEY

The primary key should show # and all subkeys should show >, indicating they are on a card rather than on disk. GPG will now use whichever card is currently inserted.

Step 2: Configure PIV

Set the management key

Generate a new management key for the backup card. It does not need to be the same as the primary card’s management key since they are independent devices, but using a different value means tracking two management keys in KeePassXC.

MGMT_KEY_BACKUP=$(python3 -c "import secrets; print(secrets.token_hex(24))")
echo "Backup management key: $MGMT_KEY_BACKUP"

ykman piv access change-management-key \
    --management-key 010203040506070801020304050607080102030405060708 \
    --new-management-key $MGMT_KEY_BACKUP \
    --algorithm AES192

Store in KeePassXC.

Set PIN and PUK

Use the same PIN and PUK as the primary card:

ykman piv access change-pin --pin 123456 --new-pin <your-piv-pin>
ykman piv access change-puk --puk 12345678 --new-puk <your-piv-puk>

Generate a new key in slot 9A and load the certificate

Generate a new key on the backup card:

ykman piv keys generate \
    --algorithm ECCP384 \
    --pin-policy once \
    --touch-policy always \
    9A /tmp/backup-9a-public.pem

Because the PIV private key was generated on the primary card and cannot be exported, the backup card has a different private key in slot 9A. This means it needs its own certificate signed by your CA, and servers need to trust both public keys.

Submit the public key to your CA for signing, import the signed certificate:

ykman piv certificates import 9A /path/to/backup-signed-client.cert.pem
rm /tmp/backup-9a-public.pem

Add the backup card’s SSH public key to authorized_keys on all servers that use PIV for SSH:

ssh-keygen -D /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

Copy this output (which now reflects the backup card’s key) to the relevant servers alongside the primary card’s public key.

Step 3: Add to PAM U2F mappings

With the backup Yubikey inserted, append it to the U2F mappings file:

pamu2fcfg -n | sudo tee -a /etc/Yubico/u2f_keys

Touch the key when it blinks. Verify the mapping file now has both keys on the same line for your username:

sudo cat /etc/Yubico/u2f_keys

Test that the backup key works for sudo before relying on it:

sudo -k && sudo echo test

Step 4: Register with FIDO2 services

Any service using FIDO2 / WebAuthn (websites, applications) needs the backup key registered separately. Log in to each service with the primary key and look for the option to add a second security key. Most services support multiple registered keys. Register the backup key the same way you registered the primary.

Services that only allow one registered key are a problem. For those, document what account recovery looks like without the key before you rely on FIDO2 for them.

Step 5: Add to LUKS

If LUKS disk encryption was set up with the Yubikey, enrol the backup card:

sudo systemd-cryptenroll --fido2-device=auto $LUKS_DEVICE

Insert the backup Yubikey when prompted. Verify both keys are enrolled:

sudo cryptsetup luksDump $LUKS_DEVICE | grep -A3 "Tokens"

Storing the backup key

Once configured, the backup Yubikey should live somewhere physically separate from the primary. The same bag is not separate enough. Options worth considering:

  • A locked drawer at home if the primary lives in your work bag
  • A trusted family member’s house
  • A fireproof safe at a different location from the primary

The backup key has the same capabilities as the primary. Treat it with the same physical security. Someone who obtains the backup key and knows your PIN has full access to everything the primary key protects.

What to do if you lose the primary key

  1. Retrieve the backup key from wherever it lives.
  2. Swap all references from primary to backup in ~/.gnupg/sshcontrol if you were using the GPG agent for SSH. The backup card’s keygrip may differ from the primary’s stub.
  3. Order a replacement Yubikey immediately and configure it as the new backup once it arrives.
  4. If the primary key may have been stolen rather than simply lost, revoke any FIDO2 registrations for it and remove its PAM U2F mapping from /etc/Yubico/u2f_keys.
  5. For PIV: revoke the certificate that was loaded on the lost key through your CA.
  6. For OpenPGP: the subkeys on the lost card are protected by the card PIN. If the PIN is strong, the window before someone could brute-force it is effectively unlimited since the card locks after three attempts.

The backup key is not a luxury. It is the thing that makes the whole hardware key approach viable rather than reckless. One key is a single point of failure. Two keys is a security posture.