How do you stop a threat model's recorded assumptions from silently going stale as the system changes?

## Why models rot without anyone editing them A threat model is accurate on the day it is signed off. What degrades it afterwards is rarely a change to the diagram — it is a change to something the diagram never showed. Assumptions decay in two directions, and a lead needs a mechanism for each. **A dependency changes underneath you.** A service's model records: *the edge gateway terminates mTLS, so the service can trust the caller identity header.* Two quarters later the gateway is upgraded and that termination behaves differently or is dropped. Nothing in the service changed; nobody re-opened its model; and an authenticated low-privilege tenant can now forge the caller identity header and act as another tenant. The threat that the model explicitly excluded is live again. Or: *the event bus is only reachable from inside the VPC.* A routine networking change adds a public listener. The asset at risk is availability and the integrity of every downstream consumer, and the attacker position has just widened from internal to anonymous internet — without a single line of the service's own design moving. **Your own design changes.** A customer-support console whose agents can read any account is moved from VPN-only access to public single sign-on. The components and data flows on the diagram are almost identical, so a redraw finds nothing. What has been deleted is the unwritten assumption *the network restricts who can reach this*, and with it the reason the model never took credential stuffing or agent account takeover seriously. Two attacker positions arrive at once: an anonymous credential-stuffer, and the support agent themselves now reachable from anywhere. ## The mechanism: review the list, not the picture The central move is to make the **assumptions register**, not the diagram, the artifact under review. Diagrams change visibly and attract attention. Assumptions fail silently, which is exactly why they need a process. **Give every assumption a trigger expressed as an event.** "Recheck on any change to gateway TLS configuration." "Recheck on any change to network exposure of the bus." "Recheck on any change to the authentication model of this console." An assumption whose recheck condition is "when we next think about it" has none. **Put an expiry on anything you cannot test.** Where the claim rests on another team's behaviour and there is no way to observe it continuously, date it. Six or twelve months, then it must be re-confirmed or downgraded to unverified. Undated assumptions accumulate for years. **Put the question into design review.** The cheapest control here is one line on the change checklist: *does this change invalidate a recorded assumption in any model?* It costs a change author thirty seconds and it catches the VPN-to-SSO class of failure, which is the one nobody notices because it looks like a routing change. **Register as a consumer with the owner.** If your model depends on a platform control, ask the owning team to record who relies on it, so their change process can surface the dependents. This is the only mechanism that reliably catches the gateway-upgrade case, because that change starts in a team that has never read your model. **Prefer assumptions that can be continuously verified.** Where you have a choice between an assumption someone asserts and one that a routine check can observe, take the observable one — not because the check belongs to threat modelling, but because an assumption that can only be asserted is one you will be re-confirming by email forever. ## Triage: you cannot revalidate everything A mature register has more entries than any team will re-examine. Rank by **what the assumption suppresses**, not by how likely it feels: an assumption whose failure reopens cross-tenant authorization or ledger integrity is worth an annual verification; one that suppresses a low-impact threat on an internal tool is worth an expiry date and nothing more. This is the field that pays for itself — if each assumption records what re-enters the model when it is false, the triage is already written. ## When a model is re-opened, walk the list first Practically: when a design change lands and you have limited time, read the assumptions before re-walking the data flows. It is faster, and it is where the yield is, because the change author has usually already thought about the components they touched and has not thought at all about a claim written by someone else a year ago. ## The cultural failure to name A register that no one ever disputes is a register no one reads. If the assumptions list has been through three reviews and never once had an entry challenged by the team that owns it, the process is decorative. Part of the lead's job is to route each assumption to its owner and treat a rejection as a success — a rejected assumption is a threat found for free, which is the entire economics of doing this at design time. ## What is being tested at this level Not that you know assumptions can go stale — everyone says that. That you have a concrete regime: triggers as events, expiry dates, a design-review hook, consumer registration with control owners, and a triage rule that says which assumptions are worth the cost of revalidation.