Moving Your PGP Key to a Hardware Token: What Changes and What Breaks

Published 28 September 2026

You generated a PGP key years ago, kept it on one laptop, and the day that laptop died you learned the hard lesson: the key lived in a file, and the file went with it. The standard answer is to put the key on a hardware token like a YubiKey, where signing and decryption happen on the device and the secret never touches your computer's memory. That answer is correct, but almost every guide skips the trade-offs. Moving a PGP key to a YubiKey changes how backups work, how key deletion works, and what happens when the token dies. Here is the honest version.

What actually moves to the key

When you run keytocard in GnuPG, the secret parts of your signing and encryption subkeys are written into the YubiKey's smartcard chip and then deleted from your local keyring. Your master (certify) key does not move. It stays wherever you keep it, ideally on an encrypted USB stick in a drawer, because the whole point of the certify key is that it rarely gets used and never gets exposed.

After the move, GnuPG keeps stub keys in your keyring, placeholders that say "the real secret is on card reader 0". When something asks to decrypt a message, GnuPG talks to the chip through the scdaemon daemon, the chip does the crypto operation internally, and only the result comes back. Malware on your laptop can request operations while the key is plugged in and unlocked, but it cannot copy the key itself and use it later. That is the entire security gain, and it is a real one.

The backup problem, before and after

Before the token, your backup was a file: secring or an exported paperkey. After the move, the file backup you made before running keytocard is still valid, because the subkeys did not change, only their location did. If you did not make that backup first, you now have a problem: the key exists in exactly one place, a chip designed to resist extraction. Losing the YubiKey means losing the subkeys permanently.

The correct order is: export your secret subkeys to an encrypted backup, verify the backup on another machine, then move to the card. This is the step most people skip and most people regret. The YubiKey is not a backup. It is the opposite of a backup: a single physical object that can go through the washing machine.

What a YubiKey 5 gives you with PGP specifically

Three slots matter. The signature slot holds your signing subkey, the encryption slot holds your encryption subkey, and the authentication slot can hold an SSH authentication key, which is how most people end up using PGP-backed SSH login. The OpenPGP application on the card is accessed over CCID, so it works through the same interface as any smartcard: GnuPG's scdaemon handles it, and on Linux you may need to fix udev permissions if the card is not visible as an unprivileged user.

Touch confirmation is worth turning on. With touch required for signing, a request to sign something makes the YubiKey blink and wait for your finger. Malware on the machine can ask for a signature, but it cannot press the sensor. The trade-off is honest: every operation needs you physically present. If you sign dozens of git commits an hour, you will either disable touch or learn to live with tapping constantly.

What breaks

Multiple machines stop just working. If you previously copied your keyring between a desktop and a laptop, that arrangement is over. The key is on the token, so the token has to be plugged into whichever machine you are using, and each machine needs the stub keys and the public keyring set up. This is friction by design. If it annoys you, that is the security model working.

Automated decryption dies. Anything that decrypts mail or files unattended, a fetchmail loop, a backup script that decrypts before upload, cannot do its job if the operation needs the card and possibly your PIN. The standard fix is to keep a separate non-token encryption subkey for the machine-bound automation, or to restructure the automation so decryption happens where a human is present. Do not work around it by leaving the key unlocked with cached credentials; that defeats the point.

Non-GnuPG software may not see the key at all. Pretty Good Privacy implementations vary wildly in smartcard support. GnuPG on Linux, macOS and Windows handles CCID fine. Mobile is worse: support on iOS and Android exists but is patchy and app-specific, so test before you commit. If your workflow requires decrypting on a phone, check how PGP works on phones first.

Key deletion is now real. In software, "deleting" a subkey usually means revoking or re-exporting. On a YubiKey you can genuinely destroy a subkey with a few clicks in the OpenPGP card admin menu, and it is gone from the chip with no recovery. Convenient for hygiene, catastrophic if done by accident on the only copy.

The PIN, the Admin PIN, and the retry counters

The OpenPGP card has two codes. The user PIN unlocks signing and decryption, defaults to 123456, and after three wrong attempts blocks. The Admin PIN (default 12345678) is needed to change anything structural, including unblocking the user PIN. Change both defaults the moment you set the card up; a YubiKey shipped with default PINs is not protecting anything.

The retry counters are stored on the chip and there is no master override. Three wrong Admin PIN attempts and the card locks itself into a state where the only fix is a full reset that destroys the keys. Write the PINs down somewhere physical. A password manager works too, but the failure mode you are planning for is "the machine is unavailable", so paper is not a stupid answer.

When not to bother

If your threat model is "my laptop gets stolen", full-disk encryption plus a passphrase-protected keyring already covers most of it, and a stolen YubiKey plugged into a stolen laptop is not obviously safer than a strong passphrase. The token earns its keep against the adversary who can run code on your machine while you use it: keyloggers grab passphrases, but they cannot export a key that never leaves the chip.

If you decide to go ahead, the sequence is: fresh backup, verify backup on a second machine, change PINs, keytocard for signing and encryption subkeys, then test signing, decryption and revocation of access on the old keyring copy. If any step fails, you still hold the backup. If you are starting from a mess of old keys instead of one clean key, read why you have more keys than you think before adding a YubiKey to the pile.

Done in that order, the move takes under an hour and converts your key from a file any malware can steal into an object that only works when you are physically there. The day the token dies, you will be annoyed. You will not be locked out, and that difference is the whole game.