Rotating a PGP key — when, why, and the migration workflow

A PGP key is meant to last. Long-lived keys accumulate trust signatures, get cached by recipients, and form the stable identity that makes PGP useful for long-term correspondence. But there are situations where rotation is the right answer — and the migration is annoyingly hands-on if you have not thought it through.

When to rotate

• The private key was exposed (e.g. unencrypted backup leaked, lost laptop without disk encryption, malware on the device).
• The passphrase is suspected to be weak or has been observed (shoulder-surfing, keylogger possibility, written down somewhere accessible).
• The key uses a deprecated algorithm — RSA-1024, DSA-1024, or older. Modern guidance is RSA ≥ 3072 or Curve25519 / P-384.
• The key has a hard expiry coming up that you cannot or do not want to extend.
• You are reorganising identity (changing primary email, splitting personal and work).
• A subkey was compromised — but here you rotate just the subkey (see "Subkey generation" article), not the primary.

Rotation purely for paranoia ("it has been a long time since I rotated") is usually unnecessary if the key is sound and uncompromised. Modern keys with strong passphrases and reasonable algorithms have no expiry-by-design — they fail when something specific goes wrong.

The two-key transition

You cannot just delete the old key. Anything encrypted to it stays encrypted to it forever. The migration is overlapping, not cutover:

1. Generate the new key pair with the [Generate Keys tool](https://pgptool.dev/generate). Use Curve25519 unless you have a specific compatibility reason for RSA.
2. Sign the new public key with the old key. This produces a "rotation certificate" — a signature from the old key vouching that the new key is also you.
3. Publish the new public key (keyserver, your website, whatever channel you used for the old one). Keep the old public key published too — recipients still need it to encrypt the old archive.
4. Send a signed announcement from the old key declaring the rotation, the new fingerprint, and the date. People who already have your old key in their keyring will trust this signed message.
5. For a few weeks, accept incoming messages on either key. Slowly stop using the old key for outgoing traffic.
6. Once correspondents have updated, revoke the old key. The revocation propagates through keyservers and tells the world to stop encrypting to the old key.
7. Keep the old private key archived, encrypted offline. Do NOT delete it — old encrypted messages are unrecoverable without it.

Decrypting old messages after rotation

Anything encrypted to the old key needs the old private key. You have three options:

• Archive: keep the old private key + passphrase in encrypted long-term storage. Pull it out when you need to read a 5-year-old encrypted email.
• Re-encrypt: decrypt the archive with the old key once, re-encrypt with the new key, store. Convenient but a one-time operational chore.
• Abandon: if you do not need the archive, delete the old private key. The old encrypted messages become unreadable forever.

Most people pick the archive route — it is cheap (one encrypted file), reversible, and keeps your options open.

If the old key was compromised

The workflow above assumes a clean rotation. If the old key was actually exposed, the announcement-and-cross-sign approach is wrong — an attacker with the old key can also sign a fake "I rotated to this new key" message. Instead:

• Publish the revocation certificate immediately. (You have one because you generated it when you generated the original key — see the "Backing up PGP keys" article.)
• Generate a fresh key, but do NOT sign it with the compromised key — it carries no trust.
• Re-establish trust out-of-band: contact correspondents directly, in person if possible, by phone otherwise, and confirm the new fingerprint.
• Treat any messages encrypted to the old key after the compromise date as potentially exposed.