Seed Phrase Backup and Recovery OPSEC: The Operational Regime

Introduction

The recovery phrase is the one secret that controls everything. A hardware wallet keeps the key off the internet and a disciplined signing routine stops you approving a drainer's transaction, but both rest on a layer underneath them: a backup of the seed that survives whatever the world throws at it. Most self-custody guides treat the seed as solved once they have told you to write the words down and never type them into a website. That advice is correct as far as it goes, and the device-level fundamentals of generating and protecting a recovery phrase are covered in our hardware wallet seed basics baseline. This page picks up where that leaves off and treats the backup as an ongoing operational regime rather than a one-time act.

The distinction matters because the failures here are slow and silent until they are total. A seed written on the supplied recovery card and slipped into a desk drawer is a backup right up to the morning of the house fire. A single metal plate in one location is a backup until the burglary. A photograph taken "just in case" is a backup until the phone syncs it to a cloud account that is later breached. None of these failures announces itself, and none of them is recoverable after the fact, because there is no reset link for a seed phrase. The regime that prevents them is not complicated, but it is deliberate: the right medium, in the right number of places, hardened against the right threats, and tested before it is trusted.

This guide owns three things the rest of the security cluster deliberately leaves to it. The first is the BIP-39 passphrase and exactly how it derives a separate wallet from the same words, because that mechanism underpins both the safe distribution of backups and the decoy-wallet pattern. The second is the decoy mechanics themselves: how a credible-balance decoy gives plausible deniability, and the narrow circumstances in which it earns its complexity. The third is the practical comparison that holders find genuinely confusing, between SLIP-39 Shamir backup and full multisig. Where the boundary of this page meets the architecture layer, it links out rather than re-deriving: multisig is an ongoing custody model with its own depth, treated as its own architecture topic later on this page, and the broader process layer this satellite belongs to is set out in the crypto operational security hub.

Backup as an Operational Problem

The reason most seed backups fail is not that the holder did something obviously reckless. It is that each convenient storage method optimises for the wrong thing. A photo is convenient because it is always with you and easy to re-read; that is exactly why it is dangerous, because it lives on a networked, synced, backed-up device that an attacker only has to reach once. A note in a password manager is convenient because it is searchable and encrypted; but a password manager is an online account, and putting the master key to your savings inside it collapses two independent security layers into one. The common thread is that backups fail through their convenience features, not in spite of them.

The failure modes, side by side

Setting the common storage methods against the failure each invites makes the pattern obvious, and shows why the regime that follows is built the way it is.

• Paper recovery card in a drawer — destroyed by fire, water and humidity; ignites at roughly 230°C, far below house-fire temperatures. A single accident in one room ends it, and there is no second copy to fall back on.
• Photograph on a phone — synced automatically to cloud backups, indexed by the device, and readable by any app with photo-library permission. One account breach or one lost-and-unlocked phone exposes it permanently.
• Cloud note or document — places the master secret inside an online account protected by a password and, at best, two-factor; a single credential compromise or provider breach exposes everything at once.
• Password-manager entry — convenient and encrypted, but it folds the key to your cold savings into the same vault as your online logins, defeating the separation that made cold storage worthwhile.
• Single metal plate, one location — survives fire and water, but a burglary, a building collapse or a single targeted theft destroys or exposes the only copy. Durable medium, fragile distribution.

A real example put the photograph failure mode on the front page in 2026. In late February, South Korea's National Tax Service published a press release celebrating a tax-evasion seizure, illustrated with a photograph of a confiscated Ledger hardware wallet sitting beside a handwritten note that contained its full recovery phrase. Within hours an unknown actor used the exposed words to drain roughly $4.8 million in tokens from the wallet, as CoinDesk reported on 2 March 2026. A government agency with every resource available made the most basic operational error there is: the secret was photographed, and the photograph was published. The lesson scales down to every holder. A seed that has ever been captured by a camera is no longer secret, regardless of how careful you are afterwards.

What this page assumes, and what it does not cover

This regime assumes the seed basics are already in place: that the recovery phrase was generated on-device by a reputable hardware wallet, that it was never typed into a computer or phone, and that you understand the words themselves are the keys to the funds. Those fundamentals, including how a seed is generated and why it must never touch a networked device, belong to the device layer and are covered in the hardware-wallet baseline linked in the introduction. From here on the question is narrower and entirely operational: given a phrase that exists, how do you store and protect it so that no single event, accident or person can either destroy it or read it.

Metal Seed Backup: Surviving Fire, Water and Time

A metal backup exists to defeat the two accidents that destroy paper most reliably: fire and water. The case for metal rests on a simple temperature gap. A typical residential structure fire runs between roughly 800 and 1,200°F (about 427 to 649°C), and once flashover occurs the temperature surges towards the top of that band; severe or fuel-rich fires push higher still. Paper ignites at around 230°C, so it is gone long before a fire reaches its peak. Stainless steel seed plates are rated far above the range a house fire reaches, which is why they survive the event that erases a paper card in the same room.

The metal options compared

Three families of metal backup dominate the market in 2026, and they differ less in survivability, where all comfortably exceed house-fire temperatures, than in how the words are recorded and how tamper-evident the result is. The figures below come from the manufacturers' own published specifications and independent heat tests.

The recording method is the more practical decision, because it determines how the backup fails if it is mishandled. Tile-assembly designs like the Cryptosteel Capsule and Billfodl let you correct a mistake and re-seal, but the tiles can be jostled out of order by a hard enough impact if the unit is not properly closed. Punched or stamped plates like Keystone's are permanent once struck, which is unforgiving of typos but immune to anything rearranging the characters later. Neither is wrong; the choice follows from whether you value correctability or permanence, and from whether you would rather assemble small tiles or operate a centre punch.

Why the steel grade and the failure axis both matter

Heat is the headline number on every product page. It is not the only way a metal backup dies. The better products advertise marine-grade 316 over 303 or 304 for corrosion resistance, not fire. The 316 grade contains molybdenum, which sharply improves its resistance to chlorides and salt. Those are the conditions that pit and rust lesser steels over years of damp storage. A plate kept in a coastal property, a flood-prone basement or a buried cache faces corrosion long before it faces a fire. A backup meant to last decades has to survive slow chemistry as well as one dramatic event. The melting figures matter for the worst-case fire. The grade matters for the more common case: a copy that simply sits in a humid cupboard for fifteen years.

There is a quieter failure mode the temperature ratings never mention. It is legibility after the event, not survival of the metal. A plate can come through a fire intact and still emerge warped, soot-blackened or scaled. Stamped characters that were shallow to begin with can become genuinely hard to read. This is the practical argument for stamping deep and choosing an unambiguous recording scheme. It is also why you should test recovery during a calm rehearsal, not in the wreckage of a house. Match the medium to the realistic threat your storage location presents, not to the largest number on the box. Remember that a backup you cannot read is no better than one that burnt.

The metal-backup checklist

Whichever medium you choose, a handful of habits separate a metal backup that actually works from one that only feels reassuring.

• Record the full phrase exactly, in order. Most schemes need only the first four letters of each word, because BIP-39 words are uniquely identified by their first four characters, but the word order is part of the secret and must be preserved precisely.
• Test a full recovery before you trust it. Wipe a spare or secondary device and restore from the metal backup alone. A backup you have never recovered from is an assumption, not a backup, and the time to discover a transposed character is now, not after a fire.
• Store the backup away from the device. A seed plate sitting next to the hardware wallet means a single burglary takes both; physical separation is part of what the backup is for.
• Seal and label nothing that identifies the funds. A tamper-evident seal tells you whether a copy has been opened, and a backup that does not announce itself as a crypto seed attracts less attention from an opportunistic thief.
• Keep the medium proportionate. A metal plate is justified by a holding whose loss would genuinely hurt; for a small spending float it is over-engineering, and the better answer is simply not to keep much there.

Geographic Distribution: Two or Three Copies, No Shared Disaster

A single backup, however indestructible the medium, is still a single point of failure. The metal plate survives the fire, but it does not survive the burglar who takes the safe, and it does not help the holder whose only copy is in a flat they can no longer reach. Distribution answers a different question from durability: not "will this copy survive an accident" but "will at least one copy survive any single event that could hit the place it is kept". The design goal is that no individual fire, flood, theft or building collapse can reach every copy at once.

A workable distribution pattern

For most holders, two to three copies across locations that do not share a disaster strikes the right balance. A practical arrangement is a copy in a home safe for everyday recovery access, a second in a bank safe-deposit box or with a trusted relative in a different building, and for larger holdings a third in a more distant location such as a second property. The locations should differ in the kind of event that threatens them: a home safe and a relative's house in the same street both burn in the same wildfire, so geographic separation has to be real rather than nominal. Each location also needs genuine access control, because a copy left in an unlocked drawer at a relative's home is a copy anyone passing through can photograph.

A worked scheme makes the reasoning concrete. Imagine a holder with a meaningful cold portfolio who decides on three copies. Treat the design as a deliberate exercise in non-overlapping risk. The first copy is a metal plate in a home safe, bolted down so it cannot be carried off. It serves everyday access for routine recovery rehearsals. The second is a metal plate in a bank safe-deposit box several miles away. Pick a box in a different flood catchment and a different power grid, so the fire or burglary that reaches the home cannot reach it. The third is a sealed, tamper-evident copy held by a sibling in another city. It sits far enough away that a regional storm or a wide-area power failure cannot take out all three at once.

Crucially, none of the three copies carries the BIP-39 passphrase. The words alone, in however many places, open only a near-empty wallet. The passphrase that unlocks the real funds lives on a single sealed record in a fourth place, known only to you. The result tolerates the loss of any one location to disaster, and the compromise of any one location to theft, without losing or exposing the funds. The cost is honest book-keeping. You have to remember which location holds what, keep the access arrangements current as relatives move or banks change their box terms, and revisit the map whenever a house move or a relationship change quietly invalidates an assumption.

The lesson is that distribution is a continuing responsibility, not a one-time act of hiding things in good places. A safe-deposit box can be sealed during a probate dispute or closed when a branch shuts. A trusted relative can move abroad, fall out with you, or be burgled themselves. A second property can be sold or let to strangers. Each of these silently invalidates an assumption the original design relied on, and none of them announces itself. The holders who lose funds to distribution failures rarely chose bad locations. They chose reasonable ones and then never revisited the map as the world changed around it.

Treat the scheme like any other piece of security infrastructure. Write down where the copies are in terms only you can decode. Each location also needs real access control: a quality safe, a bank's own authentication on a deposit box, or a tamper-evident container at a trusted party. Schedule a periodic review against real events, and update the map the moment a location stops being what it was when you trusted it.

The tension distribution creates, and how the passphrase resolves it

Distribution has an uncomfortable side effect: every additional copy of the seed is an additional place it can be stolen or read. Three copies survive three times as many accidents, but they also triple the surface for theft. This is the precise problem the BIP-39 passphrase resolves, and it is why the next section matters operationally rather than as a curiosity. When the written words are protected by a passphrase held separately, the words on their own open nothing of value, so distributing them widely stops being dangerous. You can place the metal-backed words in several locations for redundancy against loss, while the single secret that actually unlocks the funds lives somewhere else entirely. Distribution and the passphrase are not two unrelated tools; the passphrase is what makes aggressive distribution safe.

• Do separate the kinds of disaster, not just the addresses. Two copies a mile apart still share a flood plain or a wildfire front; spread them across genuinely different risk zones where the holding justifies it.
• Do put real access control on every location. A safe, a deposit box, or a sealed tamper-evident container at a trusted party, never an open drawer or a shared shelf.
• Do not distribute unprotected words widely. Multiple copies of a passphrase-free seed multiply the theft surface; either keep them tightly controlled or add a passphrase so the words alone are useless.

The BIP-39 Passphrase: How the 25th Word Actually Works

The BIP-39 passphrase, often called the 25th word, is the single most misunderstood tool in seed-backup security, so it is worth being precise about what it actually does. It is not a PIN on the device, and it is not a password stored anywhere. It is an input to the maths that turns your recovery words into the seed your wallet uses, and changing it produces a wholly different wallet from the same words. Understanding the derivation is what makes the rest of this page coherent, because both safe distribution and the decoy pattern depend on it.

The derivation, in plain terms

BIP-39 does not use the recovery words directly as the wallet seed. It runs them through a key-derivation function called PBKDF2, using HMAC-SHA512 as the underlying hash, repeated 2048 times. The recovery words act as the password input to that function, and the salt is the fixed text string "mnemonic" concatenated with your passphrase. The output is a 512-bit seed, from which the wallet derives all of its keys. The consequence is exact and unforgiving: change the passphrase by a single character and the salt changes, so PBKDF2 produces a completely different 512-bit seed, which derives a completely different set of addresses. There is no "close enough". The same twelve or twenty-four words with no passphrase, with the passphrase "garden", and with the passphrase "Garden" open three entirely separate wallets, none of which can see the others' funds.

Two properties follow directly from that mechanism and drive every operational decision around the passphrase. First, because the passphrase is mixed into the derivation rather than stored, there is nothing on the device or in the words to reveal that a passphrase is even in use, let alone what it is. Anyone who recovers the words alone lands in the no-passphrase wallet and has no signal that another exists. Second, and for the same reason, there is no recovery path if the passphrase is lost. No vendor, support line or backup holds it, because by design nothing does. A passphrase is therefore simultaneously a powerful defence and a new, self-imposed single point of failure.

The passphrase failure modes, and why they recur

The ways a passphrase costs people their funds are remarkably consistent, and almost none of them involve an attacker. The most common is the silent typo at setup. A holder picks a memorable phrase, types it confidently the first time, and funds the wallet. Months later, restoring on a new device, they find that what they entered held a transposed letter or a stray trailing space they cannot now reproduce. The derivation gives no feedback, so a wallet created with an accidental space and one without it are two different wallets. The funds sit in the one nobody can find again. The fix is mechanical rather than clever. Confirm the passphrase by performing a full recovery onto a wiped device before any real value goes in. The only passphrase you should ever trust is one you have already proved you can re-enter exactly.

The second recurring failure is ambiguity in how the passphrase is recorded. Capital letters, spaces, accented characters, and lookalike glyphs all belong to the secret. A digit zero against a capital O, or a lowercase l against the digit one, is easy to mis-transcribe under stress. A passphrase written in a hurried hand, then read back a year later by a relative during an inheritance recovery, is exactly where these ambiguities turn fatal. Favour a written form that is unambiguous. Avoid characters that depend on a particular font to disambiguate, and annotate anything that could be read two ways.

The third failure is psychological: people over-trust their own memory. A passphrase that felt unforgettable in a calm moment is genuinely lost after a serious illness, a head injury, or enough years of disuse. There is no reset and no support line, because the passphrase sits outside any authentication or encryption the device offers. Memory is a fine convenience layer on top of a written record. It is a catastrophic substitute for one, and the holders who treat it as the whole backup quietly remove themselves from their own funds.

Operational rules for living with a passphrase

The forget-risk is real enough that a passphrase mishandled is a more common way to lose funds than the attack it defends against. These rules keep the defence from becoming the failure.

• Never store the passphrase with the words. The entire point is that the two secrets live apart; a slip of paper holding both, in the same safe, recreates exactly the single point of failure the passphrase was meant to remove.
• Keep one sealed offline record, held separately. Relying on memory alone for serious value is how passphrases get lost. A single sealed copy in a different location from the words preserves the separation while removing the catastrophic memory dependency.
• Test a full recovery before trusting real funds. Restore the words plus the passphrase on a wiped device and confirm it reaches the right wallet. A passphrase you have never recovered with is an assumption you are betting the portfolio on.
• Avoid a passphrase a determined attacker could guess. A short word, a pet's name, or a date undermines the defence; the strength of the protection is the strength and unpredictability of the passphrase itself.
• Decide deliberately whether the value warrants it. A passphrase adds genuine resilience against a found backup, but it also adds operational fragility; for a modest holding the simpler regime you will not lock yourself out of is often the better one.

SLIP-39 Shamir Versus Multisig Redundancy

Once a holder has accepted that a single backup is fragile, the natural next question is how to add redundancy without simply scattering more copies of the same secret. Two mechanisms answer it in genuinely different ways, and they are frequently confused because both involve "splitting" a key across several pieces. The difference is when, and whether, the full key is ever reassembled, and that single distinction decides which one fits a given holder.

What each mechanism actually does

SLIP-39, marketed as Shamir backup and native to Trezor devices, applies Shamir's Secret Sharing to a single seed. It splits one key into several shares and sets a threshold, so that any chosen number of shares reconstruct the original seed, while fewer than the threshold reveal nothing at all about it. The crucial property is that reconstruction happens once, at recovery time, on one device: the shares come back together, the seed is rebuilt, and from then on the wallet operates as an ordinary single-key wallet. Shamir hardens the backup of a single key; it does not change how the wallet is used day to day.

Multisig is a different layer of the stack entirely. Rather than splitting one key and reassembling it, it requires several independent keys to sign every transaction on an ongoing basis. The full spending key is never reconstructed anywhere, because there is no single full key to reconstruct; M of N independent signers must each approve, so no single device, backup or person can move funds alone. That ongoing requirement is the source of both its strength and its friction, and the full mechanics, signer selection and coordinator choices are an architecture topic in their own right, covered in our multisig wallets architecture guide. The boundary of this page is the comparison; the architecture itself belongs there.

The decision rule, and a worked scheme

The choice follows from what you are defending against. If the wallet is fundamentally a single-key setup and the worry is losing or having compromised any one backup copy, Shamir is the right tool: it gives redundancy against the loss of a share without changing how you transact, and Trezor's implementation makes it accessible without bespoke tooling. If the portfolio has grown to the point where the single key itself is the unacceptable risk, where you no longer want any one event, device or person to be able to move the funds, the answer is multisig, and the right place to make that call is the architecture guide above rather than the backup layer. A useful rule of thumb: Shamir for resilience of one key, multisig for elimination of the single key.

A concrete Shamir scheme shows the trade-off in practice. Consider a three-of-five split of a single cold seed. Five shares are produced, any three of which reconstruct the wallet, and they are distributed across separate locations: a home safe, a bank deposit box, two trusted relatives in different households, and a sealed copy with a solicitor. Losing any two shares to a fire, a fallout or a misplaced envelope is survivable, because three remain. An attacker who compromises any one or two locations learns nothing, because two shares are below the threshold and reveal nothing about the seed. The cost is that recovery requires physically gathering three of the five, and at that moment the full seed does briefly exist on one device, which is exactly the property multisig avoids and the reason a large enough holding eventually graduates to it.

Choosing the threshold is where most Shamir schemes are won or lost. Three-of-five is popular because it sits in the sensible middle of two opposing failures. Set the threshold too low, say two-of-three, and you have barely improved on a single backup. Any two compromised locations now reconstruct the entire seed, so the scheme buys redundancy against loss while giving away much of its theft resistance. Set it too high, say five-of-five, and you have built a machine that destroys your own funds the first time one envelope is lost. Every share is now mandatory and there is no slack.

The three-of-five point survives the loss of two shares and resists the compromise of two. That maps well onto realistic life events. A fire that takes one location, and a relative who moves and misplaces their envelope, can both happen without touching the funds. The other parameter people overlook is who holds each share and whether they understand what it is. A share handed to someone who does not know it is sensitive, or who consolidates it with the others "to keep things tidy", quietly collapses the geographic separation the scheme depended on. Each holder needs just enough instruction to keep their share isolated, without learning enough to become a target.

The Decoy Wallet, and What Never to Do

The decoy wallet is the most advanced application of the passphrase mechanism, and the most commonly misunderstood. It exists for one narrow purpose: plausible deniability under physical coercion, where an attacker can apply pressure to make you hand over what you have. Whether you face that threat at all is a threat-modelling question rather than a default, and the realistic likelihood of physical-coercion attacks, who they target, and how to weigh them is the subject of our physical-coercion threat scenario. This section owns the mechanics of the decoy itself; that page owns whether the threat applies to you.

How a decoy actually works

The decoy is built entirely on the derivation covered earlier. The same recovery words, with no passphrase or with a simple, surrenderable one, derive a decoy wallet. The real funds sit behind a second, secret passphrase that derives a completely separate wallet from the identical words. Because nothing on the device or in the written words reveals that a second passphrase exists, an attacker who extracts the words and the decoy passphrase reaches a wallet that looks like the real thing and has no signal that another is hidden behind it. Coldcard's documentation describes the same idea through duress and trick-PIN features, but the underlying principle is the passphrase: one set of words, many derivable wallets, only one of which you ever have to reveal.

The decoy only works if it is credible, and this is where most homemade attempts fail. Coldcard's own guidance is explicit that an empty decoy is unconvincing: a wallet holding nothing tells a determined attacker that there must be a hidden one, and invites exactly the escalation the decoy was meant to defuse. A working decoy holds a meaningful but acceptable-to-lose balance, large enough to read as someone's real holdings, small enough that surrendering it is survivable. Getting that balance right is a judgement call, and it is also why the decoy is not a casual add-on: it asks you to keep real value somewhere you are prepared to lose, purely to make the deception believable. For most holders, who do not face a credible physical-coercion threat, that cost is not worth paying, and the honest recommendation is to skip the decoy entirely rather than build a half-credible one.

The seed-backup anti-pattern list

The fastest way to find the weak point in your own regime is to read the list of things that recur in loss post-mortems and confirm none of them describes your setup.

• Storing the seed as a photo or screenshot. It syncs to the cloud, is indexed by the device, and is readable by any app with photo access; the South Korea tax-authority leak is the textbook case of how fast this becomes a total loss.
• Keeping the passphrase with the words. A single document or safe holding both recreates the exact single point of failure the passphrase was supposed to eliminate.
• Holding every copy in one building. Durable metal does not survive a burglary or collapse if there is only one copy and it is all in the same place.
• Never testing a recovery. A backup you have never restored from is an untested assumption; a transposed word or a forgotten passphrase surfaces at the worst possible moment.
• Relying on memory alone for a passphrase. Memory degrades, and there is no reset; serious value behind a memory-only passphrase is value you may lose to nothing more than time.
• Building an empty or under-funded decoy. An unconvincing decoy is worse than none, because it signals a hidden wallet and escalates the pressure on you.
• Telling the world you hold crypto. Public association between your identity and a holding turns an abstract risk into a targeted one; the quietest holder is the safest one.

Conclusion

A seed backup is not a one-time chore to be ticked off and forgotten; it is a small standing system whose whole job is to survive events that have not happened yet. The four parts reinforce each other. Metal defeats the fire and the flood that destroy paper. Geographic distribution defeats the single event that could reach one location. The passphrase makes that distribution safe and unlocks the decoy pattern for the few who need it. And the deliberate choice between Shamir backup and multisig matches the redundancy mechanism to the value and the threat, rather than scattering more copies of one fragile secret.

The discipline that ties them together is testing. Every part of this regime is an assumption until you have proved it: the metal backup until you have recovered from it, the passphrase until you have restored a wallet with it, the distribution until you have confirmed you can reach the copies you are relying on. The South Korea leak is a reminder that even sophisticated, well-resourced custodians fail at the simplest step when the operational habit is missing. A seed photographed once is no longer secret; a passphrase remembered only in your head is one bad year from gone; a single metal plate in a single drawer is one burglary from total loss. None of these failures is exotic, and none is recoverable.

Match the regime to what you actually hold. A modest spending float does not warrant a metal plate, a passphrase and a five-share Shamir scheme, and over-engineering a small holding is its own failure mode, because complexity you do not maintain becomes complexity that locks you out. A serious cold portfolio warrants every layer here, tested and separated, because at that scale a single accident is not an inconvenience but the permanent loss of a life-changing sum. Build the regime your holding justifies, prove it works before you trust it, and then leave it alone to do the quiet job it was designed for.

Sources

• BIP-39 specification (bitcoin/bips): backs the PBKDF2-HMAC-SHA512 derivation, 2048 iterations, the salt of "mnemonic" plus passphrase, and the 512-bit seed output.
• Trezor — Shamir backup (SLIP-39): backs the M-of-N share threshold, reconstruct-once recovery, and Trezor-native Shamir and Super Shamir support.
• SLIP-0039 specification (satoshilabs/slips): backs the technical detail that fewer than the threshold of shares reveal nothing and that the master secret is reconstructed at recovery.
• CoinDesk — South Korea tax-authority seed-phrase photo leak, 2 March 2026: backs the roughly $4.8 million theft after the National Tax Service exposed a seized Ledger wallet's seed in a press-release photo.
• Coldcard — BIP-39 passphrase and decoy wallets: backs the decoy-wallet mechanics, the plausible-deniability principle, and the guidance that a credible decoy must hold a meaningful balance.
• Keystone Tablet — metal seed-backup specification: backs the 304-grade stainless-steel construction and the fireproof threshold of roughly 1,400°C, well above the house-fire range it cites of about 649°C (1,200°F).
• Keystone documentation — recording and recovery practice: backs the metal-backup recording method, the BIP-39 first-four-letters identification, and the test-before-trust recovery discipline.
• NFPA — fire safety reference: cross-checks the residential structure-fire temperature range (roughly 427 to 649°C) used to justify metal over paper.

Frequently Asked Questions

Do I really need a metal backup, or is laminated paper good enough?

Laminated paper is not a serious backup for anything you cannot afford to lose. Paper ignites at around 230°C, far below the 800 to 1,200°F (roughly 427 to 649°C) of a typical house fire, and lamination only delays water and humidity damage rather than stopping it. A metal backup made from stainless steel survives the accidents that destroy paper: Cryptosteel uses 303 and 304 grade steel rated to about 1,400°C, and Billfodl uses 316 marine-grade steel rated to roughly 1,800°F. The honest rule is to match the backup to the value at risk. A few hundred pounds on a hot wallet does not warrant a metal plate; a five- or six-figure cold portfolio absolutely does, because the cost of the plate is trivial against the cost of a single fire or flood erasing the only copy of the seed.

Where should I store two or three seed backups?

Store two to three copies in locations that do not share a single disaster. A home safe plus a bank safe-deposit box plus a sealed copy with a trusted relative or a second property is a common pattern, because no single fire, flood, burglary or building collapse can destroy or expose them all at once. The trade-off is that every extra copy adds a place the seed could be stolen or read, so each location needs real access control rather than a drawer anyone can open. If you use a BIP-39 passphrase, the written words become safe to distribute more widely because the words alone are incomplete without the passphrase, which is held separately. Never keep all copies in one building, and never store a backup somewhere a flatmate, cleaner or visitor could photograph it.

What is a BIP-39 passphrase, and is it the same as a 25th word?

A BIP-39 passphrase is an extra secret you add on top of your recovery words, often called the 25th word, although it is not limited to one word and it is not one of the standard wordlist entries. Technically it changes how the seed is derived: BIP-39 runs the recovery words through PBKDF2 with HMAC-SHA512 for 2048 iterations, using the string mnemonic plus your passphrase as the salt, so a different passphrase produces a completely different 512-bit seed and therefore a completely different wallet. The same words with no passphrase, with passphrase A, and with passphrase B open three separate wallets. Because the passphrase is never written into the seed and is not stored on the device, anyone who finds your words alone reaches an empty or decoy wallet, not your real funds.

What happens if I forget my BIP-39 passphrase?

If you forget the passphrase, the funds in the wallet it protects are gone permanently, with no recovery path. The passphrase is not stored anywhere by design, so there is nobody to reset it and no support line that can recover it. This is the central trade-off: a passphrase defends you against someone finding your written words, but it adds a new single point of failure that lives only in your memory. The operational answer is to never rely on memory alone for serious value. Keep one sealed offline record of the passphrase, stored separately from the words and ideally in a different location, and test a full recovery on a spare or wiped device before you trust real funds to the setup. A passphrase you cannot reliably reproduce is a way to lose your own money, not protect it.

Should I use SLIP-39 Shamir backup or multisig?

They solve different problems and the right choice follows from what you are defending against. SLIP-39 Shamir backup, native to Trezor devices, splits one key into several shares where a chosen threshold reconstruct it once when recovery is needed; below that threshold the shares reveal nothing. It protects a single key's backup against the loss or compromise of any one share, but at the moment of recovery the whole seed is reassembled on one device. Multisig is different: it requires several independent keys to approve every transaction on an ongoing basis, so the full key is never reassembled and no single device or person can move funds alone. Choose Shamir to harden the backup of a single-key wallet without changing daily operation; choose multisig when the portfolio is large enough to justify removing the single key entirely, accepting the higher day-to-day friction.

How does a decoy wallet work, and how much should I hold in it?

A decoy wallet uses the BIP-39 passphrase mechanism to create plausible deniability. Your recovery words with no passphrase, or with a simple obvious one, open a decoy wallet; your real funds sit behind a second, secret passphrase that derives an entirely different wallet from the same words. Under coercion you can surrender the words and the decoy passphrase, and the attacker reaches a wallet that looks real. The decoy only works if it holds a credible balance: Coldcard's documentation is explicit that an empty decoy is unconvincing, so you should fund it with a meaningful but acceptable-to-lose amount. A decoy holding nothing tells a determined attacker there is a hidden wallet and invites more pressure, which is why the physical-coercion threat itself, and whether you even face it, is a threat-modelling question rather than a default for every holder.

I photographed my seed phrase years ago. Is it compromised?

Treat any seed that has ever been photographed, typed into a device, or stored in the cloud as compromised, and move the funds to a freshly generated seed that has only ever existed offline. A photo on a phone is synced to cloud backups, indexed, and exposed to every app with photo-library access and to anyone who later gains access to the account. The risk is not hypothetical: in February 2026 South Korea's National Tax Service exposed the seed of a seized Ledger wallet in a press-release photo of a handwritten note, and roughly $4.8 million in tokens was drained within hours, as reported by CoinDesk on 2 March 2026. If a serious sum has been sitting behind a photographed seed, the safe action is to generate a new wallet on a hardware device, back it up only on metal, and transfer everything across, then treat the old seed as burnt.

Related Resources

• Crypto operational security: the complete guide — the hub that places seed backup inside the wider device, architecture, behaviour and recovery stack, with the threat-model framework that decides how much regime you need.
• Crypto inheritance and estate planning — how the backups in this guide pass to your heirs without exposing the keys, including the consequence of a passphrase your heir does not know about.
• Crypto threat modelling: a personal security plan — whether the physical-coercion threat the decoy defends against actually applies to you, and how to tier protection to holding size.
• Hardware wallet security: the complete guide — the device-layer baseline this regime assumes, including how a recovery phrase is generated and why it must never touch a networked machine.
• Multisig wallets: the complete guide — the architecture layer for holders whose portfolio has outgrown a single key, where the multisig side of the Shamir-versus-multisig choice is developed in full.

Financial Disclaimer

This content is not financial advice. All information provided is for educational purposes only. Cryptocurrency investments carry significant investment risk, and past performance does not guarantee future results. Always do your own research and consult a qualified financial advisor before making investment decisions.