An interviewer says - we have just talked through your design for the refund flow. Threat-model it out loud in ten minutes.

What the interviewer is testing

Whether you have a repeatable method, whether you can prioritise, and whether you stop. Ten minutes is the test: a candidate who enumerates 40 threats has demonstrated a checklist, not judgement. They want to see you find the two or three threats that would actually change the design.

The clarifying questions that change the answer

• Who can initiate a refund, and is there an amount above which a human approves? Authorisation model and limits determine most of the threat surface.
• Is the money movement idempotent, and what is the key? This decides whether a retry is a double refund.
• Which party is the attacker in your threat model - an external fraudster, a compromised customer account, a malicious or coerced insider in support, or a compromised service? These produce different priorities, and the insider case is the one teams skip.
• What is already assumed - identity provider, network controls, logging - so you spend the ten minutes on this flow rather than re-deriving the platform.

A strong answer's arc

1. Name the asset in business terms. The ability to move money to an account the business does not control. That framing immediately ranks threats by amount and by reversibility.
2. Draw the boundaries, not the components: customer to API, support agent to admin tool, service to payment provider, service to ledger. Threats live on boundaries, so this is the step that makes the rest systematic.
3. Walk STRIDE on the two highest-value boundaries only. For support-agent to admin tool: spoofing (stolen agent session), tampering (changing the destination account after approval), repudiation (no record of who approved), information disclosure (full card data in the agent view), denial of service (low value here), elevation of privilege (an agent granting themselves a higher limit). Say out loud which you are skipping and why.
4. Rank by what the attacker gains against how easy it is, then name the three mitigations you would actually build: refund destination restricted to the original payment instrument, a second approval above a threshold with the approver recorded separately from the requester, and an idempotency key derived from the refund request rather than generated per attempt.
5. State the residual risk you are accepting, and what would make you revisit it - for example a rise in refunds to new instruments, or the first case of agent-account compromise.

Common weak answers

• Reciting STRIDE across every component, producing a long undifferentiated list and running out of time before any mitigation is proposed.
• Jumping straight to controls - "we would use mTLS and encrypt everything" - with no asset and no boundary, so nothing is prioritised and the insider path is missed entirely.
• Treating the external attacker as the only adversary. In a refund flow the expensive incidents are usually internal or account-takeover driven.
• No stopping condition. A threat model that does not say what is out of scope has not made any decisions.

What a strong answer adds

Detection and economics. For each accepted risk, name the signal that would reveal it - refunds to instruments added in the last 24 hours, approvals where requester and approver resolve to the same person, refund rate per agent against the team median - because a threat model whose output is only preventive controls will be partly wrong and silent about it. And name the cost: a second approval above a threshold adds handling time to a support queue, so the threshold is a business decision, which is exactly the kind of trade a staff engineer is expected to put to someone else rather than decide alone.

The decision rule to state out loud: prefer 2 boundaries taken to the end - threat, mitigation, residual risk, detection signal - over 8 boundaries enumerated, because only the first changes the design. STRIDE itself dates from Microsoft's threat-modelling work in 1999 and is a prompt list, not a method; the method is the boundary diagram and the ranking. The failure mode of the alternative is documented in every review that produces 40 findings and no owner, which is then rediscovered unchanged at the next review.