Preview draft. Copy and visuals are pending review and may change before launch.

Practice

Threat modeling for authorization systems

An authorization system defends against something. Naming that something explicitly changes what gets built, and what gets left out.

← Back to the library

Governance, Incident Response, and Resilience · Published 2026-09-05

Naming the adversary before designing the defense

A threat model states, explicitly, who might attack a system, what access or capability they're assumed to already have, and what they'd stand to gain. Skipping this step doesn't mean a system has no threat model — it means the threat model is implicit, unstated, and usually just whatever the team building the defenses happened to imagine, which may or may not match reality.

For authorization specifically, a useful threat model has to include the insider case explicitly: a legitimate identity, correctly authenticated, acting outside its intended scope — through compromise, coercion, or plain carelessness. Defenses built only against external attackers leave this case largely unaddressed.

Threat models go stale

A system's actual threat landscape shifts as the system changes: a new integration point, a new category of automated caller, a new class of user with access nobody originally planned for. A threat model written once at launch and never revisited drifts out of date exactly as the system grows more complex — which is also when an accurate one matters most.