How does the Microsoft Threat Modeling Tool turn a diagram you drew into a list of threats?

## The pipeline The Microsoft Threat Modeling Tool does not look at your system. It looks at a graph you drew and at a template, and the template does all the thinking. **Step 1 — the template.** A template bundles two things. First, *stencils*: the element types you are allowed to place, arranged in a hierarchy under the generic data-flow-diagram element types (a generic process, a generic data store, a generic external interactor, a generic data flow). A more specific stencil, say a web application or a database, inherits from its generic parent. Second, each stencil carries *properties* — small enumerated questions about that element — and the template carries a library of *threat rules* written as conditions over those properties. **Step 2 — the drawing, which is also data entry.** Drawing the diagram is only half the work. Every element and flow has a property sheet, and filling it in is what makes the output differ from the default. Marking a flow as carrying no authentication, or a store as unencrypted, or drawing a trust boundary across a flow, changes which rule conditions evaluate true. **Step 3 — the analysis pass.** The tool walks the model *per interaction*: a data flow together with its source element and its target element. For each interaction it evaluates every rule in the template's library; each rule that matches emits a threat instance, with the element names substituted into a templated title and description, and a STRIDE category attached. **Step 4 — triage, which is the part the tool cannot do.** Each generated threat arrives in a state — not started — and you move it to needs investigation, not applicable, or mitigated, adding a justification. Those justifications are the real output: they are the record of what you decided and why. The tool then produces an HTML report of the model, the threats and their states. ## Why the output repeats itself Because the titles are templated per interaction, a model of any size produces the same line over and over with different names in it — a spoofing threat named against every external entity, a tampering or sniffing threat named against every flow. This is not a malfunction; it is what a rule engine that fires per interaction is supposed to do. Read as a *floor* it is useful: it guarantees that no flow in the model went completely unexamined, and it is a serviceable checklist for a team that has never done this before. Read as a *finding list* it is misleading, because thirty instances of one templated line are one design question, not thirty tickets. The reviewer's job is to collapse the repeats into the small number of distinct design decisions behind them, mark the rest not applicable with a reason that says which control already handles them, and then spend the remaining time on the threats the template could never have known about — the business rule, the operational shortcut, the assumption someone inherited. ## The element with no stencil The tool's stencil sets were drawn for particular styles of architecture, and its default vocabulary shows its origins in on-premises, Windows-shaped systems. Model something the template has no stencil for — a managed message topic, a serverless function, a managed identity — and you have three options, all of which have a cost. - **Map it to the nearest generic stencil.** The model still validates and the rules still fire, but only the generic ones. You get spoofing and tampering boilerplate against a generic process and lose everything specific to that component: nobody asks about the topic's subscription authorisation, its retention, its replay behaviour, or who can create a subscriber. - **Map it to a specific but wrong stencil.** Worse than generic, because the generated threats are now confidently about something the system does not contain, and a later reader believes them. - **Extend the template.** Add the stencil, its properties and its rules. This is the correct fix and it is real work: someone must know both the component and the rule syntax, and the extended template becomes a thing your organisation now maintains. The lesson generalises to every rule-driven modeling tool: *the tool knows what its library knows*. Its silence about a component is not evidence that the component is safe; it is evidence that nobody wrote a rule about it. When you take output from this tool into a review, say out loud which elements were mapped onto generic stencils, because that list is precisely where the generated threats are least trustworthy.