Who this is for
People operating a personal Bitcoin custody setup, educators explaining self-custody, and developers who need stable public IDs for safety guidance. The model is not tailored to a person, balance, jurisdiction, or adversary.
Immutable research releaseFrozen release
Bitcoin custody threat model 1.0.0
This permanent release preserves the exact taxonomy, relationships, sources, and language records published on August 28, 2026.
- Version
- 1.0.0
- Published
- August 28, 2026
- Last reviewed
- August 28, 2026
Transparent framework
What this model protects and assumes
A public framework for examining how operational failures and attacks can cause unauthorized spending, loss of recovery capability, privacy exposure, or a breakdown in continuity. It links each threat to controls, expected evidence, and remaining risk.
No score or certification
This publication is a reasoning framework, not a safety score, audit, warranty, product endorsement, or certification. Public documentation can be incomplete, implementations can contain defects, and correctly applied controls still leave residual risk.
Operating assumptions
Spending authority follows valid keys and policy
A party that can satisfy the wallet policy can authorize a spend. Losing every valid recovery path can make funds inaccessible even when the Bitcoin network continues to operate.
General-purpose devices and services can fail or be compromised
Phones, computers, browser sessions, cloud accounts, exchanges, coordinators, and communication channels are treated as fallible rather than trusted by default.
Human error is part of the operating environment
The model includes mistakes in backup handling, recovery, transaction review, access control, documentation, and handoff. It does not assume a perfectly trained operator.
Only inspectable evidence supports a published control claim
A control is documented only to the level supported by public specifications, vendor documentation, reproducible records, or an identified review. Absence of a disclosed problem is not proof of safety.
Protected assets
Spending authority
Private keys, signing devices, passphrases, policies, and quorum components that can authorize a transaction.
Recovery capability
Backups, wallet metadata, derivation information, instructions, and tested procedures required to restore access.
Transaction intent
The intended recipient, amount, fee, change, inputs, and signing policy for a proposed spend.
Wallet privacy and metadata
Addresses, extended public keys, balances, transaction history, counterparties, and ownership relationships.
Operational continuity
The ability of an authorized person to understand, maintain, recover, and transfer the setup over time.
Method
Scope, identify, respond, review
The model follows a scope, threat, response, and review sequence. Priorities describe how directly a stated condition can lead to loss; they do not estimate probability. Controls reduce specific failure paths but never establish that a wallet or setup is safe.
High attention
highThe stated condition can directly enable unauthorized spending or permanent loss of access. This label does not estimate how likely the event is.
Important
importantThe condition can block recovery, weaken verification, or make another failure materially harder to contain.
Context dependent
contextualThe consequence depends strongly on the custody model, value at risk, adversary, jurisdiction, or operating frequency. It still requires an explicit decision.
Six operating layers, reviewed separately
The model keeps custody authority, backups, recovery, access, transaction review, and continuity distinct so one strong control cannot hide a weakness elsewhere.
012 threats
Custody authority
Who can authorize spending, and which parties or components must be trusted to remain available and honest.
022 threats
Backup resilience
Whether recovery material survives loss and remains unavailable to unauthorized people.
032 threats
Recovery readiness
Whether the keys, wallet context, tools, and procedure can restore the intended wallet before an emergency.
042 threats
Access protection
How provider accounts, general-purpose devices, wallet software, and signing interfaces resist takeover or compromise.
052 threats
Transaction verification
Whether the signer can independently confirm what will be authorized before a transaction becomes irreversible.
062 threats
Continuity and succession
Whether an authorized successor can locate the right non-secret information and follow a tested process without exposing every secret together.
Every threat connects to a response and remaining risk
The visual summary is generated from the same relationship records as the downloads. The text list below carries the same information without relying on color or position.
Text equivalent of the category relationship diagram
- Custody authority
- 2 threats · 4 controls
- Backup resilience
- 2 threats · 3 controls
- Recovery readiness
- 2 threats · 2 controls
- Access protection
- 2 threats · 5 controls
- Transaction verification
- 2 threats · 2 controls
- Continuity and succession
- 2 threats · 3 controls
Inspect the records
Threat, control, evidence, and residual-risk matrix
Priority indicates how directly the stated condition can cause loss. It is not a probability, product rating, or personalized risk score.
Custody authorityHigh attention
threat-custody-provider-control
A provider controls withdrawal or signing
- Scenario
- An exchange, custodian, hosted wallet, or policy service can delay, refuse, redirect, or lose the ability to authorize a withdrawal.
- Why it matters
- The operator does not hold every key needed to spend. Provider solvency, account controls, policy, jurisdiction, and availability remain part of the custody boundary.
- Controls
- Write down the custody boundary; Use phishing-resistant account access where available
- Expected evidence
- Custody boundary evidence; Access-control evidence
- Residual risk
- Custody dependencies remain; Strong access controls do not secure every dependency
Custody authorityHigh attention
threat-custody-signer-compromise
Enough signing authority is stolen or copied
- Scenario
- An attacker obtains a private key, recovery phrase, passphrase, signing device, or enough quorum components to satisfy the wallet policy.
- Why it matters
- Bitcoin validates authorization, not the identity or intent of the person presenting a valid signature. Separation only helps while the policy threshold remains uncompromised.
- Controls
- Isolate enough signing authority; Separate secrets from instructions and from each other
- Expected evidence
- Custody boundary evidence; Backup evidence
- Residual risk
- Custody dependencies remain; Availability and secrecy remain in tension
Backup resilienceHigh attention
threat-backup-unavailable
Recovery material is missing or unreadable
- Scenario
- Loss, fire, water, corrosion, accidental disposal, memory failure, or a single shared location removes every usable backup.
- Why it matters
- Deterministic wallet recovery depends on retaining the required seed or key material. A backup that has not been checked may fail only after the signing device is gone.
- Controls
- Maintain checked backups across failure boundaries; Rehearse recovery before an emergency
- Expected evidence
- Backup evidence; Recovery evidence
- Residual risk
- Availability and secrecy remain in tension; A past rehearsal cannot guarantee a future recovery
Backup resilienceHigh attention
threat-backup-secret-exposure
A backup exposes signing secrets
- Scenario
- Recovery words, private keys, or passphrases enter a photo, cloud document, ordinary computer, shared note, or location accessible to an unauthorized person.
- Why it matters
- A deterministic seed can derive the wallet’s private keys. Redundancy improves availability but also creates more copies that require confidentiality and access control.
- Controls
- Separate secrets from instructions and from each other; Maintain checked backups across failure boundaries
- Expected evidence
- Backup evidence
- Residual risk
- Availability and secrecy remain in tension
Recovery readinessImportant
threat-recovery-not-rehearsed
The recovery procedure has not been rehearsed
- Scenario
- During device loss or failure, the operator discovers an incorrect word, forgotten passphrase, incompatible wallet, missing signer, or procedure they cannot complete.
- Why it matters
- Possessing backup material does not prove that the complete wallet can be reconstructed. A controlled rehearsal can reveal procedural and compatibility failures before funds depend on recovery.
- Controls
- Rehearse recovery before an emergency; Preserve non-secret wallet context
- Expected evidence
- Recovery evidence
- Residual risk
- A past rehearsal cannot guarantee a future recovery
Recovery readinessImportant
threat-recovery-wallet-context-missing
Keys survive but wallet context is missing
- Scenario
- A recovery has the seed or keys but lacks the script type, derivation path, descriptor, quorum policy, cosigner keys, or coordinator information needed to find and spend the intended outputs.
- Why it matters
- BIP 380 documents why private keys alone can be insufficient to reconstruct the scripts and derivation paths a wallet used, especially for non-default or multisignature policies.
- Controls
- Preserve non-secret wallet context; Rehearse recovery before an emergency
- Expected evidence
- Recovery evidence
- Residual risk
- A past rehearsal cannot guarantee a future recovery; Availability and secrecy remain in tension
Access protectionHigh attention
threat-access-provider-account-takeover
A provider account is taken over
- Scenario
- Phishing, password reuse, session theft, weak recovery, or compromised email lets an attacker control an exchange, hosted wallet, cloud backup, or communication account.
- Why it matters
- Account controls can become part of custody, backup confidentiality, or continuity. Manually entered one-time codes are not phishing-resistant under NIST’s definition.
- Controls
- Use phishing-resistant account access where available; Write down the custody boundary
- Expected evidence
- Access-control evidence; Custody boundary evidence
- Residual risk
- Strong access controls do not secure every dependency; Custody dependencies remain
Access protectionHigh attention
threat-access-signing-environment-compromise
The signing environment is compromised
- Scenario
- Malware, a malicious update, remote access, a counterfeit application, or a modified device attempts to expose keys or alter transaction data.
- Why it matters
- Separating signing from a networked host reduces key-exfiltration opportunities, but the signer, transfer channel, firmware, and review process remain trust boundaries.
- Controls
- Reduce trust in the networked signing environment; Isolate enough signing authority; Verify transaction intent on an independent display
- Expected evidence
- Access-control evidence; Transaction-verification evidence
- Residual risk
- Strong access controls do not secure every dependency; Verification can still fail at the human or display layer
Transaction verificationHigh attention
threat-transaction-destination-substitution
The destination or amount is substituted
- Scenario
- A compromised host, clipboard, QR code, payment request, or coordinator presents transaction details that differ from the operator’s intent.
- Why it matters
- A valid signature authorizes the transaction actually presented to the signer. Independent review must cover the destination, amount, fee, and change using a trusted channel or display.
- Controls
- Verify transaction intent on an independent display; Separate transaction creation, signing, and broadcast where useful
- Expected evidence
- Transaction-verification evidence
- Residual risk
- Verification can still fail at the human or display layer
Transaction verificationImportant
threat-transaction-incomplete-signing-context
The signer lacks enough context to verify the spend
- Scenario
- The signing device or person cannot reliably identify inputs, change, fees, wallet policy, or whether another system modified the proposed transaction.
- Why it matters
- PSBT standardizes data exchange between transaction roles, but a format alone does not prove that a signer displayed or checked every decision-relevant field.
- Controls
- Separate transaction creation, signing, and broadcast where useful; Verify transaction intent on an independent display
- Expected evidence
- Transaction-verification evidence
- Residual risk
- Verification can still fail at the human or display layer
Continuity and successionImportant
threat-continuity-operator-unavailability
The only informed operator is unavailable
- Scenario
- Death, incapacity, travel, coercion, conflict, or simple loss of contact leaves authorized successors unable to locate the wallet or understand the recovery process.
- Why it matters
- Technical recovery material does not communicate legal authority, roles, locations, dependencies, or the order of operations. Continuity requires documented and tested handoff procedures.
- Controls
- Document roles, dependencies, and locations without recording secrets; Rehearse the continuity handoff
- Expected evidence
- Continuity evidence
- Residual risk
- Succession combines technical and legal uncertainty; A past rehearsal cannot guarantee a future recovery
Continuity and successionHigh attention
threat-continuity-secret-concentration
A continuity document concentrates every secret
- Scenario
- One document, safe, lawyer, relative, or digital account contains enough recovery material and instructions to authorize spending without another independent control.
- Why it matters
- Continuity can improve availability while weakening confidentiality. A useful handoff explains roles and locations without turning one discoverable record into complete spending authority.
- Controls
- Document roles, dependencies, and locations without recording secrets; Separate secrets from instructions and from each other; Rehearse the continuity handoff
- Expected evidence
- Continuity evidence; Backup evidence
- Residual risk
- Succession combines technical and legal uncertainty; Availability and secrecy remain in tension
Controls
Mapped controls
mitigation-define-custody-boundary
Write down the custody boundary
- Action
- Identify every person, provider, device, key, policy, and recovery process that can authorize or block a spend. Decide which dependencies are acceptable before moving meaningful funds.
- Limit
- Documentation makes dependencies visible; it does not remove provider, legal, solvency, or implementation risk.
mitigation-isolate-signing-keys
Isolate enough signing authority
- Action
- Keep private keys away from ordinary networked devices when the operating model supports it. For quorum wallets, separate signers so one compromise does not satisfy the policy.
- Limit
- Isolation adds transfer, update, verification, and recovery steps. It does not prove that the signer or firmware is trustworthy.
mitigation-redundant-offline-backups
Maintain checked backups across failure boundaries
- Action
- Keep the required recovery material in more than one protected location when the loss scenario warrants it. Check legibility, completeness, and access without exposing the secret to an online system.
- Limit
- Every extra copy expands the confidentiality and access-control problem. Geographic separation can also complicate timely recovery.
mitigation-separate-secret-material
Separate secrets from instructions and from each other
- Action
- Do not put a seed, passphrase, PIN, and complete recovery procedure in one ordinary document or online account. Use distinct access boundaries that match the wallet policy.
- Limit
- Separation can create lockout if dependencies are undocumented or if an authorized person cannot reunite the required parts.
mitigation-rehearse-recovery
Rehearse recovery before an emergency
- Action
- Use a controlled procedure, a spare or reset device, and a non-valuable test wallet where appropriate. Confirm the expected wallet, policy, addresses, and ability to sign without entering secrets into an untrusted device.
- Limit
- A rehearsal proves only the tested path at that time. Software, devices, people, locations, and documentation can change afterward.
mitigation-preserve-wallet-context
Preserve non-secret wallet context
- Action
- Record the wallet type, script policy, derivation information, master fingerprints, quorum, coordinator requirements, and tested restoration software without combining them with every spending secret.
- Limit
- Descriptors and extended public keys can expose addresses and transaction history. Treat them as privacy-sensitive even when they cannot spend alone.
mitigation-phishing-resistant-access
Use phishing-resistant account access where available
- Action
- Protect provider, email, and cloud accounts with unique credentials and a cryptographic authenticator bound to the real service domain when supported. Review account-recovery paths as part of the same boundary.
- Limit
- Strong authentication does not address provider insolvency, malicious insiders, compromised endpoints, or a flawed withdrawal process.
mitigation-harden-signing-environment
Reduce trust in the networked signing environment
- Action
- Use maintained software from authenticated sources, limit remote access and unnecessary applications, isolate keys when justified, and keep an independent way to verify transaction intent.
- Limit
- Operational hardening reduces exposure but cannot establish that every dependency, update, library, or device is free of defects.
mitigation-verify-on-trusted-display
Verify transaction intent on an independent display
- Action
- Before signing, compare the recipient, amount, fee, change, network, and policy with the original intent on a signer or channel that does not rely solely on the transaction-creating host.
- Limit
- A display can omit fields, present confusing data, or itself be compromised. Verification is only as good as the independent reference and the operator’s review.
mitigation-separate-transaction-roles
Separate transaction creation, signing, and broadcast where useful
- Action
- Use a standard interchange format such as PSBT when multiple systems or signers must cooperate. Require each signer to validate the policy and relevant fields before adding a signature.
- Limit
- Role separation increases coordination and metadata handling. PSBT can contain privacy-sensitive wallet information and does not force a device to display every relevant field.
mitigation-document-continuity-roles
Document roles, dependencies, and locations without recording secrets
- Action
- Record who should act, what non-secret records exist, where separate materials are held, which professionals or providers are involved, and how authority is verified. Keep spending secrets outside the continuity document.
- Limit
- Operational documentation is not an estate plan and may not create legal authority. Jurisdiction-specific legal and tax advice remains separate.
mitigation-rehearse-continuity
Rehearse the continuity handoff
- Action
- Have an authorized participant explain or simulate the process with non-secret records. Confirm contacts, locations, dependencies, device disposition, and escalation paths on a dated schedule.
- Limit
- A rehearsal can expose sensitive relationships and may become stale after family, legal, provider, device, or wallet changes.
Evidence
What a control claim should be able to show
Custody boundary evidence
A current inventory of required signers, providers, policies, recovery paths, and blocking dependencies. Marketing claims alone do not establish control.
Backup evidence
A dated check that required material exists, remains legible, is separated across the intended failure boundaries, and has not been entered into an untrusted system.
Recovery evidence
A dated record of the tested recovery path, wallet identity check, tools used, policy reconstructed, problems found, and remediation. It must not contain the recovery secret itself.
Access-control evidence
Documented account-recovery methods, authenticator type, device and software provenance, update process, and removal of obsolete access.
Transaction-verification evidence
A repeatable procedure identifying which fields each signer checks, the independent source of intent, policy validation, and the point at which broadcast is allowed.
Continuity evidence
A dated non-secret role and location inventory, named owner for each follow-up, rehearsal record, and review trigger after material family, legal, provider, or wallet changes.
Residual risk
What remains after the controls
Custody dependencies remain
Keys, devices, people, providers, and policies can fail together or behave differently from their documentation. More independence usually adds operating complexity.
Availability and secrecy remain in tension
More copies can survive more loss events but create more opportunities for discovery, coercion, mishandling, or stale records.
A past rehearsal cannot guarantee a future recovery
Devices, software compatibility, people, memory, documentation, and wallet state can change after a successful test.
Strong access controls do not secure every dependency
Endpoints, support processes, service insiders, firmware, physical access, and software supply chains remain possible failure paths.
Verification can still fail at the human or display layer
A signer may omit important information, the reference may be compromised, or the operator may approve confusing or unexpected data.
Succession combines technical and legal uncertainty
A technically sound handoff may conflict with law, tax, family circumstances, provider rules, or the current wishes of the owner.
Boundaries
What version 1.0.0 does not assess
Market and price risk
The model does not forecast price, liquidity, tax treatment, or the suitability of holding bitcoin.
Bitcoin consensus and network security
Consensus failures, mining attacks, protocol defects, and network partition analysis are outside this custody-operations model.
Product certification or ranking
The model does not certify a hardware wallet, software wallet, exchange, custodian, multisignature service, or recovery provider.
Personalized risk determination
No priority in this publication accounts for a reader’s balance, skills, adversaries, location, family, or operating frequency.
Legal, tax, and estate advice
Continuity controls describe operations only. They do not create legal authority or replace qualified advice in the relevant jurisdiction.
Evidence base
Specifications, standards, and review sources
Sources support specific technical or process statements. General NIST and CISA guidance is identified as general guidance rather than Bitcoin-specific proof.
- NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
National Institute of Standards and Technology
Used for explicit scope, assumptions, threat sources, uncertainty, and review discipline. BitcoinSafe does not copy NIST probability scales.
Checked: 2026-08-28
- OWASP Threat Modeling Cheat Sheet
OWASP Foundation
Used for the scope, identify, respond, and review sequence and for documenting actionable mitigations.
Checked: 2026-08-28
- Bitcoin Developer Guide: Wallets
Bitcoin Developer Documentation
Used for the separation of key distribution, signing, and network functions and the role of private keys in spending.
Checked: 2026-08-28
- BIP 32: Hierarchical Deterministic Wallets
Bitcoin Improvement Proposals
Used for deterministic key derivation and the consequence of exposing or losing root key material.
Checked: 2026-08-28
- BIP 39: Mnemonic code for generating deterministic keys
Bitcoin Improvement Proposals
Used only to describe mnemonic recovery material and optional passphrase behavior. The model does not claim BIP 39 is required for every wallet.
Checked: 2026-08-28
- BIP 174: Partially Signed Bitcoin Transaction Format
Bitcoin Improvement Proposals
Used for transaction-role separation, offline signing, signer inputs, and PSBT metadata boundaries.
Checked: 2026-08-28
- BIP 380: Output Script Descriptors General Operation
Bitcoin Improvement Proposals
Used for the recovery importance of script type, derivation paths, keys, and descriptor checksums beyond private keys alone.
Checked: 2026-08-28
- Bitcoin Core Offline Signing Tutorial
Bitcoin Core
Used for the documented security purpose and operational boundary of offline PSBT signing.
Checked: 2026-08-28
- Bitcoin Core External Signer Documentation
Bitcoin Core
Used for external-signer identity checks, descriptor matching, and address display behavior.
Checked: 2026-08-28
- NIST SP 800-63B-4: Authentication and Authenticator Management
National Institute of Standards and Technology
Used for phishing resistance, verifier binding, authenticator controls, and the limit of manually entered one-time codes.
Checked: 2026-08-28
- #StopRansomware Guide
Cybersecurity and Infrastructure Security Agency
Used for the general practice of offline backups and regular restoration testing. Bitcoin recovery adds separate secrecy constraints.
Checked: 2026-08-28
- NIST SP 800-34 Rev. 1: Contingency Planning Guide
National Institute of Standards and Technology
Used for roles, recovery procedures, testing, validation, offsite material, and dated continuity records. It is general contingency guidance, not Bitcoin-specific advice.
Checked: 2026-08-28
- Creative Commons Attribution 4.0 International
Creative Commons
Defines the reuse terms for the scoped research prose and data.
Checked: 2026-08-28
- Semantic Versioning 2.0.0
Semantic Versioning
Defines the immutable release and major, minor, and patch version rules used by this model.
Checked: 2026-08-28
Corrections create a new version
Patch versions correct wording or sources without changing category meaning. Minor versions add compatible records. Major versions can change assumptions or taxonomy. Prior release files remain available.
- 1.0.02026-08-28
Initial public release with six custody categories, 12 threats, 12 mitigations, evidence expectations, residual risks, assessment mappings, and localized research artifacts.
Reuse the research with attribution
The model prose, taxonomy, relationships, and generated research files are CC BY 4.0. Application code and unrelated site content are outside that license notice.
- Suggested citation
- Kinnett, Kevin. (2026). BitcoinSafe Open Bitcoin Custody Threat Model (Version 1.0.0). BitcoinSafe.
- Creative Commons Attribution 4.0 International
- The threat-model prose, taxonomy, relationship data, and generated research files are licensed under CC BY 4.0. Application code and unrelated site content are outside this notice.
Reusable research files
Use the same records that build this page
The JSON and Markdown files contain the same stable IDs and relationships shown below. Released files are never rewritten in place.
Printing runs in your browser and sends no model or assessment data.
Use the framework without sending BitcoinSafe your answers
The assessment evaluates six operating practices in your browser. It does not ask for seed words, private keys, addresses, balances, or wallet files.
Related safety resources
Continue from this risk to the next practical decision
Use the broad safety map when you need context, or open the closest specialist guide for the next action.
Check your own setup with the private threat assessment
Review six operating practices locally and receive explainable priorities without entering wallet secrets.
Start with the complete Bitcoin safety map
Separate network, price, custody, scam, transaction, backup, and inheritance risk before choosing a control.
Build the layers that keep bitcoin safer
Connect custody, backups, access control, transaction verification, recovery, and continuity into one process.
Build a Bitcoin inheritance checklist
Separate asset discovery, authority, instructions, and secret access so heirs do not have to guess.