Talking about the security–usability balance without a threat model is empty
Aliases: threat modeling · attacker model · threat model
What it is
"Security must be balanced against usability" is an empty sentence without a threat model: without knowing who the attacker is, what attack is in scope, and what capability and motive they carry, there is no way to judge what a unit of friction buys. The threat model — an explicit statement of defended-against-whom, defended-against-what, and what a breach costs — is the coordinate system of the tradeoff; without it, the argument between "more secure" and "more usable" has no referee.
Why it happens
The structure of the balance problem is asymmetric: friction is immediate, certain, and lands on the user; security benefit is delayed, probabilistic, and hard to observe. Judging whether the friction is worth it needs three numbers — which attack's success rate drops, how probable that attack is, and what success costs the defender — and all three come from the threat model. The same mechanism reaches opposite conclusions under different models: auto-locking the screen is necessary friction against the "office colleague glances" model and irrelevant to the "remote network attacker" model; disabling it dismantles a line in the first model and is a usability optimization in the second. Most security debates spin precisely because the parties carry private, implicit threat models. Once the model is written down, most "balance" questions collapse into "is it worth it under this model" — computable, and stable: change the model and the answer changes; keep the model and the answer should not drift.
Where it stops holding
A threat model is never final: the attack surface evolves with the product, and the model must be re-reviewed — what nobody defended against yesterday (AI voice cloning) is a live attack path today. Models can simply be wrong — attacker capability underestimated, insiders omitted — and "the model was wrong" is usually confirmed only in hindsight after an incident, so key decisions should archive their model assumptions for post-mortems. And for consumer products facing an unnumerable attacker population, no clean model can be written; the working approximation is attack cost-effectiveness: attackers pick the cheapest path, so friction belongs on the cheapest path.
Applying it
- Every security decision document carries four fixed lines: defended against whom, against what attack, at what loss, and why this friction is worth it; a decision whose fourth line cannot be written is paused.
- Make "threat model update" a standing agenda item in product review: before any new feature ships, ask which attack path's cost it changed.
- In incident post-mortems, compare against the decision document's model assumptions: which line failed and why it was believed — the output revises the threat-model template directly.
- Verification: sample quarterly security decisions and check that the four lines are present and that attack paths still match the current product shape — a stale model is more common than a missing one.