Threat modeling is the practice of identifying who might want to read, alter, or block your messages, what capabilities they have, and which of those outcomes you actually need to prevent. It sits between cryptographic protocol analysis and operational security, and it is the only honest way to decide whether a given messenger, key-verification ritual, or backup strategy is worth your time. On this site, we usually examine specific implementations: how a protocol handles group key ratcheting, what a forensic extraction tool can recover from a seized device, or where a metadata leak undermines an otherwise sound design. But those findings only become useful when they are placed inside a personal threat model. Without one, you are either securing against a cartoon villain or ignoring a real adversary.
This article is not a checklist of “best apps.” It is a method for reasoning about personal communication under realistic constraints. We will define the components of a threat model, walk through three concrete profiles, and then show how the same technical fact—say, that a messenger stores plaintext backups in cloud storage—can be a non-issue for one person and a catastrophic design flaw for another. The goal is to make you harder to surprise, not harder to reach.
What a Threat Model Actually Contains
A useful personal threat model has four parts: assets, adversaries, capabilities, and consequences. You can write these on a napkin. The formality matters less than the honesty.
Assets: What Are You Protecting?
For most people, the asset is not “the message.” It is the content of the message, the metadata about who talked to whom and when, or the availability of the channel itself. A journalist protecting a source may care far more about metadata than about the text of a single exchange. A dissident coordinating a protest may care most about availability: if the network is blocked, the content does not matter. A person going through a divorce may care about content confidentiality from a specific individual who once had legitimate access to a shared device.
Naming the asset changes the technical evaluation. If your asset is metadata, then a messenger with perfect end-to-end encryption but centralized contact discovery is still a problem. If your asset is availability, then a messenger that depends on a single cloud provider is a risk even if its encryption is flawless.
Adversaries: Who Are You Modeling?
An adversary is not a vague “hacker.” It is a specific actor with a specific motive. Common categories for personal communication include:
- Intimate adversary: a former partner, family member, or roommate with physical or credential access to your devices.
- Criminal opportunist: someone who steals a phone or laptop and wants to extract sellable data.
- Employer or school administrator: an entity with lawful access to managed devices or network traffic.
- Law enforcement or intelligence agency: an entity with subpoena power, forensic tooling, and sometimes lawful interception capabilities.
- Platform provider: the company that operates the messaging service and can change its terms, push a malicious update, or be compelled by a government.
Each adversary has a different capability set. An intimate adversary may be able to guess your passcode or use a previously enrolled fingerprint. A platform provider can silently modify the client you download. A well-resourced intelligence agency may be able to exploit zero-day vulnerabilities in your operating system. The same messenger can be excellent against one adversary and useless against another.
Consequences: What Happens If You Fail?
Consequence is the part people skip. If an adversary reads your grocery list, the impact is near zero. If an adversary reads a message that reveals a confidential source, the impact may be imprisonment or death. The consequence determines how much friction you should accept. A person with low consequences can tolerate a messenger that stores plaintext backups in the cloud. A person with high consequences cannot, even if the messenger is otherwise well designed.
Three Worked Examples
Abstract definitions are easy to nod along to. Let us apply them to three profiles that differ in assets, adversaries, and consequences.
Profile 1: The Privacy-Conscious Office Worker
Assets: personal conversations with friends and family; occasional health or financial information.
Adversaries: criminal opportunists, data brokers, and the platform provider’s advertising partners.
Capabilities: the opportunist can steal a device; the data broker can purchase metadata from third parties; the platform provider can read anything it stores in plaintext.
Consequences: embarrassment, targeted scams, or financial fraud. Not life-threatening.
For this person, a mainstream end-to-end encrypted messenger with default settings is a reasonable choice. The main risks are device theft and cloud backup leakage. The practical mitigations are a strong device passcode, enabling remote wipe, and disabling cloud backups of message history if the messenger offers that option. The office worker does not need to run a custom ROM or use a dedicated hardware key. The threat model does not justify that friction.
Profile 2: The Journalist Working with a Confidential Source
Assets: the identity of the source, the content of their communications, and the metadata linking the journalist to the source.
Adversaries: a government agency with subpoena power, forensic extraction tools, and possibly lawful interception; a platform provider that can be compelled to hand over metadata.
Capabilities: the agency can seize devices, serve legal process on the messenger provider, and analyze traffic patterns. It may also have access to commercial forensic tools that can bypass some device locks.
Consequences: source exposure, legal jeopardy, physical harm to the source.
Here the evaluation changes sharply. The journalist should care about metadata minimization, not just content encryption. A messenger that logs who contacted whom, when, and from which IP address is a liability even if the message bodies are encrypted. The journalist should also consider device seizure: if the phone is taken, what can be recovered? A messenger that stores a local plaintext database is a problem. A messenger with disappearing messages and no cloud backup is better. The journalist may also need to use a VPN or Tor to reduce network-level metadata, and should verify safety numbers out-of-band to detect a man-in-the-middle attack.
This profile also illustrates a common mistake: assuming that “end-to-end encrypted” means “safe from governments.” It does not. End-to-end encryption protects content from the platform provider and from network eavesdroppers. It does not protect metadata, and it does not protect against a compromised endpoint. A government that can seize the phone or compel the provider to hand over metadata has already defeated the encryption in practice.
Profile 3: The Person Fleeing an Abusive Partner
Assets: current location, plans to leave, communications with shelters or lawyers.
Adversaries: an intimate partner with prior physical access to devices and accounts.
Capabilities: the partner may know passcodes, have a fingerprint enrolled, or have installed a monitoring app. They may also have access to shared cloud accounts or family plans.
Consequences: stalking, physical violence, or death.
This is the hardest profile because the adversary is not remote. The technical threat is not a cryptographic flaw; it is account takeover and device compromise. The person should assume that any device the partner has touched is compromised. The first step is not choosing a messenger; it is getting a new device and new accounts that the partner has never accessed. Then the person should enable two-factor authentication on every account, use a password manager with a new master password, and disable any location-sharing features. A messenger with disappearing messages can help, but only after the device and account hygiene is fixed.
This profile also shows why “just use Signal” is not a complete answer. Signal is a well-designed messenger, but if the abusive partner has the victim’s phone passcode and can unlock the device, Signal’s encryption does not matter. The threat model must address the endpoint first.
How to Evaluate a Messenger Against Your Model
Once you have a written threat model, you can evaluate any messenger by asking a short set of questions. These questions are not about marketing claims; they are about observable behavior and verifiable design choices.
1. What Does the Provider Store?
Ask what the provider can see. Does it store message content in plaintext? Does it store metadata such as contact lists, IP addresses, or timestamps? Does it offer a transparency report that describes what it has handed over to law enforcement? A provider that publishes a canary or a warrant canary is not proof of safety, but it is a signal that the provider is thinking about compelled disclosure.
2. What Happens When a Device Is Seized?
Ask what a forensic examiner can recover from a locked or unlocked device. Does the messenger store a local plaintext database? Does it encrypt its local storage with a key derived from the device passcode? Does it offer disappearing messages that actually delete from storage, or do they just hide from the UI? These are testable claims. A forensic extraction report from a tool like Cellebrite or GrayKey can show what is recoverable from a given device and app version.
3. How Are Keys Managed?
Ask how the messenger handles key verification. Does it use a key transparency system that lets you detect a swapped key? Does it require out-of-band verification for new devices? Does it allow silent key changes? A messenger that notifies you when a contact’s key changes is better than one that silently accepts the change, but the notification is only useful if you understand what it means and act on it.
4. What Is the Backup Story?
Ask where backups live. Are they end-to-end encrypted? Are they stored in a cloud account that is protected only by a password? Can a subpoena compel the cloud provider to hand them over? A messenger that offers encrypted backups with a user-held key is different from one that silently syncs plaintext to iCloud or Google Drive. The backup story is often the weakest link in an otherwise sound design.
Common Failure Modes in Personal Threat Modeling
Even people who understand the theory make predictable mistakes. Here are the ones I see most often in audits and post-incident reviews.
Modeling the Wrong Adversary
The most common failure is securing against a remote hacker while ignoring the person with physical access. A strong passcode and full-disk encryption do more for most people than any exotic protocol choice. If your threat model includes an intimate adversary, start with device hygiene, not with a new messenger.
Ignoring Metadata
People focus on message content because it is visible. But metadata—who you talk to, when, how often, and from where—is often more revealing and easier for a provider or network observer to collect. If your adversary is a government or a platform provider, metadata is the primary asset you need to protect.
Treating Encryption as a Binary
Encryption is not a switch. It is a set of design choices about key management, forward secrecy, backup handling, and endpoint security. A messenger can have end-to-end encryption and still leak plaintext through a backup system or a compromised endpoint. The question is not “is it encrypted?” but “what exactly is encrypted, under what conditions, and what are the failure modes?”
Overestimating Your Own Discipline
People choose a high-security setup and then fail to maintain it. They forget to verify safety numbers, they leave disappearing messages off, they reuse a passcode. A threat model should include an honest assessment of your own operational consistency. A simpler system that you actually use is often better than a complex one that you abandon after a week.
Building a Personal Threat Model in Practice
Here is a concrete exercise. Take a single conversation you had in the past week that you would not want public. Write down:
- What exactly would be harmful if it were revealed?
- Who would be most likely to try to reveal it?
- What capabilities does that person or entity have?
- What would the practical impact be?
Then look at the messenger you used. Does its design protect against the adversary you named? If not, what is the cheapest change that would close the gap? The answer might be “use disappearing messages,” “turn off cloud backup,” “get a new device,” or “use a different messenger for this specific conversation.” It is rarely “install a custom ROM and carry a hardware key.”
This exercise also reveals a truth that marketing pages hide: security is a spectrum of trade-offs. Every feature you add—cloud sync, multi-device support, contact discovery—creates a new attack surface. The question is not whether a messenger is “secure” in the abstract. The question is whether its trade-offs match your model.
What This Means for Protocol Audits
On this site, we often publish technical deep-dives into specific protocols and implementations. Those audits are most useful when you can map their findings onto your own threat model. A flaw in group key ratcheting matters if you use group chats for sensitive coordination. A forensic extraction vulnerability matters if your adversary can seize your device. A metadata leak matters if your adversary is a network observer or a compelled provider.
When you read an audit, do not ask “is this app bad?” Ask “does this flaw affect my assets, under my adversary’s capabilities, with consequences I care about?” That is the difference between security theater and security practice.
FAQ
What is the difference between a threat model and a risk assessment?
A threat model identifies specific adversaries and their capabilities. A risk assessment adds likelihood and impact to prioritize mitigations. In personal communication, the two are often combined: you name the adversary, estimate how likely they are to act, and weigh the consequence. The threat model is the qualitative foundation; the risk assessment is the quantitative overlay.
Do I need a different threat model for every conversation?
No. Most people have one or two dominant threat models that cover the majority of their communication. You might have a “default” model for everyday conversations and a “high-sensitivity” model for a specific relationship or topic. The key is to know which model applies before you send a message, not to build a new model for every chat.
Can a messenger be secure for one person and insecure for another?
Yes. Security is a property of the system plus the threat model, not of the messenger alone. A messenger that stores plaintext backups in the cloud may be fine for someone whose adversary is a random phone thief, but unacceptable for someone whose adversary is a government with subpoena power. The same technical fact has different implications depending on the adversary’s capabilities and the consequences of failure.
How often should I revisit my threat model?
Revisit it when your life changes: a new job, a new relationship, a legal dispute, a move to a different country, a change in political activity. Also revisit it when the messenger changes: a new backup feature, a change in ownership, a new data-sharing policy. A threat model is a living document, not a one-time exercise.
Next Steps for This Site
This article is the first in a recurring column on practical threat modeling. Future pieces will apply the method to specific scenarios: evaluating a messenger’s backup architecture, reading a forensic extraction report, and auditing a group chat protocol for metadata leaks. If you have a scenario you would like to see modeled, send it in. The best threat models are built from real cases, not hypotheticals.