When do you stop pushing a branch of an attack tree deeper?

## Depth is a budget, not a target Beginners treat an attack tree like an org chart and try to make it tidy — every branch pushed to roughly the same level. That instinct produces two failures at once: shallow branches get padded with invented children, and the branches that would actually have repaid detail get the same attention as the ones that would not. The useful mental model is the opposite. Depth is a finite budget of attention, spent where the defender still has choices to make. ## Four things that mean stop **1. Actionability reached.** The node names something a competent engineer could cost and act on: a specific action with an implied, ownable control. This is the same granularity test that separates a concrete leaf from a category leaf, read from the other side — the moment it passes, you are done with that line. **2. No decision changes below this point.** If every child you could write would resolve to the same single control with the same owner, the split is decoration. Decompose while the children differ in how you would stop them; stop when they stop differing. **3. The branch has left your sphere of influence.** This is the subtle one, and it is where senior candidates separate themselves. Consider a newsroom's confidential-source submission box hosted on a managed platform. The asset is source identity, and one adversary is the hosting operator itself — compromised, or a party able to compel them. The branch *the provider is compelled or turned* can be decomposed: obtain the platform's records, correlate submission timing, identify the account. But none of those children changes what the newsroom does next. The defender's real moves all sit **above** that node: hold nothing at the provider that identifies a source, strip and expire metadata, split trust so no single operator holds enough. So the branch stops at one leaf, and the design conversation moves up a level instead of down. Further decomposition would have produced pages that no control could ever attach to. **4. You would be inventing.** If the next level requires facts about the component that nobody in the room has, stop. Record the node as an open assumption with an owner, and let it be visibly incomplete. A branch honestly marked *not yet understood* is far safer than a branch padded with plausible-sounding children, because the padding makes an unexamined area look examined. ## Uneven depth is information On the newsroom tree, *compel the provider* stops at depth one while *obtain a copy of submission traffic in transit* runs four levels, because that second branch has genuinely separable actions with genuinely different mitigations. The asymmetry is not sloppiness; it is a readable statement about where the defender has leverage. A reviewer who says 'this branch is underdeveloped' should be answered with the reason, not with padding. ## Record why you stopped The single most valuable habit here is annotating the stop. A leaf that stops because it is actionable, one that stops because it is outside your control, and one that stops because nobody knew the answer are three completely different states — and they render identically as a node with no children. Six months on, with a different reader, an unmarked stop is indistinguishable from an abandoned branch. A one-line reason on the node preserves the judgment: *stopped — no defender-side choice below this point*, or *stopped — needs the platform team, open question*. ## The two costs of getting it wrong Stopping too early leaves category leaves: headings that look like threats, imply no control, and hide the paths underneath them. Stopping too late produces a tree so large nobody finishes reading it, and it also manufactures false confidence — a big tree feels exhaustive, and an exhaustive-feeling tree stops people asking what is missing. Between the two, over-depth is the more expensive failure in practice, because it burns the budget you needed for the branch that mattered and it hides that fact behind volume. ## Revisit the stops, not just the tree Stopping criteria are not permanent. A branch stopped because it was outside your influence becomes worth decomposing the moment you take ownership of that component or change providers; a branch stopped for lack of knowledge reopens when the answer arrives. Treat the annotated stops as the tree's to-do list on the next revision, which is also the cheapest way to make an attack tree a living artifact instead of a one-off diagram.