Threat Modeling

Threat modeling is the disciplined practice of asking, before you build or deploy a system, "What am I protecting, who would come after it, how would they get in, and what happens if they succeed?" Rather than reacting to breaches after the fact, you enumerate your assets, map how data and trust flow between components, identify the boundaries an attacker could cross, and rank the resulting risks — so that scarce time, money, and attention go to the threats that actually matter. For a sovereign Bitcoiner, the assets are usually a seed phrase, the devices that sign with it, the nodes and miners that earn and verify, and the privacy graph linking your identity to your coins.

The four questions

Every practical threat model, however informal, answers four questions. What are you protecting? Keys, coins, hardware, uptime, and — easy to forget — information about you, since a leaked balance is itself an attack enabler. Who are you protecting it from? Adversaries differ wildly in capability and motivation: a remote scammer phishing at scale, a burglar who finds a signer in a drawer, a coercive person who knows what you hold, a data-hungry corporation, a state-level observer. A defense that stops one may be irrelevant to another. How would they reach each asset? This is where you trace paths: the seed is threatened by cameras and house guests, the hot wallet by malware, the exchange account by SIM swaps. What is worth doing about it? Every mitigation costs friction, and friction you will not sustain is not a mitigation — it is a plan to fail later.

Frameworks that help

The widely used STRIDE framework, created at Microsoft by Loren Kohnfelder and Praerit Garg, sorts threats into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — a memory aid for "what can go wrong" at each trust boundary. You do not need enterprise tooling to use it: walking your Bitcoin stack through those six words surfaces most of the obvious holes. Pair the threat list with a simple ranking — how likely, how bad — and accept explicitly that some risks are not worth defending against. A written page beats a perfect methodology you never apply.

Why it matters for self-custody

Most self-custody failures are not exotic cryptographic breaks; they are unmodeled mundane risks: a photographed seed backup, a phishing site one character off from the real one, malware on the computer that builds transactions, a supply-chain-tampered device, or an heir who cannot find or use what you left behind. Naming threats explicitly turns vague anxiety into a checklist you can defend, and — just as valuable — it stops over-defending against glamorous, unlikely attacks while the boring ones go unaddressed. It is the threat model that tells you whether you need a hardware wallet at all, whether multisig across locations beats a single signer, whether a passphrase helps or just adds a way to lose funds, and how much cold storage ceremony your actual adversaries justify. A miner in the garage adds its own lines: firmware provenance, pool account takeover, and the fact that a power bill quietly advertises that you mine.

A living document

A threat model is never finished. Revisit it when your stack changes, when your stack size changes — defenses appropriate for pocket money are negligent for savings — and when your adversary landscape shifts. Threat modeling pairs naturally with attack surface reduction, which shrinks the paths attackers can take, and a layered defense in depth posture, since the model is what tells you which layers are worth building and which are theatre. Security is not a product you buy once; it is this loop, run honestly, for as long as you hold anything worth taking.