Bitcoin Self-Custody Threat Model: Keys, Seeds, Wallets, Backups, and Recovery

Commercial-interest and safety disclosure: D-Central sells mining equipment and services and therefore has a financial interest in mining decisions. This guide is educational and does not recommend a wallet, signing device, custody provider, security design, investment, or purchase. It is not independent security, legal, tax, financial, or estate advice. Self-custody errors can cause irreversible loss. Follow the exact documentation for your wallet and signer, use qualified local legal and security assessment where needed, and never enter live recovery material while following a webpage.

Quick answer: self-custody is an operating system for authorization and recovery, not a product label. Start by naming the assets, people, software, devices, records, locations, and failure conditions in scope. A control is useful only if it addresses a stated threat and can be recovered under a tested, documented scenario.

Name each object before protecting it

Bitcoin records unspent transaction outputs and the conditions under which they can be spent. Coins are not stored inside a wallet. A wallet coordinates the information and authorization process used to recognize and spend relevant outputs.

Term	Operational meaning	Recovery boundary
Private key	Secret scalar used in a signing operation that may satisfy a particular spending condition.	Exposure may permit unauthorized signing; loss may matter if no other authorized recovery path exists.
Seed	Root input from which a deterministic wallet can derive keys under a defined scheme.	The same bytes are insufficient if the derivation, script, or implementation context is missing.
BIP39 mnemonic	Words encoding entropy and a checksum, processed with an optional passphrase to produce a seed.	It is not a generic synonym for every seed or wallet backup.
Passphrase	An optional, case-sensitive BIP39 input; not necessarily a word and not stored in the mnemonic.	Every input produces a seed. A mistake can silently derive an unrelated wallet.
Descriptor	A textual description of scripts and key derivation, often with origin information and a checksum.	Public-only forms can restore watching; private forms can authorize spending and are secrets.
Wallet	Software and data coordinating descriptors or keys, address derivation, transaction creation, signing, and metadata.	Backup behavior is implementation-specific; labels, history, birth time, and policy records may require separate handling.

Build the threat model before choosing controls

Failure class	Example boundary	Evidence to retain	Control question	Stop gate
Secret disclosure	Mnemonic, passphrase, private descriptor, signing device, camera, clipboard, logs	Access history, device state, known copies, last verified transaction	Which material can authorize spending and who can reach it?	Suspected disclosure of production authorization data
Software or host compromise	Address substitution, false balance, malicious transaction, exposed RPC	Release, signature or digest, configuration, independently verified output	Where is transaction intent verified outside the proposing host?	Unexplained destination, change, fee, or signer display
Backup loss or damage	Fire, moisture, corrosion, media failure, illegibility, inaccessible location	Inventory, condition check, recovery-test record	Can the required information survive distinct failure domains?	Only remaining readable copy or uncertain transcription
Operator error	Wrong network, wrong passphrase, incomplete descriptor, premature wipe	Runbook, expected scripts or addresses, second-person check where appropriate	What reversible test occurs before an irreversible step?	Unmatched expected output or undocumented prompt
Supply chain or update	Substituted device, altered package, incompatible firmware, unreviewed dependency	Source URL, pinned release, signer fingerprint, digest, provenance record	How is exact software and hardware provenance established?	Signature, digest, origin, or compatibility cannot be verified
Availability or incapacity	Lost signer, unavailable operator, forgotten passphrase, death	Role map, access conditions, recovery dependencies, drill date	Can authorized successors recover without one undocumented memory?	Required person or record has no tested substitute
Physical coercion	Threats to an operator or family member	Qualified personal-safety and legal plan	Does the design avoid concentrating knowledge and unilateral power?	Immediate danger: prioritize personal safety and lawful emergency help

No arrangement removes every threat. Controls can introduce new failure modes: separation can reduce one-site loss but complicate access; extra signers can reduce one-key dependence but add coordination and configuration risk; offline signing can reduce remote key exposure while leaving transaction verification and physical security unresolved.

Map hardware, software, and human boundaries

Boundary	Can help with	Does not establish
Dedicated signing hardware	Keeping signing keys away from a general-purpose host and displaying transaction details	Authentic supply chain, correct firmware, safe backups, honest display, or recoverability
Wallet software	Descriptor management, transaction construction, history, labels, broadcasting	That the host, update, network view, or proposed transaction is trustworthy
Single-signature design	Lower configuration and coordination complexity	Protection from one-key loss, disclosure, incapacity, or coercion
Multisignature design	Separating authorization across keys or operators under a defined script	Correct configuration, private operation, inheritance, compatibility, or sufficient surviving keys
Watch-only descriptor	Deriving and monitoring scripts without private keys when correctly constructed	A spending path, an honest network view, or concealment of wallet structure
Human procedure	Independent checks, access separation, maintenance, incident decisions	Freedom from mistakes, coercion, legal duties, or undocumented dependencies

A node and wallet are also distinct. A validating node checks blocks under its rules; a wallet handles keys, descriptors, transactions, and related records. See the educational guide to Bitcoin Core validation, wallet, release, and security boundaries.

Create a recovery inventory, not just a secret copy

Record	Question	Sensitivity	Test evidence
Mnemonic or seed material	Which standard, language, checksum, and transcription method apply?	Usually critical secret material	Independent transcription check using non-networked procedure
Passphrase	Is one used, how are exact characters preserved, and is it separated appropriately?	Secret and availability-critical	Known test wallet derives the expected result
Descriptor and key origins	Which script type, threshold, fingerprints, paths, ranges, and checksum apply?	Public forms reveal structure; private forms are secrets	Expected receive scripts or addresses are reproduced
Wallet data and metadata	Are labels, history, birth time, contacts, or policies needed?	May expose identity and transaction relationships	Restored wallet scans the intended range and preserves required records
Software and device context	Which version, source, signature, digest, network, and compatibility assumptions apply?	Operational	Pinned restoration environment is documented and independently checked
Access and inheritance record	Who acts, under what trigger, with which legal authority and escalation path?	Highly sensitive	Role-based tabletop exercise without disclosing live secrets

Do not store every secret, instruction, identity, and exact location in one broadly accessible document. Conversely, obscurity that only the original operator understands is not a recovery control. Record enough authenticated context for an authorized person to identify the right procedure without granting unintended unilateral access.

Run a bounded recovery drill

Define the scenario. Name the failed device, missing operator, damaged copy, or software migration being tested. A drill proves only that scenario.
Use non-production material. Create an isolated test wallet and use trivial test value if transaction behavior must be checked. Never paste live secrets into a site, chat, ticket, or general-purpose form.
Record the expected result. Preserve independently derived scripts or addresses, descriptor checksum, network, signer threshold, and relevant scan start or wallet birthday.
Restore using the documented path. Match the standard, exact passphrase, descriptor, derivation, and compatible software. Record release provenance and prompts.
Compare independently. Confirm expected scripts or addresses and authorization threshold through a separate trusted view. Do not infer success from a familiar balance screen alone.
Test authorization carefully. If needed, use the test wallet to construct, inspect, authorize, broadcast, and confirm a trivial test transaction. Do not convert this exercise into instructions for moving production funds.
Close the drill. Remove temporary test artifacts according to the plan, preserve the evidence log, document discrepancies, and schedule review. Never wipe the only working signer or destroy the only verified backup.

Recovery acceptance: the intended scripts or addresses match; the required threshold is understood; the documented operators can follow the runbook; software provenance is recorded; the relevant history can be found; and no production secret was exposed during the test.

Design inheritance around roles and conditions

An inheritance plan must join technical recovery with applicable law. Identify the owner, fiduciary or executor roles, technical helpers, beneficiaries, incapacity and death triggers, authentication method, access dependencies, and a qualified legal contact. Do not assume a technically valid signature settles ownership, authority, tax, or estate obligations.

Separate the fact that an asset exists from complete spending authority where appropriate.
Document which wallet, descriptor, threshold, passphrase, and software context successors need.
Ensure no required step depends only on one person’s undocumented memory.
Use a tabletop exercise to test roles without exposing live authorization material.
Review after changes to people, locations, law, wallet software, scripts, or devices.

Incident response: stop before improvising

Signal	Immediate safe action	Evidence and escalation	Avoid
Mnemonic, passphrase, private key, or private descriptor may be exposed	Stop entering or copying it; isolate affected systems and invoke the prewritten incident plan.	Record what was exposed, when, where, and which scripts may be affected; obtain qualified incident help.	Testing the suspected secret on random websites or announcing details publicly
Destination, change, fee, or signer display is unexpected	Do not authorize or broadcast.	Preserve the unsigned transaction and logs; verify intent using an independent trusted path.	Repeated blind attempts or bypassing signer checks
Signer or backup is missing or damaged	Freeze destructive changes and inventory surviving dependencies.	Use the documented recovery decision tree and validate with a non-production rehearsal first.	Wiping remaining devices or changing configuration before evidence is captured
Wrong passphrase or empty wallet appears	Stop repeated guesses on untrusted systems.	Check exact characters, standard, network, derivation, descriptor, and expected script evidence.	Assuming an empty view proves loss or importing secrets into unknown software
Death, incapacity, or physical threat	Prioritize personal safety and the documented lawful response.	Contact the authorized legal or emergency roles in the plan.	Improvised concealment, confrontation, or evasion tactics

Periodic review worksheet

Assets and scripts in scope:
People and roles, including incapacity substitutes:
Authorization threshold and signer inventory:
Mnemonic, passphrase, descriptor, wallet-data, and metadata dependencies:
Hardware, software, release, signature, digest, and network assumptions:
Physical, host, supply-chain, privacy, coercion, legal, and availability threats:
Last non-production recovery drill, expected evidence, discrepancies, and owner:
Incident contacts, escalation conditions, and explicit stop gates:
Next review date and change triggers:

Pinned primary sources and revision record

Reviewed 2026-08-29. Protocol and implementation references are pinned to the exact revisions below. Pinning makes this review reproducible; it does not make software, law, wallet behavior, or device documentation permanently current.

Frequently asked questions

What is the difference between a private key, a seed, and a mnemonic?

A private key can satisfy a specific spending condition. A deterministic wallet can derive many keys from a seed. A BIP39 mnemonic is an encoded representation of entropy and checksum material that is transformed, with any passphrase, into a seed. Exact behavior depends on the wallet standard and implementation.

Is a BIP39 passphrase simply a 25th word?

No. It is an optional, case-sensitive string used in BIP39 seed derivation and need not be one word. Every entered passphrase produces a seed, so a typo can silently open a different wallet rather than show an error.

Is a mnemonic backup always enough to recover a wallet?

No. Recovery can also require the correct passphrase, derivation and script information, descriptor or multisignature configuration, wallet version, and a compatible restoration path. Test the exact documented design without exposing production secrets.

What does a wallet descriptor add to a recovery record?

A descriptor can identify scripts, keys or key origins, derivation paths, and checksums used to derive addresses. A public descriptor may support watch-only recovery; a descriptor containing private material must be protected as a secret.

Does a hardware signing device guarantee secure self-custody?

No. It can change some key-exposure risks, while software, firmware, supply chain, backups, user verification, physical access, recovery compatibility, and coercion remain separate boundaries.

How can a recovery procedure be tested more safely?

Use an isolated test plan with non-production secrets and trivial test value, record the expected scripts or addresses, restore with the documented compatible software, and compare results independently. Do not type live secrets into a webpage or wipe the only working signer.

Is multisignature always safer than single-signature custody?

No. It can reduce some single-key failures but adds configuration, coordination, privacy, inheritance, and recovery risks. Its suitability depends on the defined threats, operators, backups, and tested failure cases.

What should an inheritance plan record?

Record roles, access conditions, the wallet and recovery data required, verification steps, incapacity or death triggers, review dates, and qualified legal guidance. Avoid placing every secret or precise secret location in one broadly shared document.