Every few weeks someone turns up asking the same question in some form: my PGP key expired, or my laptop died and took my secret key with it, or I revoked a key by accident. What now? The answers are mostly reasonable, but a few of them surprise people, and the surprises tend to matter exactly when the stakes are highest. This is a practical map of what expiration, revocation and key loss actually do to your encrypted mail.
What expiration really does
An expired PGP key is not a dead key. Expiration is a flag the key owner sets when creating or editing the key, and its real job is defensive: it limits how long your public key keeps circulating with your stamp of approval if you vanish. If you set a key to expire in two years and then drop off the internet, the old copies floating around on keyservers eventually mark themselves expired, and people who fetch them get a warning before encrypting to an address you may no longer control.
What expiration does not do: it does not lock you out. If you still hold the secret key, you can extend the expiration date at any time, even after the key has already expired. The signature you use to push the new date is timestamped now, which means anyone who sees the update can tell the key was revived rather than never expired, but the key goes right back to working. GnuPG will do this with gpg --edit-key and the expire command in under a minute.
Decryption is the part people get wrong. A message that was encrypted to your key while it was valid can still be decrypted after the key expires. Expiration applies to future use, not to material already protected by the key. So if someone tells you their old mail is unreadable because the key expired, the actual problem is something else: a missing secret key, a different key, or a mail client refusing on policy grounds rather than the cryptography failing.
The practical habit worth copying from serious users: set an expiration of one or two years, and renew it before the date passes. An unexpired key you actively maintain signals liveness better than a no-expiration key nobody has touched since 2019. If you are setting up a new keypair, you can generate one in your browser with the EasyPGP tool and pick the expiration at creation time.
Revocation certificates: powerful, and mostly misunderstood
When you create a key, most software also offers to generate a revocation certificate. It is a signed statement that cancels the key, and it exists so you can kill a key even after losing the secret key: you keep the certificate somewhere safe, and publish it if the key is ever compromised. Publishing it is just uploading it to a keyserver or handing it to the people you correspond with. Every conformant PGP implementation that sees it will refuse to encrypt to the key.
Two things surprise people. First, revocation is permanent. There is no un-revoking a key, even with the secret key in hand. If you publish a revocation certificate by mistake, the only fix is a new key and a round of re-verification with everyone who had the old one. Second, most revocation certificates are marked with a generic reason, "key compromised or superseded", even when the real reason was mundane. Recipients cannot tell a catastrophic compromise from a spring clean. If you revoke deliberately, use the proper reason codes and write a short explanation; recipients will see it.
Where should the certificate live? Not next to the key. The entire point is to survive the loss of the machine holding the secret key, so the certificate sitting in the same backup is worthless. A password manager, a printout in a drawer, or a USB stick at a different address all work. The certificate is not secret in the encryption sense, but publishing it destroys the key, so treat it as a self-destruct switch rather than a document.
Losing the secret key
This is the hard one, so it deserves plain language. If the secret key is gone, every message encrypted to that key is gone with it, permanently. PGP has no recovery path, no escrow, no authority to appeal to. That is not a limitation of a particular app; it is the design. Anyone who could recover your encrypted mail without your key could recover it without your permission.
Check the obvious before mourning. Old backups, a phone that still has the key in a mail app, an export you emailed yourself years ago, a paper copy of the key with its passphrase. Partial destruction sometimes helps: if you have the key but forgot the passphrase, there is no brute-force tool worth the electricity for a strong passphrase, but weak passphrases can sometimes be recovered with dictionary attacks, and that is a job for a specialist rather than a guarantee. If the key had subkeys and you lost only one, the surviving subkeys may still decrypt some mail.
After that, the recovery is procedural, not cryptographic. Revoke the old key using the certificate you hopefully stored elsewhere, publish the revocation, generate a new keypair, and tell your correspondents to use it. Before you send anything sensitive to a new contact, the burden flips around: read our guide on verifying a PGP key before you trust it, because from their side your new key is an unknown quantity until they check your fingerprint.
Keyservers, updates and why people see stale keys
Most confusion about expiration in the wild comes from stale copies. Public keys get around: keyservers, email signatures, web pages, address book apps that cache a key forever. If someone encrypts to an expired copy of your key, the failure is on their side, and the fix is refreshing from a current source. If you extend your key's expiration, propagate the update the same way you originally shared the key, because keyservers will carry the new signature but cached copies in mail clients will not refresh themselves.
The modern keyservers complicate this. The old SKS pool had deletion problems, and the replacements, like keys.openpgp.org, verify identity by email before linking an address to a key, and they do not distribute third-party signatures at all. The effect is that key discovery is less automatic than it used to be, and a deliberate refresh is more often on you. That is a mild annoyance and a genuine improvement in hygiene at the same time.
A sane personal policy
You can avoid nearly every scenario above with four habits. Set an expiration date and extend it yearly while you still have the key, which doubles as proof of life. Store the revocation certificate somewhere separate from the key, in a form you will actually find in three years. Keep an encrypted export of the secret key with your serious backups, because the passphrase alone is not the key. And when you retire a key, revoke it deliberately with a stated reason instead of letting it rot, so nobody encrypts to a mailbox you no longer read.
None of this is hard, and all of it is boring, which is the correct shape for key hygiene. The people who lose encrypted mail are rarely the ones who did something exotic. They are the ones who never exported the key, never stored the certificate, and discovered the difference on the worst possible day.