Most threat models are made once — a whiteboard photographed, pasted into a doc, never opened again. Six months later the architecture has moved and the model describes a system that no longer exists.

A durable threat model is built differently. It assumes it will be wrong soon, and it makes being wrong cheap to notice.

Write the assumptions, not just the threats

The threats are the obvious part. The assumptions are what fail. "This service is only reachable from inside the VPC." "This token always expires in an hour." "Only the billing team can write to this table." Each one is true until a config change makes it quietly false.

So I write the assumptions as their own list, in plain language, next to the diagram. Then I ask one question of each: what would have to change for this to stop being true, and would we notice?

Tie it to something that moves

A model in a doc nobody reads is dead. A model expressed as tests, as policy, as a checklist in the PR template — that's a model that gets checked on every change. The goal is a tripwire: when an assumption breaks, something turns red.

The durability test

Before I call a threat model done, I ask:

Could a new engineer read this and understand what we were afraid of?
If assumption #3 silently broke next quarter, what fails loud?
What in here is already a lie?

If I can't answer all three, I haven't modeled the system. I've drawn a picture of it on a good day.

AnthonyHerman

Anthony
Herman