01. Begin with the asset
An asset is something worth protecting: account access, private communications, location information, identity, or the availability of a service. Be specific about the potential harm if that asset is exposed.
02. Identify the adversary and capability
A threat model asks who might cause harm and what capabilities they realistically have. A local network operator, a commercial tracker, a targeted attacker, and a compromised device present different problems and require different safeguards.
03. Map attack surfaces
Consider devices, browsers, accounts, recovery channels, networks, third-party services, backups, and people who may receive shared information. Weaknesses often occur at the boundaries between these systems.
04. Choose controls proportionately
Controls can include software updates, strong unique passwords, multi-factor authentication, encryption, minimizing data collection, and safer account recovery. No single tool addresses every threat.
05. Review assumptions
Threat models change when devices, relationships, travel patterns, software, or adversary capabilities change. Revisit the model periodically and after significant incidents.
06. Build a threat model in five steps
- Identify assets. Decide what needs protection: identity, location, contacts, browsing history, files, or access to an account.
- Name adversaries. Consider a commercial tracker, a malicious website, a local network operator, a data broker, a targeted attacker, or a state-level observer. Avoid treating all adversaries as equally capable.
- Map exposure. List devices, accounts, networks, people, backups, browser sessions, and third-party services that touch the asset.
- Estimate likelihood and impact. A low-probability event can still matter if its consequences are severe. State assumptions instead of inventing numeric risk scores.
- Choose controls and review. Prefer controls that reduce multiple risks without creating excessive complexity. Revisit the model when devices, adversaries, or circumstances change.
07. Example: protecting research activity
A person researching a sensitive topic may want to limit routine profiling, prevent account linkage, and keep downloaded documents from revealing identity. Tor Browser can reduce some network and browser-level exposure; a separate non-identifying workflow may reduce account linkage; device updates and cautious file handling address endpoint risks. None of these controls protects against every adversary, and a personal login can still associate activity with an account.
08. Prioritize controls by layer
| Layer | Useful controls | Residual limitation |
|---|---|---|
| Device | Updates, screen lock, malware hygiene | Compromise can expose activity directly |
| Browser | Supported browser, conservative settings | Accounts and behavior can identify users |
| Network | Tor or a trusted VPN where appropriate | Traffic patterns and endpoints remain relevant |
| Accounts | Unique credentials, MFA, minimal profile data | Service providers still know account activity |
Primary reading: EFF: Tor and HTTPS and CISA: Secure Our World. Last substantive review: 11 November 2026.