Threat modeling for consequential systems
A threat model written at design time is a design input, not an after-the-fact explanation: its six questions are asked of 100% of trust boundaries, and every threat with a plausible path to patient harm becomes a hazard entry in the ISO 14971 risk management file.
Why should threat modeling happen at design time?
A threat model written at design time is a design input, not an after-the-fact explanation. Every threat with a plausible path to patient harm becomes a hazard entry in the ISO 14971 risk management file.
A threat model written after the system is built is an explanation of what was already decided. A threat model written at design time is a design input — it changes what gets built, not just what gets documented about it afterward. The difference is entirely about when the exercise happens, not how sophisticated the diagram is.
Threat modeling at design time, not audit time
A threat model produced to satisfy an audit checklist, after architecture decisions are already locked in, can only explain those decisions — it has no power to change them. Run at design time, against a specific system boundary, the same exercise surfaces mitigations that are cheap to design in and expensive to retrofit later.
A systematic elicitation frame
Six questions, asked of every trust boundary in the system, not just the obvious ones:
| Category | Question it forces | Example mitigation |
|---|---|---|
| Spoofing | Can an actor convincingly claim to be someone or something they're not? | Mutual TLS, signed and verified tokens |
| Tampering | Can data be modified in transit or at rest without detection? | HMAC signatures, write-ahead-log checksums |
| Repudiation | Can an actor deny taking an action, with no way to prove otherwise? | An immutable, non-repudiable audit log |
| Information disclosure | Can data reach someone who shouldn't see it? | Encryption at rest and in transit, least-privilege access |
| Denial of service | Can an actor make the system unavailable to legitimate users? | Rate limiting, bounded resource quotas |
| Elevation of privilege | Can a low-privilege actor gain higher privilege? | Authorization checked at every boundary, not only at login |
From threat model to risk management file
Not every identified threat is a safety hazard, but every threat with a plausible path to patient or operational harm belongs in the MedTech risk management file as a hazard entry — see ISO 14971:2019. A threat model that never crosses into the risk file has identified problems nobody is formally tracking.
A worked boundary example
A minimal worked example, from this site's own magic-link sign-in boundary:
Boundary: magic-link verification endpoint
Threat: token replay (Tampering / Spoofing) — a captured verification
URL reused after the legitimate sign-in already completed
Mitigation: token is single-use (consumption is atomic with the
session-creation write), signed with an HMAC key the client never
sees, and expires in under 15 minutes
Residual risk: a token captured and replayed within the TTL, before
first use — accepted, given the delivery channel (email) and the
short windowEngineering reference only. Not a complete security assessment — a real threat model requires walking your own system's actual boundaries, not substituting this page's example for that work.
Provenance & review state
- Last reviewed
- Sources
-
- NIST SP 800-154 (Draft), Guide to Data-Centric System Threat Modeling — National Institute of Standards and Technology
- ISO 14971:2019 — International Organization for Standardization
- Ingested from
-