Explain the security implications of not updating a threat model after an architecture change?

A threat model encodes a set of assumptions about trust boundaries, data flows, and component responsibilities as they existed at a specific point in time. When the real architecture changes - a new external integration is added, a data store moves outside a previously trusted boundary, a monolith splits into two services - and the model isn't regenerated to match, every downstream artifact built on that stale model is silently describing a system that no longer exists.

The risk isn't only that the report is missing threats introduced by the new change, though that's real. It's the false confidence problem: a threat sitting in Mitigated state from the old architecture tells you nothing about whether that same mitigation still holds under the new one, and worse, nobody on the team has any prompt to go check, because as far as the tracked report is concerned nothing changed. A sign-off based on the stale model looks identical to a sign-off based on a current one, which is exactly what makes this failure mode dangerous - it doesn't announce itself.

This is why treating the .tm7 file as a living artifact tied to the architecture's actual change history (see version control practices) matters as much as the initial modeling exercise itself; a threat model that's accurate once and stale forever after provides a diminishing amount of real security value the further the system drifts from what it describes.