When is a design worth a full STRIDE per-interaction sweep rather than a cheaper per-element pass?

Per-interaction analysis is the more thorough STRIDE variant and the more expensive one, and the expense is not linear. It is worth being explicit about the arithmetic before deciding where to mandate it. ## The arithmetic A per-element pass costs roughly one visit per node. A per-interaction pass costs one visit per *edge*, and edges grow faster than nodes as a design gains parties. Each visit is up to six questions. An e-prescribing hub with four external prescriber systems and three internal processes — a small diagram by any standard — carries request, response, acknowledgement and audit flows between most of those pairs, and lands somewhere around forty to sixty interactions once the store and directory lookups are drawn. At six letters each, that is a couple of hundred rows. Now put that in front of a room for a two-hour design session. Two hundred rows in one hundred and twenty minutes is under forty seconds a row. Nobody thinks about a crossing in forty seconds. What actually happens is that the first twenty rows get real analysis and the remaining one hundred and eighty get "N/A" typed at speed, after which the artifact carries a completeness claim it has not earned. That is worse than not running the sweep, because the next reader believes it. ## The decision So the call is not "thorough or sloppy", it is "where does this design's risk actually live". Per-interaction earns its cost when the answer is *the crossings*: - **A shared component invoked by callers at different trust levels.** The single strongest signal. If a process serves both an anonymous external path and a privileged internal one, a node row must describe both at once and will describe neither. - **Fan-in from external parties.** A hub or gateway aggregating several third-party systems has most of its interesting surface on the edges: which partner is this really, what can they assert, what can they deny sending. - **A destination whose authorization decision depends on which path invoked it.** If the same operation is permitted from one caller and not another, that difference exists only on the interaction. - **Boundaries that carry a real obligation** — regulated data leaving an estate, money moving, an action that must be attributable to a named person. It does not earn its cost on a design whose components each sit alone behind one boundary, on batch jobs reading internal stores, or on any diagram where nearly every edge has the same source trust level, the same destination trust level and the same data class. ## The hybrid that most teams land on The affordable shape is not "pick one variant for the whole system". It is: 1. **Element pass over the whole diagram** as the floor. Cheap, catches the node-local threats, and gives every component *some* coverage. 2. **Interaction pass restricted to boundary-crossing edges.** Intra-boundary hops are dropped by default — same principal, same privileges, same audience on both ends — and pulled back in only where one end is a shared component or the two ends carry different retention or audit obligations. 3. **Collapse by signature.** Key each triple by source trust level, destination trust level and data class, and merge triples that share a signature into one row listing the edges it covers. On the prescribing hub, four prescriber systems that are all external vendor integrations sending the same prescription payload collapse from four sets of rows to one, with a note that a per-partner difference in authentication strength splits them back apart. 4. **Sweep the highest-consequence crossings first**, so the rows that get real thought are the ones where thought pays. On a prescribing hub the dominant asset is not confidentiality — it is integrity and availability, because a tampered or dropped prescription is a patient-safety event, and that ranking should decide which edges the room spends its attention on. What comes out is still a large set of threats, and turning those into an ordered set of fixes is a separate rating exercise with its own method. The point of the selection above is only that every row in the artifact was actually thought about. ## The organisational failure to avoid The tempting policy is "all designs get per-interaction". It reads as rigour and produces theatre: rows answered mechanically, a completeness claim that is untrue, and engineers who conclude that threat modeling is paperwork. The better policy names the trigger — a shared component crossing trust levels, external fan-in, regulated or financial crossings — and lets everything else run the cheaper pass. A rule a team can follow honestly beats a rule that produces impressive artifacts nobody trusts.