What does a group STRIDE card session surface that one engineer's solo sweep misses?

## The claim, precisely A group elicitation pass does not find "more threats" as a law of nature. It finds *different* threats — ones that depend on facts, incentives and operational reality that live outside the head of whoever would have done the sweep alone. Understanding which differences it produces is what lets you decide when the group hour is worth its cost. ## 1. Facts are distributed, and the model is not A data-flow diagram records structure, not behaviour. It shows a queue between a producer and a consumer; it does not show that the consumer's retry policy is unbounded, that the queue's dead-letter path is unmonitored, or that a support console can write the same record the approval step wrote. Those facts live with the people who operate and support the thing. A worked case: a squad plays a Denial of Service card against a telemetry-style ingest path. The solo modeler had already looked at that queue and written "availability of the ingest path is out of scope — it is buffered and lossy by design." The SRE holding the card says the buffer only absorbs a burst if consumers keep up, and a low-privilege producer that publishes malformed batches makes every consumer retry until the queue drains its budget. The threat is availability, the attacker position is an authenticated but low-privilege client, and it was invisible to the solo pass — not because STRIDE was applied badly, but because the scoping sentence rested on a behavioural claim the modeler could not check. ## 2. Scoping assumptions get an audience Every solo threat model contains a quiet layer of "not applicable here" decisions, and nobody argues with a sentence one person wrote. In a card session the draw, not the analyst, chooses what gets considered next. You cannot skip Repudiation because you find it boring, and you cannot skip the component you designed because you are confident about it. When a card lands on a scoped-out area, the group either re-derives the reason it was scoped out — which strengthens the model — or discovers the reason has expired. The same mechanism drags out weak-but-real threats. A low card in the Tampering suit against a refunds service gets an engineer to say something they would never volunteer at a whiteboard: a support agent with legitimate access edits the amount after approval. That is an insider attacking money, the least glamorous threat in the room, and precisely the kind a solo sweep by the service's own designer never writes down. ## 3. Disagreement is a model bug, not noise The highest-value moment in a team session is often not a threat at all. Two participants describe the same flow in incompatible ways — one believes the ingest endpoint deduplicates on message id, the other believes the consumer does it. Nothing found before that point is trustworthy, because threats derived from a wrong diagram are noise. The right move is to stop eliciting and fix the model. ## 4. What the group does not fix Be honest about the limits, because interviewers probe here: - It does not repair a missing diagram. A group with no shared model produces anecdotes faster than one person does. - It does not rate anything. Elicitation and risk rating are separate steps, and a session that mixes them stalls on arguments about severity. - It does not guarantee coverage. A hand of cards is a sample, not a sweep; systematic enumeration of elements or interactions makes a completeness claim that a card game does not. - It duplicates. Several cards land on the same element and category, and unless you record threats against the model — one entry per element, category and attacker position — the raw list looks impressive and says nothing. ## 5. Deciding when to spend the hours Five people for ninety minutes is seven or eight engineer-hours plus the preparation. That price is right when the design is new, when it spans teams so no single person holds the facts, when it moves money or handles regulated data, or when the trust boundaries changed. It is poor value for a small change inside one owner's component, where a written pass by that owner — reviewed by one other person — gets most of the benefit. The mature position is not "always model as a group"; it is knowing which designs contain knowledge that no individual holds.