Threat Model

A threat model is a deliberate, written assessment of the risks you actually face, used to decide where to spend limited time and money on security. The Electronic Frontier Foundation frames it as thinking about who might want to compromise you and what they want from you. The concept originated in software security — Microsoft formalized the STRIDE methodology in the late 1990s — but it applies just as well to personal privacy, self-custody, and running sovereign infrastructure from home.

The core questions

A useful threat model answers a handful of plain questions. What am I protecting (assets: keys, coins, identity, location, uptime)? Who might want it (adversaries: opportunistic thieves, targeted criminals, data-hungry corporations, overreaching institutions)? How likely and how capable is each of them? What happens if they succeed (consequences: from spam to total loss)? And how much inconvenience am I willing to accept to prevent it? Crucially, there is no defense against every theoretical threat, so the exercise is about prioritization — taking seriously the threats that are plausible for you and consciously declining to chase the ones that are not. A written model also exposes contradictions: encrypting your disks while your seed phrase sits in a desk drawer, or running a node over Tor while posting your stack size on social media.

Why it comes first

Without a threat model, security spending becomes cargo-cult ritual: people adopt tools that do not address their real risks while ignoring the ones that do. A casual holder defending against remote hackers needs different measures than a public figure who must also plan for physical coercion; a home miner worried about a nosy landlord faces different exposure than an operation drawing megawatts. Naming your adversary turns vague anxiety into concrete engineering decisions — whether your node needs an onion address, whether multisig with geographic separation is warranted against a wrench attack, whether an amnesic system like Tails OS belongs in your toolkit, or whether a passphrase and a fireproof plate already cover your realistic risks.

A worked example

Consider a home miner and node runner. Assets: seed phrases, a hot wallet for payouts, the privacy of the home address, the miners themselves. Plausible adversaries: burglars (opportunistic, low capability), scammers and SIM-swappers (remote, medium capability), data brokers correlating purchases with addresses (passive, persistent). Less plausible: targeted physical coercion, unless holdings become public. The resulting plan writes itself: keys in cold storage with a duplicate off-site, no holdings talk anywhere, deliveries handled discreetly, node reachable over Tor, and compartmentalization between the online persona and the household. Nothing exotic — just measures matched to threats.

Once written, pressure-test it. A tabletop exercise costs an evening: walk each adversary through their attack step by step and see where your plan actually stops them — burglar finds the hardware wallet, then what? SIM-swapper owns your phone number for 48 hours, what falls? If the walkthrough finds a single point of failure, you have learned something a product page never tells you. Testing also exposes the recovery half of security that planning tends to skip: knowing your backups exist is not the same as having restored from one. The habit mirrors good bench practice — you do not trust a repair because the board looks right, you trust it because you watched it hash under load.

Keep it living

A threat model is not a one-time ceremony. Holdings grow, a hobby becomes a business, a pseudonym gets linked, a new attack pattern emerges — each shifts the calculus, so revisit the document when circumstances change. Build the model first, then let it drive your day-to-day OPSEC and tool choices rather than the other way around. Security bought without a threat model is decoration; security derived from one is engineering.