Multiple PGP Keys for One Identity: Why You Have More Keys Than You Think

Published 20 September 2026

You generated a PGP key years ago. Then you made another on a new laptop because you forgot the passphrase of the first. Then your work email needed one, and a colleague uploaded "your" key to a keyserver on your behalf, and now a search for your own email address returns four keys and you are not sure which one is current. This situation is extremely common and almost never explained anywhere. Here is what is actually going on, and what to do about it.

A key ID is not an email address

Nothing in PGP binds an email address to exactly one key. An address on a key is just a UID, a user ID string, and a single key can carry many of them while a single address can appear on many keys. When someone imports a key "for your address" from a keyserver, they get whichever key the server's search ranked first, which may be your 2014 key with the expired UID and no self-signature updates, not the one you use today.

This is why the fingerprint check exists and why every serious guide, including ours on verifying a PGP key before you trust it, insists on it. The fingerprint identifies one specific key. The email address identifies a person, loosely. Encrypting to "the key that came up when I searched your email" is how messages end up locked to a key whose passphrase nobody remembers.

How the pile of keys accumulates

In practice people collect duplicate keys four ways:

• Forgotten passphrase, new key. The most common origin. The old key is still perfectly valid on every keyserver, it just cannot be used by you anymore, and correspondents keep finding it.
• Device-specific keys. A deliberate, legitimate pattern: a primary key offline and separate subkeys or full keys per laptop and phone. If you followed our advice on running PGP on your phone, you already have this arrangement. It looks like duplicates but is actually structure.
• Job change or reissue. A company provisions a key for your corporate address, you had a personal one on the same address before, both float around.
• Someone else uploaded yours. Keyservers accept any public key for anyone. A well-meaning colleague can publish an old or malformed copy of your key and there is no removing it later, keyservers are designed to be append-only.

Which key is the real one?

Yours is whichever key you still hold the secret half of and can actually use. Check with gpg --list-secret-keys on every machine you own. That output is the truth; a keyserver listing is not. If two machines show two different primary keys for the same UID, you have two live identities and need to consolidate deliberately rather than let correspondents choose for you.

Consolidating without breaking anything

The clean sequence, in order:

1. Pick the survivor. Usually the newer key, or the one with the most signatures. If the old key has valuable third-party signatures you want to keep, you can sign the new key with the old one instead of discarding it cold.
2. Add the new key's fingerprint to the old key's record. The practical way people signal migration is a signed statement from the old key pointing at the new fingerprint, published where correspondents will see it.
3. Revoke or expire the old key if it is truly dead. A revocation certificate is generated at key creation for exactly this moment. Publishing the revocation tells every keyserver and every correspondent's copy of the old key to stop trusting it. We cover generating and storing that certificate in the key expiration and revocation guide.
4. Update the places your key is advertised. Email signature, website, WKD record if you run one, profiles. Correspondents who fetch by fingerprint get the right key regardless, but everyone else follows your advertised link.
5. Test before you rely on it. Send yourself an encrypted message to the new key, decrypt it, sign something and verify the signature. The same verify step we recommend when moving a key to a new computer.

When NOT to consolidate

If your "duplicates" are actually a primary key plus device subkeys, leave them alone. That is the recommended architecture: one identity, many usable decryption stems, and the crown jewel secret kept offline. Merging those into a single fat key on your phone would make security worse, not better. The test is simple: multiple primary keys with the same UID is a mess to clean up. One primary key with several subkeys is a plan working as intended.

The one habit that prevents all of this

Give correspondents your fingerprint, not your email address, as the way to fetch your key. "Get my key from keys.openpgp.org, fingerprint starts 9ABC" beats "search my email" every time. The address search is what surfaces the 2014 zombie key; the fingerprint cannot return the wrong key by design.

Once the right key is in play, you can encrypt a message to it in the tool and confirm the recipient can decrypt. If you are starting fresh rather than cleaning up, the walkthrough for sending encrypted email with PGP for free covers key generation properly the first time.