# BitcoinSafe Open Bitcoin Custody Threat Model

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.

- **Release:** 1.0.0
- **Published:** 2026-08-28
- **Last reviewed:** 2026-08-28

## Audience

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.

## Methodology

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.

### Certification boundary

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.

## Assumptions

<a id="assumption-bitcoin-key-authority"></a>
### 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.

<a id="assumption-hosts-can-fail"></a>
### 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.

<a id="assumption-human-operation"></a>
### 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.

<a id="assumption-public-evidence"></a>
### 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** (`asset-spending-authority`): Private keys, signing devices, passphrases, policies, and quorum components that can authorize a transaction.
- **Recovery capability** (`asset-recovery-capability`): Backups, wallet metadata, derivation information, instructions, and tested procedures required to restore access.
- **Transaction intent** (`asset-transaction-intent`): The intended recipient, amount, fee, change, inputs, and signing policy for a proposed spend.
- **Wallet privacy and metadata** (`asset-privacy-metadata`): Addresses, extended public keys, balances, transaction history, counterparties, and ownership relationships.
- **Operational continuity** (`asset-operational-continuity`): The ability of an authorized person to understand, maintain, recover, and transfer the setup over time.

## Priority language

- **High attention** (`high`): The stated condition can directly enable unauthorized spending or permanent loss of access. This label does not estimate how likely the event is.
- **Important** (`important`): The condition can block recovery, weaken verification, or make another failure materially harder to contain.
- **Context dependent** (`contextual`): The consequence depends strongly on the custody model, value at risk, adversary, jurisdiction, or operating frequency. It still requires an explicit decision.

## Threat categories and relationships

<a id="custody"></a>
### Custody authority

Who can authorize spending, and which parties or components must be trusted to remain available and honest.

<a id="threat-custody-provider-control"></a>
#### A provider controls withdrawal or signing

- **ID:** `threat-custody-provider-control`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Write down the custody boundary](#mitigation-define-custody-boundary), [Use phishing-resistant account access where available](#mitigation-phishing-resistant-access)
- **Evidence expectations:** [Custody boundary evidence](#evidence-custody-boundary), [Access-control evidence](#evidence-access-controls)
- **Residual risks:** [Custody dependencies remain](#residual-custody), [Strong access controls do not secure every dependency](#residual-access)

<a id="threat-custody-signer-compromise"></a>
#### Enough signing authority is stolen or copied

- **ID:** `threat-custody-signer-compromise`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Isolate enough signing authority](#mitigation-isolate-signing-keys), [Separate secrets from instructions and from each other](#mitigation-separate-secret-material)
- **Evidence expectations:** [Custody boundary evidence](#evidence-custody-boundary), [Backup evidence](#evidence-backup-check)
- **Residual risks:** [Custody dependencies remain](#residual-custody), [Availability and secrecy remain in tension](#residual-backup)

<a id="backup"></a>
### Backup resilience

Whether recovery material survives loss and remains unavailable to unauthorized people.

<a id="threat-backup-unavailable"></a>
#### Recovery material is missing or unreadable

- **ID:** `threat-backup-unavailable`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Maintain checked backups across failure boundaries](#mitigation-redundant-offline-backups), [Rehearse recovery before an emergency](#mitigation-rehearse-recovery)
- **Evidence expectations:** [Backup evidence](#evidence-backup-check), [Recovery evidence](#evidence-recovery-rehearsal)
- **Residual risks:** [Availability and secrecy remain in tension](#residual-backup), [A past rehearsal cannot guarantee a future recovery](#residual-recovery)

<a id="threat-backup-secret-exposure"></a>
#### A backup exposes signing secrets

- **ID:** `threat-backup-secret-exposure`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Separate secrets from instructions and from each other](#mitigation-separate-secret-material), [Maintain checked backups across failure boundaries](#mitigation-redundant-offline-backups)
- **Evidence expectations:** [Backup evidence](#evidence-backup-check)
- **Residual risks:** [Availability and secrecy remain in tension](#residual-backup)

<a id="recovery"></a>
### Recovery readiness

Whether the keys, wallet context, tools, and procedure can restore the intended wallet before an emergency.

<a id="threat-recovery-not-rehearsed"></a>
#### The recovery procedure has not been rehearsed

- **ID:** `threat-recovery-not-rehearsed`
- **Priority language:** `important`
- **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.
- **Mitigations:** [Rehearse recovery before an emergency](#mitigation-rehearse-recovery), [Preserve non-secret wallet context](#mitigation-preserve-wallet-context)
- **Evidence expectations:** [Recovery evidence](#evidence-recovery-rehearsal)
- **Residual risks:** [A past rehearsal cannot guarantee a future recovery](#residual-recovery)

<a id="threat-recovery-wallet-context-missing"></a>
#### Keys survive but wallet context is missing

- **ID:** `threat-recovery-wallet-context-missing`
- **Priority language:** `important`
- **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.
- **Mitigations:** [Preserve non-secret wallet context](#mitigation-preserve-wallet-context), [Rehearse recovery before an emergency](#mitigation-rehearse-recovery)
- **Evidence expectations:** [Recovery evidence](#evidence-recovery-rehearsal)
- **Residual risks:** [A past rehearsal cannot guarantee a future recovery](#residual-recovery), [Availability and secrecy remain in tension](#residual-backup)

<a id="access"></a>
### Access protection

How provider accounts, general-purpose devices, wallet software, and signing interfaces resist takeover or compromise.

<a id="threat-access-provider-account-takeover"></a>
#### A provider account is taken over

- **ID:** `threat-access-provider-account-takeover`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Use phishing-resistant account access where available](#mitigation-phishing-resistant-access), [Write down the custody boundary](#mitigation-define-custody-boundary)
- **Evidence expectations:** [Access-control evidence](#evidence-access-controls), [Custody boundary evidence](#evidence-custody-boundary)
- **Residual risks:** [Strong access controls do not secure every dependency](#residual-access), [Custody dependencies remain](#residual-custody)

<a id="threat-access-signing-environment-compromise"></a>
#### The signing environment is compromised

- **ID:** `threat-access-signing-environment-compromise`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Reduce trust in the networked signing environment](#mitigation-harden-signing-environment), [Isolate enough signing authority](#mitigation-isolate-signing-keys), [Verify transaction intent on an independent display](#mitigation-verify-on-trusted-display)
- **Evidence expectations:** [Access-control evidence](#evidence-access-controls), [Transaction-verification evidence](#evidence-transaction-verification)
- **Residual risks:** [Strong access controls do not secure every dependency](#residual-access), [Verification can still fail at the human or display layer](#residual-transaction)

<a id="transaction"></a>
### Transaction verification

Whether the signer can independently confirm what will be authorized before a transaction becomes irreversible.

<a id="threat-transaction-destination-substitution"></a>
#### The destination or amount is substituted

- **ID:** `threat-transaction-destination-substitution`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Verify transaction intent on an independent display](#mitigation-verify-on-trusted-display), [Separate transaction creation, signing, and broadcast where useful](#mitigation-separate-transaction-roles)
- **Evidence expectations:** [Transaction-verification evidence](#evidence-transaction-verification)
- **Residual risks:** [Verification can still fail at the human or display layer](#residual-transaction)

<a id="threat-transaction-incomplete-signing-context"></a>
#### The signer lacks enough context to verify the spend

- **ID:** `threat-transaction-incomplete-signing-context`
- **Priority language:** `important`
- **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.
- **Mitigations:** [Separate transaction creation, signing, and broadcast where useful](#mitigation-separate-transaction-roles), [Verify transaction intent on an independent display](#mitigation-verify-on-trusted-display)
- **Evidence expectations:** [Transaction-verification evidence](#evidence-transaction-verification)
- **Residual risks:** [Verification can still fail at the human or display layer](#residual-transaction)

<a id="continuity"></a>
### Continuity and succession

Whether an authorized successor can locate the right non-secret information and follow a tested process without exposing every secret together.

<a id="threat-continuity-operator-unavailability"></a>
#### The only informed operator is unavailable

- **ID:** `threat-continuity-operator-unavailability`
- **Priority language:** `important`
- **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.
- **Mitigations:** [Document roles, dependencies, and locations without recording secrets](#mitigation-document-continuity-roles), [Rehearse the continuity handoff](#mitigation-rehearse-continuity)
- **Evidence expectations:** [Continuity evidence](#evidence-continuity-rehearsal)
- **Residual risks:** [Succession combines technical and legal uncertainty](#residual-continuity), [A past rehearsal cannot guarantee a future recovery](#residual-recovery)

<a id="threat-continuity-secret-concentration"></a>
#### A continuity document concentrates every secret

- **ID:** `threat-continuity-secret-concentration`
- **Priority language:** `high`
- **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.
- **Mitigations:** [Document roles, dependencies, and locations without recording secrets](#mitigation-document-continuity-roles), [Separate secrets from instructions and from each other](#mitigation-separate-secret-material), [Rehearse the continuity handoff](#mitigation-rehearse-continuity)
- **Evidence expectations:** [Continuity evidence](#evidence-continuity-rehearsal), [Backup evidence](#evidence-backup-check)
- **Residual risks:** [Succession combines technical and legal uncertainty](#residual-continuity), [Availability and secrecy remain in tension](#residual-backup)

## Mitigations

<a id="mitigation-define-custody-boundary"></a>
### Write down the custody boundary

- **ID:** `mitigation-define-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.
- **Limitation:** Documentation makes dependencies visible; it does not remove provider, legal, solvency, or implementation risk.

<a id="mitigation-isolate-signing-keys"></a>
### Isolate enough signing authority

- **ID:** `mitigation-isolate-signing-keys`
- **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.
- **Limitation:** Isolation adds transfer, update, verification, and recovery steps. It does not prove that the signer or firmware is trustworthy.

<a id="mitigation-redundant-offline-backups"></a>
### Maintain checked backups across failure boundaries

- **ID:** `mitigation-redundant-offline-backups`
- **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.
- **Limitation:** Every extra copy expands the confidentiality and access-control problem. Geographic separation can also complicate timely recovery.

<a id="mitigation-separate-secret-material"></a>
### Separate secrets from instructions and from each other

- **ID:** `mitigation-separate-secret-material`
- **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.
- **Limitation:** Separation can create lockout if dependencies are undocumented or if an authorized person cannot reunite the required parts.

<a id="mitigation-rehearse-recovery"></a>
### Rehearse recovery before an emergency

- **ID:** `mitigation-rehearse-recovery`
- **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.
- **Limitation:** A rehearsal proves only the tested path at that time. Software, devices, people, locations, and documentation can change afterward.

<a id="mitigation-preserve-wallet-context"></a>
### Preserve non-secret wallet context

- **ID:** `mitigation-preserve-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.
- **Limitation:** Descriptors and extended public keys can expose addresses and transaction history. Treat them as privacy-sensitive even when they cannot spend alone.

<a id="mitigation-phishing-resistant-access"></a>
### Use phishing-resistant account access where available

- **ID:** `mitigation-phishing-resistant-access`
- **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.
- **Limitation:** Strong authentication does not address provider insolvency, malicious insiders, compromised endpoints, or a flawed withdrawal process.

<a id="mitigation-harden-signing-environment"></a>
### Reduce trust in the networked signing environment

- **ID:** `mitigation-harden-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.
- **Limitation:** Operational hardening reduces exposure but cannot establish that every dependency, update, library, or device is free of defects.

<a id="mitigation-verify-on-trusted-display"></a>
### Verify transaction intent on an independent display

- **ID:** `mitigation-verify-on-trusted-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.
- **Limitation:** 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.

<a id="mitigation-separate-transaction-roles"></a>
### Separate transaction creation, signing, and broadcast where useful

- **ID:** `mitigation-separate-transaction-roles`
- **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.
- **Limitation:** 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.

<a id="mitigation-document-continuity-roles"></a>
### Document roles, dependencies, and locations without recording secrets

- **ID:** `mitigation-document-continuity-roles`
- **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.
- **Limitation:** Operational documentation is not an estate plan and may not create legal authority. Jurisdiction-specific legal and tax advice remains separate.

<a id="mitigation-rehearse-continuity"></a>
### Rehearse the continuity handoff

- **ID:** `mitigation-rehearse-continuity`
- **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.
- **Limitation:** A rehearsal can expose sensitive relationships and may become stale after family, legal, provider, device, or wallet changes.

## Evidence expectations

<a id="evidence-custody-boundary"></a>
### Custody boundary evidence

A current inventory of required signers, providers, policies, recovery paths, and blocking dependencies. Marketing claims alone do not establish control.

<a id="evidence-backup-check"></a>
### 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.

<a id="evidence-recovery-rehearsal"></a>
### 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.

<a id="evidence-access-controls"></a>
### Access-control evidence

Documented account-recovery methods, authenticator type, device and software provenance, update process, and removal of obsolete access.

<a id="evidence-transaction-verification"></a>
### 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.

<a id="evidence-continuity-rehearsal"></a>
### 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 risks

<a id="residual-custody"></a>
### Custody dependencies remain

Keys, devices, people, providers, and policies can fail together or behave differently from their documentation. More independence usually adds operating complexity.

<a id="residual-backup"></a>
### 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 id="residual-recovery"></a>
### A past rehearsal cannot guarantee a future recovery

Devices, software compatibility, people, memory, documentation, and wallet state can change after a successful test.

<a id="residual-access"></a>
### Strong access controls do not secure every dependency

Endpoints, support processes, service insiders, firmware, physical access, and software supply chains remain possible failure paths.

<a id="residual-transaction"></a>
### 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.

<a id="residual-continuity"></a>
### 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.

## Exclusions

- **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.

## Sources

- <a id="source-nist-risk-assessment"></a>[NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments](https://doi.org/10.6028/NIST.SP.800-30r1) — National Institute of Standards and Technology. Used for explicit scope, assumptions, threat sources, uncertainty, and review discipline. BitcoinSafe does not copy NIST probability scales.
- <a id="source-owasp-threat-modeling"></a>[OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) — OWASP Foundation. Used for the scope, identify, respond, and review sequence and for documenting actionable mitigations.
- <a id="source-bitcoin-wallet-guide"></a>[Bitcoin Developer Guide: Wallets](https://developer.bitcoin.org/devguide/wallets.html) — Bitcoin Developer Documentation. Used for the separation of key distribution, signing, and network functions and the role of private keys in spending.
- <a id="source-bip32"></a>[BIP 32: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) — Bitcoin Improvement Proposals. Used for deterministic key derivation and the consequence of exposing or losing root key material.
- <a id="source-bip39"></a>[BIP 39: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) — 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.
- <a id="source-bip174"></a>[BIP 174: Partially Signed Bitcoin Transaction Format](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) — Bitcoin Improvement Proposals. Used for transaction-role separation, offline signing, signer inputs, and PSBT metadata boundaries.
- <a id="source-bip380"></a>[BIP 380: Output Script Descriptors General Operation](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki) — Bitcoin Improvement Proposals. Used for the recovery importance of script type, derivation paths, keys, and descriptor checksums beyond private keys alone.
- <a id="source-bitcoin-core-offline-signing"></a>[Bitcoin Core Offline Signing Tutorial](https://github.com/bitcoin/bitcoin/blob/master/doc/offline-signing-tutorial.md) — Bitcoin Core. Used for the documented security purpose and operational boundary of offline PSBT signing.
- <a id="source-bitcoin-core-external-signer"></a>[Bitcoin Core External Signer Documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/external-signer.md) — Bitcoin Core. Used for external-signer identity checks, descriptor matching, and address display behavior.
- <a id="source-nist-authentication"></a>[NIST SP 800-63B-4: Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html) — National Institute of Standards and Technology. Used for phishing resistance, verifier binding, authenticator controls, and the limit of manually entered one-time codes.
- <a id="source-cisa-backups"></a>[#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) — Cybersecurity and Infrastructure Security Agency. Used for the general practice of offline backups and regular restoration testing. Bitcoin recovery adds separate secrecy constraints.
- <a id="source-nist-contingency"></a>[NIST SP 800-34 Rev. 1: Contingency Planning Guide](https://doi.org/10.6028/NIST.SP.800-34r1) — 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.
- <a id="source-cc-by-4"></a>[Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/) — Creative Commons. Defines the reuse terms for the scoped research prose and data.
- <a id="source-semver"></a>[Semantic Versioning 2.0.0](https://semver.org/) — Semantic Versioning. Defines the immutable release and major, minor, and patch version rules used by this model.

## Version history

- **1.0.0 (2026-08-28):** Initial public release with six custody categories, 12 threats, 12 mitigations, evidence expectations, residual risks, assessment mappings, and localized research artifacts.

## Citation and reuse

BitcoinSafe, "BitcoinSafe Open Bitcoin Custody Threat Model," version 1.0.0, 2026-08-28, https://www.bitcoinsafe.com/en/research/bitcoin-threat-model/1.0.0.

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.

- [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
- [CITATION.cff](/research/bitcoin-threat-model/1.0.0/CITATION.cff)
- [Repository source](https://github.com/kevinkinnett/bitcoinsafe/tree/main/public/research/bitcoin-threat-model/1.0.0)
- [Corrections](https://github.com/kevinkinnett/bitcoinsafe/issues)