Self-Custody Threat Model

Self-custody security can become complicated very quickly.

Hardware wallets.

Seed phrases.

Passphrases.

Backups.

Malware.

Phishing.

Physical security.

Privacy.

Inheritance.

Multisignature.

Air gaps.

Multiple locations.

Each topic can matter.

But treating every possible threat as equally important is not a security strategy.

It is a good way to build a system you no longer understand.

A threat model does something simpler.

It asks:

1. What am I protecting?
2. What could realistically go wrong?
3. How serious would that failure be?
4. Which control reduces that risk?
5. What new risk does the control create?
6. Can the complete system still be recovered and operated?

That is the point of threat modeling.

Not to become paranoid.

Not to defend against every imaginable attacker.

Not to build the most complicated custody system you can find online.

The goal is to identify the failures that actually matter in your situation and build a custody system that remains secure, recoverable, and understandable.

This page is educational and is not personalized security or financial advice. It does not provide hiding locations, evasion tactics, wallet-specific setup instructions, or recovery steps. See what that means here.

Threat modeling starts before choosing a product

A common self-custody mistake is starting with the solution.

Someone asks:

Which hardware wallet should I buy?

Or:

Should I use a passphrase?

Or:

Should I use multisig?

Those may eventually be useful questions.

They are not the first question.

Before choosing the control, define the threat.

A hardware wallet can reduce some risks associated with exposing signing keys to a general-purpose computer.

It does not automatically solve:

• seed phrase exposure;
• poor backups;
• family recovery;
• phishing;
• transaction-verification mistakes;
• or a custody design that is too complicated to recover.

A passphrase can reduce one form of single-secret exposure.

It can also create another exact recovery dependency.

Multiple backup locations can reduce one-location disaster risk.

They can also increase exposure, coordination, and maintenance risk.

A security feature only makes sense when you can name the problem it is solving.

Threat first. Control second.

A threat model is not a list of everything that could happen

Almost anything can be imagined.

A sophisticated remote attacker.

A malicious hardware vendor.

A house fire.

A stolen device.

A fraudulent support agent.

A forgotten passphrase.

A family member discarding an unfamiliar backup.

A software failure.

A targeted physical attack.

A meteorite.

The fact that a scenario is possible does not make it a priority.

A useful threat model considers at least two dimensions:

Likelihood

How plausible is this event in your actual environment?

Consequence

If it happens, how serious is the outcome?

Some events are relatively ordinary but high consequence.

Examples include losing the only valid recovery path or exposing a complete seed phrase.

Some events are theoretically serious but extremely specialized.

For most ordinary holders, operational mistakes, phishing, bad backup design, loss, physical damage, and recovery failure may deserve more attention than highly targeted side-channel attacks or exotic adversaries. That same principle already appears in Bitcoin Plaster's existing custody material: realistic risks should be prioritized over sophisticated scenarios simply because they sound more advanced.

Threat modeling is therefore partly an exercise in refusing to let dramatic threats distract you from probable ones.

Step 1: Identify what you are actually protecting

Do not begin with:

My hardware wallet.

The device is only one component.

A self-custody system may depend on several assets.

Spending authority

The keys or script conditions required to authorize a transaction.

Recovery information

The seed phrase, wallet backup, passphrase, or other recovery material required to restore control.

Data integrity

The recovery information must be complete, correct, and associated with the intended wallet.

Availability

The authorized holder must be able to access the system when needed.

Exclusivity of control

An unauthorized person should not be able to gain the same spending authority.

Transaction integrity

The transaction being signed should be the transaction the holder actually intended.

Recovery context

Future-you or another authorized person may need enough non-secret information to understand how the system is supposed to work.

Continuity

The custody system should not depend entirely on one person remaining healthy, available, and able to remember every undocumented detail forever.

This is why self-custody cannot be reduced to protecting one object.

A strong hardware wallet with a weak recovery process is a weak custody system.

A durable seed backup with an unknown passphrase is a weak recovery system.

A technically secure setup that nobody can reconstruct later is a continuity failure waiting to happen.

Step 2: Define what failure means

Security becomes clearer when failure is specific.

For self-custody, most serious failures fall into a few broad outcomes.

Unauthorized control

Someone who should not be able to spend the bitcoin gains enough authority to do so.

Possible causes include exposed recovery material, compromised signing keys, social engineering, or unauthorized access to a complete signing path.

Loss of authorized access

The legitimate holder cannot recover or operate the wallet.

Possible causes include lost recovery information, forgotten required secrets, destruction, missing components, or excessive complexity.

Incorrect authorization

The holder signs something they did not actually intend.

Possible causes include poor verification, misleading software, malicious substitution, or simple human error.

Loss of continuity

The system works for the original holder but cannot be used by an authorized future person when the original holder is unavailable.

Loss of privacy

Information about ownership, addresses, holdings, purchases, or transaction relationships becomes more exposed than intended.

Privacy loss does not always mean immediate loss of funds.

It can expand the future security and social-engineering surface.

These outcomes are more useful than saying vaguely:

I want my Bitcoin to be secure.

Secure against which failure?

Step 3: Identify realistic threat categories

Once the assets and failure outcomes are clear, identify the threat categories that apply.

You do not need every category to be equally important.

1. Human error

The holder can be part of the threat model.

Examples include:

• recording recovery information incorrectly;
• confusing one wallet with another;
• forgetting an important dependency;
• signing without verifying;
• misplacing a backup;
• misunderstanding a passphrase;
• or making the custody design too complex to maintain.

Human error is not an embarrassing edge case.

It is one of the central self-custody risks.

2. Social engineering and phishing

An attacker may not need to defeat Bitcoin cryptography.

It may be easier to convince the holder to:

• reveal recovery information;
• install fake software;
• approve a malicious transaction;
• or follow an urgent false recovery procedure.

The technical system can work exactly as designed while the user is manipulated into granting authority.

3. Device loss or failure

A phone, computer, or hardware wallet can:

• break;
• disappear;
• become obsolete;
• fail to boot;
• or become unavailable.

The custody question is whether losing that device also removes the only valid access path.

A recoverable system expects individual devices to fail.

4. Recovery-secret exposure

A seed phrase, passphrase, or other sensitive recovery component can be:

• seen;
• copied;
• photographed;
• entered into the wrong software;
• digitized;
• or obtained by another person.

The important distinction is between losing a backup and exposing a backup.

Both are dangerous in different directions.

5. Physical destruction or displacement

A recovery medium or device can be affected by:

• fire;
• water;
• impact;
• deterioration;
• accidental disposal;
• moving;
• or other physical events.

Material survival is not the same as recovery success.

An object can survive physically and still be lost, unreadable, inaccessible, or misunderstood.

6. Software and tool risk

Wallet software, companion applications, operating systems, firmware, and network services can fail or mislead.

The key question is whether the custody model remains understandable when one tool stops working.

7. Common-mode failure

Several protections can look independent while still failing together.

Examples include:

• wallet and recovery backup in the same location;
• several backups affected by one event;
• seed and required passphrase sharing one dependency;
• every recovery component depending on one person;
• or multiple processes relying on one compromised computer.

Common-mode failure is one of the most important things a threat model can reveal.

8. Continuity failure

The holder becomes unavailable and nobody authorized can reconstruct the process.

This can happen even when no device was hacked and no secret was stolen.

A custody system that works only while its designer is present has a human single point of failure.

9. Privacy exposure

Information can reveal more than the holder intended.

This may include:

• transaction relationships;
• public address reuse;
• purchase or shipping metadata;
• disclosure of holdings;
• or unnecessary sharing of custody details.

The correct response depends on the actual privacy threat.

Privacy should not be treated as a reason to add hidden complexity without understanding the new recovery cost.

Step 4: Identify the likely threat actor or failure source

Not every threat is a hacker.

A useful model asks who or what causes the failure.

Possible sources include:

You

Mistakes, memory failure, poor verification, overcomplexity, or incomplete documentation.

Someone with ordinary physical access

A visitor, household member, worker, family member, or other person who can encounter a sensitive object.

This does not mean treating everyone as malicious.

Accidental discovery, disposal, or copying can still matter.

A remote attacker

Phishing, malware, fake software, impersonation, or account compromise.

A custodian or service provider

Operational failure, withdrawal restriction, account compromise, or service dependency.

A thief

Theft of a device, backup, or other component.

The environment

Fire, water, deterioration, relocation, or physical damage.

Future-you

Memory fades.

Labels lose meaning.

Old instructions become stale.

A system that depends on today's context can become difficult to reconstruct years later.

An authorized future user

A family member or other legitimate recovery person may fail because the system is too difficult to interpret.

This is one of the reasons a threat model should include recovery usability, not only attacker resistance.

Step 5: Rank threats instead of treating them equally

A threat model becomes useful when it creates priorities.

One simple way is to think in a matrix.

Threat	Likelihood	Consequence	Priority question
Primary device fails	Plausible	Low to high depending on recovery	Can I recover without it?
Seed phrase exposed	Depends on storage and behavior	Potentially severe	Can unauthorized control result?
One backup destroyed	Plausible in some environments	Depends on redundancy	Is another independent recovery path valid?
Phishing attempt	Common enough to plan for	Potentially severe	Will I recognize a request for sensitive authority?
Required passphrase forgotten	Depends on setup	Potentially severe	Is the dependency preserved and understood?
Highly specialized physical attack	Context-dependent	Potentially severe	Is this realistic enough to justify added complexity?
Family recovery failure	Relevant for long-term holdings	Potentially severe	Can an authorized future person understand the path?

The point is not to calculate perfect probabilities.

You usually cannot.

The point is to force yourself to distinguish:

possible

from:

plausible enough to design around.

Step 6: Choose a control for a defined threat

Once a threat matters, select a control.

A control is anything intended to reduce, remove, shift, or knowingly accept risk.

Bitcoin Plaster's existing threat-model framework uses four useful responses.

Reduce

Make the risk smaller.

For example, improve verification so an authorization mistake becomes less likely.

Remove

Eliminate a risk path where possible.

For example, keeping sensitive recovery material out of normal online workflows removes a major digital-exposure path.

Shift

Move the risk into a different structure.

For example, independent redundancy can shift some risk away from one-location loss, while creating new maintenance and exposure considerations.

Accept intentionally

Some risk will remain.

A simpler custody model may knowingly accept a certain limitation because the alternative adds a greater recovery risk.

The goal is not zero risk.

The goal is risk you understand and chose deliberately.

Step 7: Ask what new failure the control creates

This is where threat modeling becomes much better than security shopping.

Every control has a cost.

A second backup

Can improve recoverability.

Can also create another exposure point.

Geographic separation

Can reduce one-location disaster risk.

Can create access, coordination, or maintenance risk.

A passphrase

Can separate one secret from the final wallet.

Can create a second exact recovery dependency and self-lockout risk.

Multisignature

Can reduce dependence on one key or device.

Can increase setup, metadata, coordination, and recovery complexity.

Strong concealment

Can reduce casual discovery.

Can increase the chance that future-you or an authorized person cannot locate or interpret the recovery path.

Additional software or services

Can improve usability or monitoring.

Can introduce new third-party and software dependencies.

The correct question after adding any control is:

What became safer, and what became easier to lose, forget, expose, or misunderstand?

If you cannot answer both sides, you do not yet understand the control.

The best control may be doing less

Security culture often rewards visible complexity.

More devices.

More secrets.

More locations.

More steps.

More advanced terminology.

But the strongest BPOS custody material repeatedly points toward a different principle:

The strongest material or most sophisticated tool does not compensate for the wrong threat model.

For many holders, ordinary failure can be more relevant than exotic attack.

That means simplicity can itself be a control.

A simpler setup may:

• reduce memory dependencies;
• reduce configuration mistakes;
• make recovery easier to verify;
• reduce stale documentation;
• and make continuity easier.

Simplicity is not automatically safer.

It can become too concentrated or too fragile.

But complexity must justify itself by solving a threat that actually matters.

Threat modeling is not about hiding things from everyone

A threat model should not become a guide to concealment.

“Where can I hide the seed phrase so nobody will ever find it?” is not a complete security question.

Extreme concealment can create:

• accidental disposal;
• forgotten locations;
• failed inheritance;
• poor recovery under stress;
• or dependence on one person's memory.

A safer conceptual question is:

How do I prevent unauthorized access while preserving authorized recovery?

Bitcoin Plaster's seed-storage framework calls this recoverable secrecy.

The wrong person should not be able to use the recovery secret.

The right person should still be able to recover under the conditions the system is designed to survive.

That tension applies to the broader self-custody system too.

The two poles: unauthorized access and self-denial

Many self-custody decisions sit between two failure poles.

Pole 1: Unauthorized access

Security is too weak.

Someone else gains enough information or authority to control the bitcoin.

Pole 2: Self-denial

Security is so restrictive, fragile, or complicated that the legitimate holder cannot recover.

A custody system can fail at either end.

Maximum convenience can create too much exposure.

Maximum secrecy can create an unrecoverable system.

The goal is not to push endlessly toward one pole.

It is to build a system where control remains exclusive enough and recoverable enough.

Threat modeling the signing device

A hardware wallet or other signing device solves a specific part of the problem.

Ask:

What threat am I using the device to reduce?

Perhaps exposure of signing keys to a general-purpose online computer.

What does the device not solve?

It may not solve:

• recovery-secret exposure;
• bad backups;
• phishing;
• mistaken transaction approval;
• family continuity;
• or a compromised recovery process.

What happens if the device disappears?

The custody system should have an answer that does not depend on the device surviving forever.

What information do I trust on the device?

Transaction verification matters because the security value of an isolated signer is reduced if the holder approves details they did not check.

The correct device choice comes after these questions, not before them.

Threat modeling the recovery path

The recovery system has a different job.

Its purpose is continuity after ordinary access fails.

Ask:

Can it survive loss of the primary device?

If not, it is not much of a recovery system.

Can the recovery material itself be exposed?

If yes, what would that exposure allow?

Can the backup be destroyed or displaced?

Physical resilience and findability are separate properties.

Has the data been verified?

A perfectly preserved incorrect backup is still a failed backup.

Does recovery depend on another secret?

If a passphrase or other required element exists, that dependency belongs in the threat model.

Could an authorized future person use it?

If not, the recovery path may contain a continuity failure.

For seed-specific depth, use Seed Phrase Storage Threat Model.

Threat modeling the transaction process

A custody system does not only sit in storage.

It is used.

That creates another threat surface.

Ask:

Where is the transaction created?

Where is it verified?

Which device displays the final details?

What happens if the computer or phone is compromised?

What information am I actually authorizing?

What behavior would make me stop instead of signing?

A strong storage setup can still lose funds through a bad authorization process.

That is why security should cover the entire lifecycle:

store → recover → verify → sign → maintain.

Threat modeling other people

Other people can play several roles.

They may be:

• potential attackers;
• accidental discoverers;
• trusted helpers;
• authorized future recovery users;
• or service providers.

Those roles should not be confused.

A family member who needs to recover in the future does not necessarily need full control today.

A support agent should not need access to the seed phrase.

A trusted person may reduce one continuity risk while creating another dependency.

The threat model should therefore ask:

Who needs to know what, and when?

That is safer than either extreme:

Nobody can know anything.

or:

Everyone trusted gets every secret.

Threat modeling your own behavior

This may be the most important section.

Ask honestly:

• Do I panic when technology behaves unexpectedly?
• Do I click through prompts quickly?
• Am I likely to forget undocumented details?
• Do I travel or move frequently?
• Do I maintain paperwork reliably?
• Do I tend to overcomplicate technical systems?
• Would I recognize a fake support request?
• Am I comfortable performing recovery?
• Would I postpone maintenance for years if everything seems fine?

A threat model that assumes a perfect future version of you is not realistic.

Build for the operator who will actually use the system.

Example threat-model profiles

These are not recommended setups.

They show why different people can rationally prioritize different risks.

Profile A: New holder in a stable home environment

Likely priorities may include:

• understanding recovery;
• avoiding digital seed exposure;
• device loss;
• ordinary phishing;
• transaction verification;
• and keeping the setup simple enough to operate.

An exotic multi-device design may create more recovery risk than it removes.

Profile B: Frequent traveler or person who relocates often

Likely priorities may include:

• device loss;
• moving-related backup loss;
• unstable access to recovery locations;
• privacy exposure;
• and maintaining continuity across changes in environment.

Profile C: Long-term family holder

Likely priorities may include:

• owner unavailability;
• future-user understanding;
• clear recovery context;
• avoiding memory-only dependencies;
• and keeping non-secret instructions current.

Profile D: Publicly known Bitcoin holder

Likely priorities may include:

• privacy;
• social engineering;
• targeted phishing;
• physical-access concerns;
• and reducing single-person or single-device concentration.

The extra controls still have to remain recoverable.

Profile E: Advanced custody user

A person using passphrases, multiple signers, or distributed recovery may need to prioritize:

• configuration correctness;
• reconstruction;
• hidden dependencies;
• stale records;
• component availability;
• and continuity for another authorized person.

Advanced security creates advanced recovery obligations.

Do not copy a high-risk person's security model

A common mistake is copying the custody architecture of someone with a completely different threat environment.

A public Bitcoin executive may have:

• high visibility;
• meaningful targeted risk;
• staff or professional support;
• multiple jurisdictions;
• institutional responsibilities;
• and a much larger operational burden.

A private beginner may not share those conditions.

Copying the same controls can create complexity without buying meaningful protection.

The threat model belongs to the holder and environment, not to the internet personality whose setup looks impressive.

A threat model should include what you deliberately do not defend against

This is a sign of maturity.

You cannot defend equally against every possibility.

A useful model may conclude:

This threat is possible, but I am not adding another control because its likelihood is low and the control would create a more probable recovery failure.

That is not negligence.

That is explicit risk acceptance.

The important thing is that the tradeoff is visible.

Unexamined risk is different from accepted risk.

Revisit the threat model when circumstances change

Threat models become stale.

Review the assumptions when something material changes.

Examples include:

• moving;
• a household change;
• a major change in the financial importance of the wallet;
• adding or removing a backup;
• introducing a passphrase;
• changing wallets;
• changing signing devices;
• migrating the wallet;
• changing storage arrangements;
• suspected unauthorized access;
• losing a backup;
• changing the people involved in recovery;
• or discovering that you can no longer explain the full recovery path.

The model should also survive ordinary time.

A custody system that worked five years ago may still be technically valid while its documentation, devices, locations, or human assumptions have become stale.

A practical threat-model worksheet

Do not put real seed words, private keys, passphrases, exact secret locations, or other sensitive recovery material into a worksheet.

The worksheet is for the model, not the secrets.

Asset

What part of the custody system am I protecting?

Examples:

• signing authority;
• recovery availability;
• transaction integrity;
• continuity;
• privacy.

Threat

What realistic event could damage that asset?

Failure

What happens if the threat succeeds?

• unauthorized control;
• loss of access;
• wrong authorization;
• privacy loss;
• continuity failure.

Likelihood

Is this ordinary, plausible, specialized, or remote in my actual situation?

Consequence

Would the outcome be minor, disruptive, severe, or potentially permanent?

Existing control

What currently reduces the risk?

Control gap

What remains exposed?

New control

What change would reduce the risk?

New dependency

What new failure does that control create?

Recovery test

Can I verify that the system still remains recoverable?

That last line is essential.

A security improvement that destroys recoverability may not be an improvement.

A simple threat-model sequence

If the full framework feels abstract, use this sequence.

1. Name the thing that must survive

Do not start with the product.

Start with control and recovery.

2. Name the three most realistic failures

Not twenty.

Start with the ones that could actually happen in your life.

3. Identify the most severe single point of failure

Which one event could defeat the entire custody system?

4. Choose one proportional control

Address the defined problem.

5. Ask what the control makes worse

Every added defense should get a tradeoff review.

6. Verify the recovery path

The system should still work after the control is added.

7. Stop adding complexity when the remaining risk is acceptable

Security has diminishing returns.

Complexity can become the next threat.

Common threat-model mistakes

Starting with products

A product cannot tell you what your threat model is.

Treating theft as the only risk

Loss, error, exposure, destruction, confusion, and continuity failure can be just as final.

Defending against extreme threats before ordinary ones

A sophisticated attack model does not compensate for an unverified backup.

Assuming more copies always mean more safety

Redundancy improves availability but can increase exposure and maintenance surface.

Assuming fewer copies always mean more safety

Concentration can create one catastrophic failure point.

Adding a passphrase without modeling recovery

A new secret can reduce one exposure risk while creating a self-lockout risk.

Adding multisignature because it sounds advanced

Distribution can reduce single-key concentration while increasing coordination and recovery complexity.

Treating hardware as the whole custody system

The device is one component.

Ignoring future-you

Memory and context degrade.

Ignoring other authorized users

A setup that cannot survive owner unavailability has a continuity weakness.

Never revisiting the model

The environment changes even when the Bitcoin protocol does not.

Common questions

What is a Bitcoin self-custody threat model?

It is a structured way to identify what your custody system must protect, which realistic events could cause failure, how serious those failures would be, and which controls address them without creating larger recovery problems.

Is threat modeling only for advanced users?

No.

Beginners may benefit from it precisely because it prevents unnecessary complexity.

A simple threat model can be as basic as identifying device loss, seed exposure, phishing, recovery failure, and owner unavailability.

Is theft the biggest self-custody threat?

Not automatically.

The dominant threat depends on the holder and environment.

Operational error, exposure, loss, failed recovery, phishing, physical damage, and continuity problems can all be serious.

Should I protect against every possible threat?

No.

A useful model prioritizes realistic, high-consequence risks and accepts some residual risk deliberately.

Attempting to defend against everything can make the system too complex to recover.

Does a hardware wallet solve my threat model?

No.

It can be a control for specific threats, particularly around key exposure during signing.

It does not automatically solve recovery, phishing, backup design, continuity, transaction verification, or every physical risk.

Is multisignature always more secure?

The project source does not support a universal claim that multisignature is always more secure.

It can reduce dependence on a single key or device, but it also increases operational and recovery complexity. Whether that tradeoff is appropriate depends on the threat model.

Should I use a passphrase?

There is no universal answer.

A passphrase can change the exposure model but also creates an additional exact recovery dependency. It should only be used when that tradeoff is understood and justified by a defined threat.

How often should I review my threat model?

Review it when the custody system or life circumstances materially change, and periodically confirm that the recovery path, documentation, components, and assumptions still make sense.

What is the most important threat-model question?

Ask:

Which single realistic event could either give unauthorized control to someone else or prevent every authorized recovery path from working?

That question often reveals the weakest part of the system.

Where this goes next

The four bridge pages now answer four different questions.

Why Self-Custody Matters explains why direct Bitcoin control is useful.

When Self-Custody Is Not Ready Yet explains when direct control may create more risk than it removes.

What Can Go Wrong With Self-Custody maps the main failure modes.

This page turns those failures into a method:

identify the asset → identify realistic threats → define failure → rank risk → choose a control → identify the control's new risk → verify recovery.

From here, product and setup decisions can be made against an actual security problem instead of against fear, status, or feature lists.

For the recovery-secret-specific model, continue with Seed Phrase Storage Threat Model.

For device-specific threat modeling, continue with Hardware Wallet Threat Models.

This page is educational and is not financial or personalized security advice. See what that means.