The locked-out feeling is a one-time lesson. Learn it once, fix it forever.

The master backup rule

Wallets on this site split into a few backup models: seed/key-based wallets (the phrase — plus the passphrase if you added one), encrypted-file wallets (wallet.dat, keystores, vaults), private-key/paper cases (BIP38, brain wallets) and hardware wallets (seed held by the device). So the number-one rule depends on what your wallet actually is:

• Write the seed on paper — two copies, two different physical locations (home + a safe, a trusted relative, a bank box).
• Or use a metal backup (stamped steel/copper) for fire and flood protection — paper burns; your access should not.
• Never store the seed only digitally — not in a screenshot, not in a notes app, not in the cloud, not in an email to yourself. Digital copies are how seeds get stolen, not how they get saved.
• If you must have a digital copy, put it in an encrypted file whose password lives in your password manager — and treat that file as a third, emergency-only backup.

Related reading: what the seed actually is, and the passphrase on top of it — a password that can lock the derived addresses.

The wallet-file rule

The seed restores the wallet, but the encrypted wallet file is what offline recovery actually runs against — wallet.dat, an Ethereum keystore JSON, an Electrum file, seed.seco, a .keys backup. If you still have the file, the password stays testable offline — a recovery path that exists even when the seed is gone, as long as the password was human-chosen or you have clues. So the files get the same treatment as the seed:

• Copy the file read-only to two offline places — an external drive and a USB stick kept with your paper backup. Mark both copies read-only so no app can migrate or rewrite them.
• Keep the original format untouched — never let a newer wallet version “upgrade” or migrate your only copy; a migrated file can use different encryption that no longer matches your clues.
• Back up old exports too — .aes.json exports, MultiBit .key backups, keystore JSONs from apps you no longer use. Old formats stay recoverable; the app that made them may not.
• Log what each file is — wallet name, file type, version, and which password unlocks it. A file without its password is a half backup; a password without its file is a dead end.

Protect your wallet files covers the exact five moves; this is the same rule from the prevention side. Not sure which files exist? Find your wallet file first.

Multisig wallets: access depends on the required number of keys (for example 2-of-3), so there is no single seed to protect. Back up each participating key or seed according to its role, and keep the list of who holds the other keys current — a multisig wallet is only as recoverable as the combination you can still assemble.

The password rule

Wallet passwords — the ones that unlock encrypted files like wallet.dat or an Ethereum keystore — should be generated and stored by a password manager, never invented in your head:

• Random 16+ characters in a manager are impossible to recover if lost — but you will not lose them, because the manager remembers them. (See the feasibility arithmetic to understand why this trade-off is the right one.)
• Export and back up your manager’s vault the same way you back up the seed: two places, tested.
• Write down which manager you use and its master password location in your password journal. The single biggest “forgotten password” failure is forgetting which manager held it — the search guide exists for exactly this.
• Note which password belongs to which wallet or file — and whether you added a passphrase to the seed. The “one more thing you added” is the easiest thing to forget later.

And the moment you recover a forgotten one — on this site or anywhere else — put it in the manager before you do anything else. That single step is what makes the recovery the last time.

The passphrase rule — the 13th/25th word

Some wallets let you add a passphrase on top of the seed — the “25th word” (or “13th word” on a 12-word seed). It is not part of the seed. It is a password you chose, and it changes which addresses the seed derives.

• Store the passphrase in your password manager — it is a password, not a seed, so a manager is exactly where it belongs.
• Write it in your password journal too, with a note of which wallet it belongs to. “I probably used a passphrase” is one of the most common dead ends we see.
• Test it in the annual restore — restore with the seed plus the passphrase and confirm you land on the same address.

The full mechanics — and when a forgotten passphrase is recoverable — are on the seed phrase passphrase guide.

Hardware wallets and PINs

Hardware wallets (Ledger, Trezor, Coldcard, …) are excellent prevention — but only if you understand their two layers:

• The PIN is temporary and is never the backup — but failed-PIN behavior is model-specific: devices may wipe, lock or permanently brick after their configured attempt limit (some, like Coldcard, can brick). Where the model allows, you restore from the seed.
• The seed phrase from the device’s setup card is the real backup. Store it per the master rule above — ideally before you need it.
• Write down the model and firmware setup date in your journal; it helps if you ever need to reconstruct what you set up.
• If you set a passphrase on the device (a hidden wallet), that passphrase is a second key — store it per the passphrase rule above, or the seed alone opens an empty wallet.

The restore test (once a year)

1. 1

   Pick a safe moment

   When you can be offline and undisturbed. This is a test, not a repair.

2. 2

   Restore the layers you rely on

   Software-wallet backup: test in an appropriate isolated/offline environment. Hardware-wallet backup: use the manufacturer’s on-device recovery check or dry-run feature where available, or a spare/wiped compatible hardware wallet — do not enter a hardware-wallet seed into a software wallet or an ordinary computer merely to test the backup. Add your passphrase if you use one, and separately open a copy of the wallet file with its password. Each layer you rely on must land you on the address you expect.

3. 3

   Confirm, then wipe the test wallet

   Delete the test wallet afterward. You proved the backup works without leaving a live copy around.

4. 4

   Update your journal

   Note the date and any changes (new devices, new wallets). Prevention is a habit, not a one-off.

An emergency plan for the people you trust

The most common permanent loss is not theft — it is a person dying or incapacitated with no one able to reach the funds. A simple sealed envelope with your seed, kept with a trusted person or lawyer, plus copies of your encrypted wallet files and a note listing which wallets, managers and passphrases you use, turns a tragedy into a solvable administrative task. Weigh this against the added attack surface — and never write down which bank or exchange the seed connects to on the same paper. Do not put every access component in one place: consider splitting information across secure locations and documenting where to find help, without storing seed phrases, passphrases and wallet-file access instructions together unless you fully understand the risk.

Already locked out? Different page.

If you are reading this after losing access, skip the prevention — go to the first 24 hours and protect your wallet files immediately. Then come back and build the backups once you are back in.