How to Back Up a PGP Key So It Survives a Lost Laptop, a Forgotten Passphrase and a Decade

EasyPGP · Published 7 September 2026

← Back to blog

Most people who set up PGP make a backup of their key once, on the same laptop the key lives on, and consider the matter closed. Then the laptop dies, or gets stolen, or the disk fails, and the backup turns out to be encrypted with a passphrase nobody remembers, or it was never actually exported with the secret key at all, just the public half. The key is gone, and with it every encrypted message ever sent to it.

The failure that hurts most is the quiet one: the key still works, so nothing looks wrong, but the one place a revocation certificate was supposed to be stored never received it. If your laptop is gone, your identity on the keyserver network is unrevokable. Anyone who extracts the secret key can impersonate you indefinitely, and you cannot publish proof that the key is dead because the revocation certificate lived next to the key it was meant to revoke.

A revocation certificate is not the key. It is a pre-signed message that says "this key should no longer be trusted", generated at key creation time. You can generate one later, but only while you still control the secret key. That is the whole trick: the certificate proves key compromise without the key, so it must be stored away from the key, on paper or on a device that never touches the laptop. When you create a new key pair, the certificate appears as a file ending in .rev. Print it, or write the contents into your password manager. Do not store it in the same encrypted volume as the key and call it a day.

Three copies, two formats, one off-site

The standard pattern for the secret key itself is the same 3-2-1 rule used for any backup, with one PGP specific addition: at least one copy must be printable. An offline paper copy of the secret key, printed as a QR code or base64 text, survives dead USB ports, forgotten passphrase managers, and twenty year format drift. Tools exist for exporting a key to paper; even a plain base64 dump of the ASCII armored export, printed in a monospace font and stored with the revocation certificate, is enough to rebuild the key on any machine a decade from now. Laptops and encrypted volumes are convenient; paper does not need a driver.

The passphrase is the second half of the backup. A secret key export is only as recoverable as the passphrase you can recall under stress, five years later, on a machine you do not own. If the passphrase lives only in your head, your key backup is a dead letter. Store it in a password manager you trust, and make sure someone you trust knows where the recovery path for that manager is. If the key protects anything that matters after you are unreachable, that instruction is part of the backup too.

Test the restore, or you have not backed up

The step almost nobody does: restore the key onto a clean machine and confirm it decrypts something. A backup verified only by the existence of a file is a hope, not a backup. The test is five minutes. Export the secret key, move it to another computer or a fresh user account, import it, and decrypt one old message you kept for exactly this purpose. If the import succeeds but decryption fails because the subkey is missing, you have found the classic trap: exporting only the primary key while the encryption subkey, which is what actually decrypts mail, stayed behind. Export with --export-secret-keys, not --export, and the subkeys come along.

One more thing worth doing while you are in there: set an expiry date on the key, even a far one, and diarize the renewal. An expiring key that you control gives you a scheduled checkpoint to re-test the whole recovery chain, and it limits the damage of a lost key, because a key nobody renews stops being trusted by well configured peers automatically. Loss, theft, forgotten passphrases and dead disks are not edge cases; they are the normal failure modes of long-lived keys. The people who still have their PGP identity after ten years are not the careful ones. They are the backed up ones.

Where not to store it

A short list of places secret keys keep ending up by accident: unencrypted cloud sync folders, email drafts to yourself, screenshots, git repositories, and the Downloads directory of a machine shared with family. A secret key in a synced folder is a secret key on every device that syncs, including the phone that gets left in a taxi. If you want the key available on multiple machines, export it deliberately to each one with full disk encryption enabled, rather than letting a sync tool decide the blast radius. And after any export to a USB stick, wipe the stick properly or keep it in the same physical safe as the paper copy; a half forgotten USB key in a drawer is the single most common way old keys resurface in the wrong hands.

The quiet rule underneath all of this is separation. Key on the laptop, passphrase in the manager, paper copy and revocation certificate in the safe, one tested restore every year or two. Each piece somewhere sensible, none of them together. Break that rule anywhere and the backup you think you have becomes the leak you did not plan for.

Related on this blog

If the key is already gone, read what expiration and revocation actually do, and for the mechanics of moving a key between machines, moving your PGP key to a new computer without breaking anything.