Moving Your PGP Key to a New Computer Without Breaking Anything

Published 3 September 2026

You got a new laptop, and your PGP key is on the old one. This is the moment people make the two classic mistakes: they either delete the key from the old machine before confirming the new copy works, or they move the whole secret key onto a laptop that will travel through airports and coffee shops for the next three years. Both are avoidable. Here is the full procedure, with the checks you should run at each step.

What you are actually moving

A PGP key is really a small bundle: a primary key pair (certification and signing), one or more subkey pairs (usually one for encryption, sometimes one for signing), user IDs with your name and email, and signatures from other people confirming those IDs. When people say "export my key", they usually mean exporting all of that, secret parts included. The secret material is what an attacker needs to decrypt your mail and forge your signatures, so treat the export file the way you would treat a password vault: it never goes over email, cloud drives in plaintext, or messenger apps.

Step 1: Export on the old machine

Find your key ID first:

gpg --list-secret-keys --keyid-format long

You will see a line like sec ed25519/ABC1234DEF56789 2024-03-12 [SC]. The part after the slash is your long key ID. Export everything:

gpg --export-secret-keys --armor ABC1234DEF56789 > oldmachine-private.asc
gpg --export --armor ABC1234DEF56789 > oldmachine-public.asc

The private file will ask for your passphrase, which is correct: an export that does not prompt would mean your key is not passphrase protected, which is its own problem worth fixing today.

Step 2: Move it securely

The safe options, in order of practicality: a USB stick used only for this transfer, then wiped; an encrypted archive (age, 7z with AES, or an encrypted disk image) copied over your network; or simply an encrypted drive you carry yourself. What disqualifies a method is not the encryption on the file but what happens after: a file named private.asc left in a Downloads folder or synced by Dropbox is a leak waiting for a date. Move it, import it, then shred the copy:

gpg --import oldmachine-private.asc
shred -u oldmachine-private.asc

On Windows, shred does not exist; delete it and empty the recycle bin, then accept the residual risk or use a wiping utility. On macOS, rm -P overwrites before deleting.

Step 3: Verify the new copy before touching the old one

This is the step everyone skips, and it is the one that matters. On the new machine, check that the secret key is fully present, not just the public half:

gpg --list-secret-keys --keyid-format long

You want sec and ssb lines, not just pub and sub. Then set trust so GPG stops warning about your own key:

gpg --edit-key ABC1234DEF56789
gpg> trust   # pick "ultimate" for your own key
gpg> save

Finally, run a real functional test. Decrypt an old message you know the contents of, and if you sign things, make a test signature and verify it:

echo test | gpg --clearsign -u ABC1234DEF56789
# then verify the output block
gpg --output - --verify signed-file

If decryption fails on the new machine with "no secret key" while the listing shows ssb, the most common cause is a smartcard or YubiKey configuration: if the key was moved to a hardware token on the old machine, the secret key no longer exists in software anywhere, and the token is the thing you actually carry over. Plug it in and run gpg --card-status.

The better pattern: move only a subkey, keep the primary offline

If your threat model includes laptop theft, do not copy the primary secret key at all. The standard setup: keep the primary key (the [SC] one) on an encrypted USB stored at home, and put only the encryption subkey [E] on the laptop. You can still read all your mail on the road, but a stolen laptop cannot be used to sign documents, sign other people's keys, or add new user IDs to your identity. The trade-off is honest: to sign anything you need the USB stick. Most people who try this keep a cheap dedicated stick with the primary on it and discover they sign things rarely enough that the friction is worth it.

What not to do

Do not publish a new key just because you changed computers. Your key's value is partly its age and the signatures it has collected; a fresh key starts from zero and makes correspondents wonder if they are being targeted by a key substitution. Do not keep copies of the secret key on five machines "just in case"; every copy is an attack surface. Two, maybe three locations, all accounted for.

After the move

Once the new machine decrypts and signs correctly, remove the secret key from the old laptop before selling or handing it down:

gpg --delete-secret-key ABC1234DEF56789
gpg --delete-key ABC1234DEF56789

Reinstalling the OS also destroys it, but a handed-down laptop with an intact gpg keyring and a guessable login password has burned people before. Check our guide on key expiration and revocation for what to pre-print and store, and if you have never tested a full cycle, the difference between signing and encrypting article covers what each operation actually needs from your keyring.