Note

A Threat Model Is Not a Fear List: Writing Yours on One Page

A threat model is not a list of things to be afraid of. It is a short written record of what you are protecting, from whom, how bad failure would be, and which costs you accept to prevent it.

2026-10-16 · self-custody, threat-model, security-planning, backups, privacy, sovereign-starter, module-1, civil-liberties

Sovereign Starter · Module 1 of 5 · Threat model

Dark CryptoDecentral hex mesh — a single calm teal hexagon at the centre surrounded by a few bronze rings of varying distance, some cells faintly lit and others dark; no text.

The final checklist in the Sovereign Starter path opens with "Threat model written." Most people skip it. The phrase sounds like something a security team does with whiteboards, or it turns into a list of every frightening attack anyone has ever described.

Thesis, stated once: a threat model is not a list of things to be afraid of. It is a short written record of what you are protecting, from whom, how bad failure would be, and which costs you accept to prevent it. One page is enough. Its real job is to tell you what you can safely ignore.

The five questions

The Electronic Frontier Foundation's Surveillance Self-Defense guide frames a security plan around five questions. They work for keys, coins, notes and identities as well as they work for phones:

What do I want to protect?
Who do I want to protect it from?
How bad are the consequences if I fail?
How likely is it that I will need to protect it?
How much trouble am I willing to go through to try to prevent potential consequences?

Answer each in a few lines and you have a threat model. Everything else in this note is about answering them concretely for sovereign tools.

1. Assets: name the secrets, not the apps

"My wallet" is not an asset. Write down the things that, if copied or lost, change what someone can do:

Spending secrets. A BIP 39 mnemonic and any passphrase, a Monero 25-word seed, a Nostr nsec.
Wallet definitions. Which scripts and derivation paths your funds use. Our descriptors note explains why a seed alone may not be enough to find them.
Metadata. Labels, transaction history, contacts, relay lists. Bitcoin Core's wallet guide is blunt about this: "Metadata cannot be retrieved from a blockchain rescan."
Linkability. The connection between your network address, your on-chain activity and your public identity.

Each item deserves its own line, because each fails differently. A leaked seed is a theft problem. A lost seed is a recovery problem. A leaked IP address is a privacy problem.

2. Adversaries: be specific and boring

Most real losses are not elaborate. Useful adversary entries look like:

You, later. Forgotten passphrases, unreadable handwriting, a backup you never tested. The Bitcoin Core guide warns that wallet encryption "significantly increases the risk of losing coins due to forgotten passphrases. There is no way to recover a passphrase."
Opportunists. Malware on a daily-use laptop, a phishing page, a fake app update. This is why our verify-before-trust note comes first in the path.
People near you. Housemates, family, anyone with physical access to a drawer or an unlocked phone.
Service operators. A remote node, an indexing server or a relay sees your queries. Monero's own anonymity-network docs note that a node run only to broadcast and then quit "can also be used by an ISP to link a user to a transaction."
Network observers and legal pressure. These vary sharply by country, which is exactly why a global audience cannot share one template.

Leave off adversaries you can't name a reason for. A model that defends against everyone defends against no one in particular.

3 and 4. Impact and likelihood: rank, don't score

You don't need numbers. Put each asset–adversary pair into one of three rows: would ruin me, would hurt, annoying. Then mark each as plausible this year or unlikely.

The top-left cell (would ruin me, plausible) is where your effort goes. For most beginners that cell contains two entries, and neither is a nation-state:

losing access to your own keys, and
a common piece of malware or a phishing prompt on a hot device.

Notice that these two pull in opposite directions. More copies of a seed protect against loss and increase exposure to theft. Encryption protects against theft and adds a forgettable secret. A threat model doesn't make that tension go away. It makes you choose deliberately.

5. Costs: write down what you won't do

The fifth question is the one people skip, and it is the most honest. If you will never carry a second device, or never run your own node, write that down. Then design around it, rather than pretending you'll follow a regime you'll abandon in a month.

Accepted costs are also where trade-offs become explicit:

"I use a remote node; I accept that its operator can see my wallet's network address."
"I keep one metal backup in one place; I accept a fire risk in exchange for fewer copies."
"My Nostr key lives in a separate signer, so I accept an extra approval tap." NIP-46 states the principle behind that last line: "Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface."

A one-page template

Plain text works. Paper is fine.

WHAT: (each secret, definition, metadata, link)
WHO: (you-later, opportunists, people nearby, operators, observers)
TOP CELL: (would ruin me + plausible this year)
CONTROLS: (one or two per top-cell entry)
ACCEPTED: (costs I won't pay, and the risk I accept instead)
RECOVERY: (if this device vanished tonight, what I'd do first)
REVIEW: (date — and after any move, new device, or big life change)

The recovery line is the test. If you can't write it, the next note in this module, on seed backup and recovery basics, is where to go. The review line matters because threat models expire. A new job, a new country or a new household changes the adversary column overnight.

Why this fits a global audience

The same tools are used by a student whose phone gets checked at a border, by a small organisation on shared hardware, and by someone whose main risk is a flooded flat. A single "best setup" can't serve all of them. A shared method can. That is the civil-liberties case for writing the page yourself: it puts your own circumstances, not someone else's defaults, at the centre of every later choice in the path.

What this is not

This is not a hardening checklist, a product recommendation or a ranking of wallets, signers or devices. It is not legal guidance for any jurisdiction, and it doesn't teach evasion of lawful process. It contains no custody advice, prices or trading content. And it isn't permanent: a threat model is a dated draft that you are expected to rewrite.

The practical takeaway fits on one line: if your page names your secrets, your realistic adversaries, the one or two outcomes that would truly hurt, and the costs you accept, it is a threat model, however short it is.