A mitigation ships for a modeled threat — what do you re-rate, and how does the fix queue change?

## Ratings are perishable A threat model's ratings describe a design at a moment. Every shipped mitigation, every new entry point, every changed assumption ages them. The most common decay is the happy one: a control ships, and the list still shows the pre-control ratings, so the queue keeps pointing at work that has already been partly done — while the threats the control created are not on the list at all. ## What actually moves when a control ships Split a rating into its two halves. Roughly: **how likely / how reachable** the threat is, and **how bad it is if it still occurs**. Most preventive controls move the first and leave the second alone. Consider step-up authentication on the grade-change action in a school district's student-records system. The threats it touches: - A staff insider changing a grade from a colleague's unlocked session — tampering. Reachability drops sharply; the damage to the record if it still happens is unchanged. - The same actor later denying they made the change — repudiation. A second factor tied to a person strengthens the evidence, so both the likelihood of a successful denial and the weakness of the audit trail improve. - A low-privilege staff account reaching the grade-write path — elevation of privilege. The extra check narrows the path but does not remove the over-broad grant underneath it, so this one drops less than the other two, and the underlying authorization threat stays on the list. Some controls *do* cut impact rather than likelihood — segmentation, tokenization and field-level encryption all reduce what an attacker gets rather than whether they get in. The discipline is to say which half you moved and why, not to wave the whole row down a band because "we did something". ## Re-rate the cluster, not the row A control rarely touches exactly one row. It changes the reachability of a shared path, and every threat that traverses that path shifts with it. So the re-rating unit is the cluster of threats sharing the path or the root cause, not the single ticket that prompted the work. This is also the honest check on whether the fix delivered what was claimed: if only one of the four rows moves, the change was narrower than the design said. ## New threats the control introduces This is the half candidates forget, and it is the interesting half. Every control has its own threat surface: - **Denial of the legitimate user.** Step-up authentication at the report-card deadline means a teacher without their second factor cannot enter grades on the day it matters. That is an availability threat against a time-critical workflow, and it is not hypothetical — it is the most likely thing to actually happen. - **A new dependency.** The second-factor provider becomes part of the trust boundary. Its outage is your outage; its compromise is a bypass of the control you just built. - **A new bypass path.** An enrolment or recovery flow exists so people who lose the factor can get back in, and that flow is now the cheapest route to the thing the control protects. A control almost always creates a lower-friction back door somewhere, and modeling it is part of shipping the control. These new rows are rated on the same scale and take their place in the same queue. It is entirely normal for a mitigation to lower three rows a band and add one row near the top. ## Keeping the re-rating comparable Re-rating with a fresh bar is the same defect as rating a model piecemeal: the moved rows are no longer comparable with the untouched ones. So re-rate against the original session's anchor examples. If the anchors themselves no longer make sense — the system has changed too much — that is a signal to re-rate the whole model rather than to patch a few rows. Keep the history. Record the previous band, the new band, and the specific control and reason for the change. That record is what lets you answer, months later, why a threat that was High is now Medium, and it is the first thing anyone auditing the model asks. Deleting the old row loses the reasoning and makes a lowered rating look like a rating that was always low. ## When to trigger a re-rate Not continuously. The sensible triggers are: a mitigation from this model shipped; a new entry point or trust boundary appeared in the design; an assumption the ratings rested on turned out to be false; or a threat you rated as low-reachability was observed being attempted. Each of those invalidates specific rows, and re-rating those rows plus their cluster is a short exercise — usually shorter than the argument about whether it is worth doing. ## Residual risk After re-rating, what is left on a mitigated row is residual risk, and it is rarely zero. A dropped band means the threat is now competing for attention with other Mediums, not that it left the model. Saying so plainly is what separates a mature re-rating from a victory lap.