How to Back Up a Crypto Wallet Properly

What exactly must survive for recovery to work?

The secret layer, by design

There is no single answer to "what is my secret", and a wrong assumption here is one way backups break without anyone noticing. "Backing up a wallet" covers four different recovery paradigms, and the habits of one do not always transfer to another.

• Seed-phrase backup. The holder records a mnemonic, plus any passphrase and non-standard derivation path, and those words regenerate every key in any compatible wallet (BIP-39; BIP-32). Whoever holds the complete record holds the wallet.
• Hardware-device backup. A hardware wallet is replaceable; what gets backed up is the recovery material the device generated, such as a BIP-39 mnemonic or a set of SLIP-39 shares, together with a note of how the device was set up. Where the device offers a backup check, covered in the rehearsal section, it can prove the record without exposing it.
• MPC recovery. In threshold designs the key is typically generated in distributed form, so the full private key need never exist in one place and there is often no seed phrase to record. Recovery follows the product's documented process, which may ask the holder to keep a recovery factor, such as an encrypted backup or a recovery credential, or may ask for nothing beyond access to a device and an account. Holders back up key shares themselves only where the design says so.
• Smart-account recovery. Recovery is a rule written into the account's contract, for example a set of guardians who can together authorise a new signing key. What must survive is the account address, a record of the recovery rules, and enough guardians who remain reachable and willing, since guardian recovery exists to replace a lost signing key.

Multisig and Shamir shares, covered below, are distributed forms of the first two paradigms. The table below is the checklist.

Two consequences follow. First, "a seed regenerates everything" is true only for the first row. Holders of a passphrase-protected wallet who back up the mnemonic and carry the passphrase in memory alone have built a two-part secret and backed up half of it; the mnemonic alone derives a different valid wallet that does not reach the passphrase-protected one, a discovery made at the worst possible moment. Second, for MPC and smart-account wallets the useful questions are the ones the crypto wallet guide uses throughout: what combination of factors can recover access, and whether any provider holds a factor that it could withhold or lose. The answers are product facts, and the backup has to record them.

The knowledge layer

The map is what the secret is for: which wallet software or standard the material belongs to, whether a passphrase exists, which derivation path or script type the wallet used if it departed from the default, where the other shares, devices or guardians are, and, for inheritance, who should act and in what order. None of this is secret in itself, and any piece of it can end access if it goes missing; the recovery and inheritance guide treats the succession case fully. For unfamiliar terms, the crypto glossary is the companion reference. The habit is a written recovery note, stored with the backup, saying what this is and how restoration works, in words the intended reader can follow without you.

The component layer

Components apply to arrangements beyond a single seed: hardware devices in a multisig, share cards in a threshold scheme, the contact details of guardians or co-signers, and the account with the provider that holds a share in a two-party MPC design. These arrangements are designed so that losing one component is survivable; losing track of which components exist and where they are is a failure the design does not cover.

How do backup media actually fail?

Paper is where many holders start, and it is weak in exactly the ways that matter: a house fire or flood can destroy the same copy that was meant to protect against loss, ink fades, and a sheet of words is easy to throw away by mistake. As a temporary medium on the way to something better, paper works; as the permanent sole copy of meaningful value, it is a bet against entropy with the odds unpriced.

Metal backups, stamped or engraved plates sold for the purpose, address the physical fragility: they are built to withstand fire, water and time far better than paper, within the limits each product states. They do nothing for the rest of this guide: a metal plate is still one copy, still readable by whoever finds it, still mute about passphrases, derivation paths and maps. Metal suits the secret layer and nothing more.

Digital storage deserves its own paragraph because it exposes secrets remotely. A photographed seed inherits every risk of the account it syncs to; cloud documents and notes apps are searchable by anyone who gets into the account, including credential-stealing malware; and a password manager holding a raw seed converts your wallet's security into your email account's. Chainalysis, a data provider using its own on-chain attribution, counted about 158,000 personal wallet compromise incidents in 2025 affecting at least 80,000 victims (Chainalysis, 18 December 2025); the figure is an estimate, it does not separate leaked backups from other causes, and it is cited here for direction rather than precision. The discipline is a clean line: complete secrets live on physical media or inside purpose-built hardware, never in general-purpose digital storage. Digital is acceptable for the knowledge layer, the recovery note that helps a legitimate holder and merely orients a thief, and for encrypted forms designed for the purpose, understood as adding the encryption key to what must survive.

Where does a passphrase fit, and what does it cost?

What it is

The passphrase is often called the "25th word", which is a colloquial name and slightly misleading: it is not a word from the wordlist and it is not part of the mnemonic. Under BIP-39 it is an arbitrary string, mixed with the mnemonic through a key-derivation function to produce the seed; if no passphrase is set, an empty string is used, and any passphrase yields a valid seed and therefore a valid wallet (BIP-39). That property is what makes typos dangerous: a mistyped passphrase derives a different valid wallet, which may or may not hold funds and does not reach the passphrase-protected wallet, with no error to tell you so. SLIP-39 share backups carry the same property: "there is no way to verify that the correct passphrase was used" (SLIP-39). Vendor documentation is blunt about the consequence; Trezor's guide states that passphrases cannot be changed, removed or recovered, and that losing the passphrase loses the passphrase wallet and its funds (Trezor, passphrases guide).

What it buys

A burgled mnemonic alone no longer suffices, and extortion against the seed's holder meets a layer that the guide to physical security and coercion explores. The seed-generation flaw that Coinkite disclosed in some Coldcard firmware versions in 2026 shows the benefit and its limit together. Coinkite's advisory (30 July 2026, updated 1 August 2026) says that a strong, unique BIP-39 passphrase used with an affected seed "adds an independent barrier", warns that a short, common, patterned, quoted or reused passphrase may be guessable, and tells holders to migrate to a newly generated seed even with a strong passphrase (Coinkite advisory). A passphrase reduced the exposure; it did not remove it.

What it costs

The passphrase must be backed up too, separately from the mnemonic, or theft risk has been swapped for loss risk at unfavourable odds: human memory across years is not the smaller risk. The workable pattern is two locations of genuine independence, mnemonic in one, passphrase in the other, each with its half of the recovery note, so that no single burglary, fire or death takes both. Where two independent locations are impractical, a single-secret arrangement kept physically excellent has a simpler failure profile than a passphrase carried in memory as a promise; the trade-off is the holder's to weigh.

How do you remove the single copy entirely?

The single copy is the residual weakness of everything above: however good the medium, one item exists whose finder gains everything and whose destruction loses everything, unless the design itself distributes the power. The architectures themselves are compared in who holds your crypto and the comparison of hardware, software and MPC key storage; here they appear as backup strategies, and none of them is free of its own risks.

Shamir shares. SLIP-39 splits a master secret into N shares of which any T reconstruct it, with optional groups so that the owner can restrict which combinations of shareholders can recover (SLIP-39). Trezor, which implements it, uses a two-of-three scheme as its worked example and states that "the entire recovery process is done directly on your Trezor", warning users never to type recovery shares into a computer (Trezor, multi-share guide). What Shamir splits is the backup: it starts from an existing secret and divides it, and the wallet still signs with one key, so the design does nothing for a compromised signing device. Threshold-signature designs that use distributed key generation work differently, because no complete key exists to divide.

Multisig quorums. With two-of-three keys on separate hardware in separate places, a single burglary, fire or lost device need not end access, provided the other two keys and the descriptor survive. Backing up then means maintaining the descriptor, the map and the components rather than guarding one fatal object, and the design adds its own costs: coordination between signers, dependence on wallet software that can read the descriptor, and more items to track. The descriptor listing every cosigner's public key is itself backup material: without it, holding two of three keys may still not reconstruct the wallet.

Threshold signatures and MPC. These aim at a similar property by a different route. Where the design uses distributed key generation, the key shares are created jointly, the full private key need never exist in one place, and a threshold of devices or parties signs together (the mechanics are covered in threshold cryptography and MPC from first principles). For backup purposes, the holder keeps what the product's documented recovery process asks for, which may be a recovery factor and not a key share; copying or exporting shares outside that process adds an exposure the design did not plan for. Some designs allow shares to be refreshed or reissued when one is lost, so a single lost device need not end access. They add dependencies of their own: the provider's availability where it holds a share, the product's recovery process, possible implementation bugs in the signing protocol, and the coordination needed among share holders. Whether a given product delivers any of this, what the provider's share can and cannot do, and how recovery works if the provider disappears are implementation facts to verify in the product's documentation, never a label to trust.

Guardian recovery. Smart-account designs where several chosen parties must cooperate to restore access extend the same logic toward inheritance, with trade-offs the recovery guide details, including the guardians' own key hygiene and availability.

The honest note about all distributed designs: they move the burden from media to bookkeeping. Shares that nobody can locate, quorums whose second key was quietly promoted to daily use, descriptors never exported, quorum maps that die with their author: the failure modes belong to the knowledge layer, which is why the recovery note and the rehearsal below carry more weight, and why a design a household can actually operate tends to outlast a sophisticated one it cannot.

How do you rehearse recovery without exposing a live secret?

The rehearsal has to respect the same rule as storage: a complete secret entered into a general-purpose computer has been exposed, whether or not anything goes wrong that day. Three patterns keep the rehearsal inside that rule.

Rehearse before funding. For a new arrangement, the rehearsal can come first: create the wallet, back it up according to the design, wipe the device, restore from the backup alone, and fund the wallet only after the restore has worked. No funds are at risk because none are there yet, and the exercise validates the words, any passphrase, the derivation path and the recovery note's readability. Confirm the restored wallet shows the same first receiving address as the original; a different address means a different wallet, usually a passphrase or path mismatch.

Use the on-device check for an existing wallet. Some hardware wallets offer a backup-check function. Trezor's guide for the Safe 3 describes one: the words are entered on the device, "the device compares the wallet backup saved in its storage with the wallet backup you have just 'recovered'", and a match is confirmed on the device screen, with a matching guide for the Safe 5 (Trezor, check backup guides). Other vendors' equivalents, where they exist, are described in their own documentation. This proves the written words without the seed leaving the secure element and without any networked device seeing them. Where a wallet lacks such a feature, the equivalent is a second signing device of the same kind, factory-reset, kept offline, restored from the written materials, and compared by first address; a spare phone or laptop with a software wallet is not that equivalent, because the moment the seed is typed into it the seed has been on a networked machine.

Rehearse the loss you claim to survive. For Shamir, quorum, MPC and guardian designs, retire one component and restore from the remainder per your own instructions: recover from two of three shares on the device, sign a small transaction with two of three keys while the third stays in its drawer, or, for MPC and guardian designs, run the product's documented recovery flow with one device absent, without attempting to extract or reassemble key shares yourself. The design's promise is only known to hold when it has been exercised.

Rehearsal has a second product beyond confidence: it audits the knowledge layer. Every stumble in rehearsal, a word that reads two ways, a step the note forgot, a share that was somewhere else, a descriptor never exported, is a failure that just happened safely instead of catastrophically later. Fix the note, re-run the stumble, and repeat the rehearsal after any change to the arrangement: new passphrase, new cosigner, new device, new guardian, new heir.

Frequently asked questions

Should I split my seed phrase into parts and store them separately?

Ad-hoc splitting, some words here and some there, is usually a downgrade: it multiplies loss risk while barely denting theft risk, since a partial mnemonic narrows the search for the rest. Designs made for distribution (passphrases, SLIP-39 shares, multisig, threshold shares) achieve the goal with defined thresholds, which is why this guide routes there instead.

How many copies of a single seed should exist?

The trade-off is between fragility and exposure: one copy in one place is lost with that place; every additional copy is another item a finder could read. One pattern is two or three copies on durable media in locations that do not share disasters, each with the recovery note. The number matters less than the independence of the locations and the accuracy of the map.

Is a bank safe deposit box a good location?

It scores well on fire and theft and adds considerations of its own: access hours, jurisdiction, succession rules on death, and the box provider's own procedures. As one location in a distributed design it can be a sound component; as the sole location of a sole copy it concentrates exactly what this guide distributes.

Do I need to update backups when I add funds?

For a BIP-39 wallet with a standard derivation path, no: the mnemonic and passphrase restore the same keys and addresses regardless of balance (BIP-39; BIP-32). Yes, when the arrangement changes: a new passphrase, a new account on a non-standard path, a new cosigner or descriptor, a new device share, a new guardian, new heirs. Backup follows architecture, and architecture changes deserve a rehearsal. Some MPC and smart-account products also rotate shares or recovery factors on their own schedule, in which case the product's documentation says what, if anything, the holder must re-record.

What should happen to backups when I die?

That is the inheritance question, and it has its own guide to recovery and inheritance: the short version is that someone you trust must be able to find the materials, understand the map and act within the succession law that applies, none of which happens by accident. Succession and estate rules differ by jurisdiction, and legal advice applies to any specific estate. A backup design that dies with its author was a loan to entropy all along.

Can a lost seed phrase be recovered?

It depends on what else exists. In a single-signature BIP-39 wallet, a device that still holds the wallet can be used to send the funds to a new wallet whose backup is made and rehearsed properly; if the device and the written words are both gone and no other copy was made, the design itself offers nothing else to restore from. Multisig, Shamir, MPC and guardian designs are built to survive the loss of one component, within the limits their documentation sets. Services that offer to recover lost or stolen crypto for a fee call for caution: the FBI has warned about companies falsely claiming to recover funds lost in cryptocurrency investment scams, saying such fraudsters "charge an up-front fee" and then stop responding or ask for more (FBI IC3, 11 August 2023). No legitimate process needs a seed, passphrase or share handed to a stranger, and the guide to responding when crypto is hacked or stolen covers reporting routes.

Sources and further reading

• BIP-39: Mnemonic code for generating deterministic keys. Bitcoin Improvement Proposals repository, 2013, as maintained. https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki (accessed 23 September 2026)
• BIP-32: Hierarchical Deterministic Wallets. Bitcoin Improvement Proposals repository, 2012, as maintained. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki (accessed 23 September 2026)
• BIP-44: Multi-Account Hierarchy for Deterministic Wallets. Bitcoin Improvement Proposals repository, 2014, as maintained. https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki (accessed 23 September 2026)
• SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes. SatoshiLabs Improvement Proposals repository, 2017, as maintained. https://github.com/satoshilabs/slips/blob/master/slip-0039.md (accessed 23 September 2026)
• COLDCARD Security Advisory: seed generation warning. Coinkite, 30 July 2026, updated 1 August 2026. https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/ (accessed 24 September 2026)
• Passphrases and hidden wallets (vendor documentation). Trezor, undated. https://trezor.io/learn/a/passphrases-and-hidden-wallets (accessed 24 September 2026)
• Check wallet backup on Trezor Safe 3 (vendor documentation). Trezor, undated. https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-3 (accessed 24 September 2026)
• Check wallet backup on Trezor Safe 5 (vendor documentation). Trezor, undated. https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-5 (accessed 24 September 2026)
• Recovering a wallet with Multi-share Backup (vendor documentation). Trezor, undated. https://trezor.io/guides/backups-recovery/advanced-wallets/recover-a-wallet-with-multi-share-backup (accessed 24 September 2026)
• Navigating Bitcoin Storage (Bitcoin Custody Report; a custody provider's own dormancy-based estimate). River, 14 August 2026. https://river.com/content/bitcoin-custody-report-2025 (accessed 24 September 2026)
• Crypto Crime Report 2026: stolen funds (data provider's own on-chain estimate). Chainalysis, 18 December 2025. https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2026/ (accessed 23 September 2026)
• Increase in Companies Falsely Claiming an Ability to Recover Funds Lost in Cryptocurrency Investment Scams (PSA230811). FBI Internet Crime Complaint Center, 11 August 2023. https://www.ic3.gov/PSA/2023/psa230811 (accessed 24 September 2026)