Your fourth control on one attack-tree branch barely raises attacker cost — where do you spend next?

## Why the curve flattens Diminishing returns in an attack tree are not a vague economic intuition; they follow from how values propagate. The root takes the **minimum** over alternative branches. So the useful spend on any one branch has a hard ceiling: **the gap between that branch's current cost and the next-cheapest branch.** Push the branch past that point and the root does not move at all, because a different path is now the cheapest and it is the one the attacker will use. That gives a rule you can apply on a whiteboard. If the branch you have been hardening now stands at 40 and the runner-up sits at 12, further hardening of the 40-branch buys exactly zero root cost. Every hour spent there is an hour that produced no change in what the attack costs the adversary. It is worth being precise about where the saturation lives. **Within** an AND path returns do not diminish this way: an AND node sums its children, so raising the cost of any required step raises the branch total, and there is no self-cancelling. The plateau appears at the **OR** level, the moment that branch stops being the minimum. Candidates who say "attack tree costs are logarithmic" or "each control cancels part of the last" have invented a mechanism; the real one is the minimisation. ## The defender side moves against you too The ratio you rank by — attacker-cost rise per unit of defender cost — degrades from both ends as controls stack on one branch: - **Numerator shrinking.** Each control adds less root cost as the branch approaches the runner-up, and nothing after it crosses over. - **Denominator growing.** The cheap, uncontroversial control goes first. Later ones cost more to build, more to run, and impose more friction on legitimate users. On a ticketing platform's bot-resale branch, the fourth control is typically the one that starts failing real customers during a high-demand sale — a cost paid in support volume, refunds and reputation, on a branch that had already stopped setting the root. When you report only the count of controls shipped, both of these are invisible. When you report the root value before and after each one, the plateau is obvious to anybody looking at the table. ## Where the next unit of effort goes When the branch plateaus, there are three defensible destinations, and the tree tells you which: 1. **The branch that now sets the root.** This is the default and it is the whole point of re-costing. On the ticketing tree, that meant leaving automation speed alone and moving to how bulk accounts and payment instruments are acquired in the first place — a different branch, a different team, and a much better return per unit of effort. 2. **Two branches at once.** If the top branches sit close together, no single control moves the root and only a pair does. Fund them as one decision, and be explicit that shipping half of it will produce a table with no improvement in it. 3. **Detection and response instead of prevention.** When every branch has been levelled to roughly the same cost and each further step is expensive, the marginal value of prevention is genuinely low and the same effort spent on noticing and reacting is worth more. Argue it from the flat cost column, not as a slogan. ## Making the argument survive the room The reason to do this on a tree is that the alternative is a debate settled by conviction. The engineer who built the first control on a branch has every reason to propose the fourth; the tree is the artefact that says the fourth buys nothing, without anybody having to be wrong in public. A logistics firm's driver-app fuel-card tree is the clean version of this: two candidate controls, one cheap to build with a modest root rise and one expensive with a large rise, laid out as a two-column comparison, and the decision made on the numbers rather than on seniority. Two cautions before you rely on a plateau. First, a plateau is only as trustworthy as the branch set — if the tree is missing a cheap path, everything above it is mis-ranked, and the flat curve may be an artefact of an incomplete model. Second, resist reading the plateau as a statement about the whole system's security. It says one thing precisely: additional prevention on this branch no longer changes what the modelled goal costs an attacker. That is a spending conclusion, not a verdict on the design.