Rotating Your PGP Key Without Losing Old Encrypted Mail

Published 2 October 2026

You generated a PGP key five years ago. The subkeys have accumulated, the passphrase is one you used everywhere in 2021, and the primary key sits in a keyring file that has been copied across three laptops. Everything still works, which is exactly the problem: the longer a key works, the more encrypted mail piles up behind it and the scarier the idea of touching it becomes. Key rotation done properly takes an afternoon and does not cost you a single old message. Done wrongly, it locks you out of years of correspondence. Here is the version that works.

What rotation actually means

Rotation is not deleting your old key and generating a new one. It is a staged handover: create the new key, connect it to the old one, move correspondence over, and retire the old one on a schedule you control. The connection point is the signature system. Your new key signs your old key and your old key signs your new one, so anyone who trusted the old key can verify the new one through a chain rather than through some out-of-band promise that "this is really me".

The order matters because each step protects you if the next one goes wrong. New key first. Cross-signatures second. Publication of the new key third. Only then do you start moving people over, and only at the very end do you revoke the old one.

Step one: build the new key deliberately

Generate the new key on a machine you trust, with a fresh passphrase that exists nowhere else. RSA 4096 or one of the elliptic curve options both work; the choice matters less than the hygiene around it. Give the key a creation date you can remember, add the UID you actually send mail from, and set a sensible expiry, two years is a common choice, because an expiring key that you keep renewing is a safety net: if you vanish, the key dies on schedule instead of living forever.

Before anything else, make and verify the backup: export the secret key to an encrypted medium, and test the restore on a second machine. If you skip the verification, you have made a ritual, not a backup. The same discipline is the first step in moving a key to a hardware token, and for the same reason: the failure mode you are guarding against is one copy and no exit.

Step two: cross-sign and publish

Sign the new key with the old one and the old one with the new. If your correspondents verify keys before use, and you should hope they do, the cross-signature is what lets them accept the new key without meeting you. Publish the new key wherever the old one lives: the keyservers, if you use them, or better, Web Key Directory on your own domain, which serves your key automatically to anyone whose mail client looks it up.

Do not revoke anything yet. Both keys are valid simultaneously, and that is the design: during the transition your correspondents can encrypt to either, and every message encrypted to the old key still opens.

Step three: move the correspondence

Here is the fact that makes the whole operation safe: encrypted mail you have already received stays readable forever, because it was encrypted to your old secret key and the old secret key still works. Rotation does not touch stored mail. What changes is new mail: each correspondent has to fetch your updated public key and start encrypting to the new one, and until they do, mail keeps arriving on the old key.

The practical chore is prompting people. Most modern mail clients refresh keys automatically if you publish via WKD; manual key exchanges need a short signed note: "encrypt to the new key from now on, the old one retires on DATE". Set that retirement date a couple of months out. If someone misses it entirely, their message bounces or arrives unencrypted depending on their client, and the fix is one line of correspondence.

Step four: retire the old key properly

Retirement means generating a revocation certificate if you never made one, publishing the revocation, and then, separately, archiving the old secret key somewhere cold and offline. The counter-intuitive part: do not destroy the old secret key on retirement day. The revocation tells the world the key must not be used for new mail; the archived secret key is what lets you open the decade of old mail you already have. Store it encrypted, offline, labelled with the passphrase, and treat it like a paper document rather than like a live credential.

The day you can genuinely destroy the old key is the day you no longer need the mail it decrypts. For most people that day never arrives, and that is fine.

What rotation does not fix

Rotation limits the blast radius of a compromised key: the stolen key stops working the moment the revocation propagates, and everything before it is unaffected. It does not fix a compromised machine, because whatever took the old key takes the new one too. It does not retroactively protect anything: mail encrypted to the old key was always only as safe as the old key. If you suspect the key is already stolen, the order changes: revoke immediately, publish the revocation now, and hand over to the new key under the assumption that the thief is reading your transition messages.

If what you actually have is not one tired key but a pile of accidental duplicates, that is a different problem, and we walked through it in consolidating multiple keys for one identity. Do the consolidation first, then rotate the survivor; rotating four keys into four new keys just relocates the mess.

Done in this order, rotation is uneventful, which is the goal. The new key takes over quietly, the old one retires on schedule, and your mail from 2021 still opens on the machine you use in 2031.