How do you decide a team STRIDE elicitation session is finished rather than just out of time?
answer
- the clock is not a criterion
- watch the rate of new accepted threats
- two quiet rounds, not two empty ones
- coverage per category, per valuable flow
- points reward playing, not finding
basics
~20 sStop on saturation and coverage, not the clock: two full rounds with no newly accepted threat, every category played against the flows that matter, and each raised threat accepted, rejected with a reason, or parked against a named unknown.
solid answer
~50 sI use two conditions together. Saturation: two full rounds produce no newly *accepted* threat — accepted, not played, because the scoring rewards playing any card. Coverage: all six STRIDE categories have landed against the elements and boundaries that carry the value, and I can name which. Running out of cards and running out of clock are not criteria; they are events. On a distributed session over a telemetry ingest service, the honest exit was that the last two rounds only produced duplicates against paths we had already worked, while the write path had all six categories dispositioned. Anything the group cannot agree on gets parked with the fact that would settle it — does the endpoint deduplicate on message id — rather than accepted to avoid an argument or dropped to keep the list tidy. And if the diagram turns out to be wrong mid-session, you stop eliciting and fix the model.
go deeper
Know that a threat-modeling session is not finished just because the meeting ended or the cards ran out, and that each threat raised needs a recorded outcome rather than being left hanging.
Explain saturation in the right terms: no newly accepted threat over a couple of full rounds, where accepted is stricter than raised, because participation scoring keeps the raised count climbing regardless.
Show you check coverage as well as saturation — name which categories landed on which valuable flows — and handle a contested threat by parking it against the fact that would settle it.
Own the measurement problem. Argue why threat count is a corrupting metric, define what your organisation accepts as evidence a design has been examined, and be candid that no pass proves completeness.
## "Done" is a claim, so make it a checkable one A team elicitation session ends for one of two reasons: something happened to it, or a criterion was met. The clock expiring, the deck emptying and the room getting tired are all things that happen. None of them says anything about the design. If you want the output to be defensible — to a reviewer, to a team deciding what to fix, to yourself in three months — the exit needs to be a claim someone could challenge. ## The two conditions worth defending **Saturation.** Two full rounds of play with no *newly accepted* threat. The word accepted is load-bearing. A card-driven session scores participation: you get a point for playing a card, and social pressure rewards playing rather than passing. Raw played-card count therefore rises steadily whether or not anything is being learned. What flattens near the end of a productive session is the rate of *distinct, accepted* threats. Track that, and the curve tells you when you have stopped learning. **Coverage.** You can name which STRIDE categories have been played against which parts of the model, and every part that carries real value has seen all six. Saturation alone is a trap: a room can exhaust its enthusiasm having only worked the two flows it finds interesting. If the money-moving path or the audit-log write has only ever been examined for Spoofing and Information Disclosure, the session is not finished no matter how quiet the last two rounds were. Hold these together. Saturation without coverage means the group got bored. Coverage without saturation means you are still finding things and should keep going. ## Criteria that look reasonable and are not - **"The deck ran out."** The number of cards has no relationship to the size or shape of your model. A hand ends; an analysis does not. - **"The time-box ended."** A time-box is a budget, not a completeness test. Ending on time is fine; *declaring the model complete* because the hour ended is not. Say what remains unexamined. - **"We found enough threats."** Usually shorthand for "we filled the remediation capacity we expect to get." That is a prioritisation decision, and mixing it into elicitation quietly suppresses findings before anyone has rated them. - **"We hit our threat count target."** Counting threats as a metric guarantees inflation. Every ambiguity resolves toward accept, duplicates get split, and the list becomes worthless as evidence. ## The gamification problem, stated plainly The scoring in a card session is a participation mechanic. It rewards playing a card, not playing the right one, and it never distinguishes a threat that will get fixed from one raised to keep a turn moving. That is a fine trade for engagement, but it means the score, the card count and the length of the raw list are all measures of *the session*, never of *the design*. Anyone reporting "we found 47 threats" as an outcome has mistaken one for the other. Report which parts of the model were examined against which categories, and what was accepted. ## Half-accepted threats The hardest exit case is a threat the table cannot agree is real. There are three dispositions and only one of them is honest: - Accept it to end the argument: inflates the list and burns credibility when the owner rejects it later. - Drop it because there is no consensus: hides a genuine gap, and consensus was never the accept bar. - **Park it with the fact that would settle it.** "Does the ingest endpoint deduplicate on message id? If not, a compromised collection agent can replay batches and corrupt the counts other teams bill from." Now the argument is a question with an answer, and the answer arrives later without the room. Most unresolvable disagreements are not disagreements about security at all. They are two people holding different facts about the system, which is a model gap wearing a threat costume. ## Stop early when the model is wrong One condition ends a session before either criterion is met: the diagram turns out not to match what is being built. Threats elicited against a wrong model are noise, and the group's time is better spent redrawing. This is a genuine outcome, not a failure — a session that ends with "we cannot model this yet, here is what we discovered we do not agree on" has produced something real. ## The honest limit No elicitation pass proves there are no more threats. "Done" always means done against *this* diagram, at *this* level of detail, with the people who were in the room. Say so when you report. A lead who claims completeness is claiming something no threat-modeling method can deliver, and an interviewer will push on exactly that.
- What do you do with a threat the table cannot agree is real?Park it with the fact that would settle it, phrased as a question — does the ingest endpoint deduplicate on message id? Accepting it to end the argument inflates the list; dropping it treats consensus as the accept bar and hides a gap. Most unresolvable disagreements are two people holding different facts about the system, which makes them model defects rather than judgement calls.
- Why is the number of cards played a poor measure of coverage?Because the scoring rewards playing a card whether or not a threat lands, and the count mixes accepted threats, rejections, duplicates and tangents into one number. Coverage is a statement about the model: which categories were examined against which elements and boundaries, and which parts of the design nobody reached. Report that, and report what was accepted.
- The diagram turns out to be wrong halfway through the session. Now what?Stop eliciting and fix the model. Everything found after that point is derived from a system nobody is building, so it is noise you will have to re-triage anyway. Redraw the affected area with the people who know it, confirm the room agrees, then resume from that element. Ending a session with a corrected diagram and few threats is a real outcome.
- How do you report 'done' to someone who was not in the room?State the scope: which version of the diagram, which elements and boundaries were examined, which categories landed on each, and what was explicitly left unexamined. Then the accepted threats and the parked questions. Never claim completeness — done means done against this model at this level of detail, and being precise about that is what makes the output reusable.
saying these in an interview costs you the question
- Says the session is done when the deck runs out
- Uses raw threat count as the coverage metric
- Calls the model complete because the time-box ended
- Accepts contested threats to avoid the argument
- Drops a threat because the group lacked consensus
- Claims an elicitation pass proves no threats remain
- Keeps playing cards after the diagram is shown to be wrong