Article
Threat Modeling Connected Medical Devices: A Practitioner Guide
Key takeaways
- Threat modeling is a design activity, not a documentation activity; doing it at submission time is what costs companies their timeline.
- Intended use and clinical workflow are inputs to the threat model, not framing; the same device on a hospital backbone and in a home setting has different threats.
- Every external interface that physically exists on the device is in scope. 'Out of scope' is not an answer for a USB port that ships enabled.
- STRIDE is fine; what reviewers want is traceability from threat to control to verification, not the framework choice.
- The threat model is a living artifact and feeds the SBOM, the risk file, the test plan, and the postmarket monitoring plan.
Why this matters
Threat modeling is the spine of the FDA premarket cybersecurity package. The SBOM tells you what is in the device; the threat model tells you what can go wrong and what you did about it. Of the 250+ submissions my team at Blue Goat Cyber cleared in 2025, the strongest correlation with first-pass clearance was the quality of the threat model, not the volume of supporting evidence.
The failure mode is consistent. Teams treat threat modeling as a STRIDE table generated near the end of the project, disconnected from the architecture diagrams the engineers actually use. Reviewers see immediately that the threat model and the design do not reference each other, and the deficiency letter that follows costs the program months. Done early and revisited every milestone, threat modeling is one of the highest-leverage activities in MedTech development.
Where does a real threat model start?
It starts with intended use, clinical workflow, and the deployment environment. A wearable monitor in a patient's home faces a different threat surface than the same monitor in an ICU on a segmented clinical network. The threat model has to name the environment explicitly, because the controls that follow depend on it.
Next comes a system architecture diagram with trust boundaries drawn on it. Every component, every data flow, every interface, every storage location. The trust boundaries are not decorative; they are the lines along which threats arise. If you cannot draw the boundary, you do not yet have a model worth assessing.
What does a credible interface enumeration look like?
Every physical and logical interface that exists on the shipped product, regardless of whether you 'intend' it to be used. USB ports that ship enabled. Service connectors. Debug headers. Wireless radios, including ones disabled in software but present on the board. Bluetooth, Wi-Fi, NFC, cellular, proprietary RF. Removable media. Wired network ports. Companion mobile apps. Cloud APIs. Update channels. Telemetry channels.
For each interface, document the protocol, the authentication mechanism, the data classification crossing it, and whether it is reachable pre- or post-authentication. Reviewers count interfaces against the architecture diagram and against the device they can physically inspect. Omissions become deficiencies.
How do you classify threats so the analysis holds up?
STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the most common methodology and FDA reviewers are fluent in it. For each asset and interface, walk the six categories and ask what a motivated adversary could do. Discard categories that genuinely do not apply, but document why, not just the absence.
For scoring, use a structured method (CVSS adapted for medical context, or a custom rubric tied to patient-safety severity). The exact rubric matters less than its consistency across the model. Reviewers can follow any defensible system; they cannot follow a model that scores similar threats differently with no rationale.
How do you tie mitigations to verifiable controls?
Every identified threat that you are not accepting needs a mitigation, and every mitigation needs (1) a design control that implements it, (2) a verification activity that proves it works, and (3) evidence from that verification stored where the auditor can find it. This is the traceability chain reviewers look for: threat to control to verification to evidence.
When a threat is accepted with residual risk, the justification has to address why the residual risk is acceptable under the device's intended use and risk classification. 'Low likelihood' is not a justification; quantified likelihood against the specific deployment environment is. AAMI TIR57 gives you the structural language for this.
How does the threat model connect to the rest of the submission?
The threat model is upstream of almost everything else. The SBOM informs the threat model (each component is a potential threat origin); the threat model drives the test plan (each threat becomes a test case); the test plan generates the verification evidence; the residual risks feed the postmarket monitoring plan and the labeling.
When these artifacts cross-reference each other and use consistent identifiers, the submission reads as a single coherent argument. When they do not, the submission reads as a stack of disconnected documents, and reviewers treat it that way.
When and how often do you revisit the model?
At every architecture change, at every release, and on a recurring postmarket cadence tied to the threat landscape. New CVEs against embedded components, new attack techniques in the medical device research community, and new deployment patterns (a device suddenly being used in home settings) all trigger revisits.
The model lives in version control, alongside the design. The pull request that changes the architecture also updates the threat model, or it does not merge. Anything looser drifts within a quarter.
How Christian approaches this
At Blue Goat Cyber we run the first threat-modeling workshop before the architecture is frozen, with product, engineering, regulatory, and clinical in the same room. The model is treated as a living design artifact, versioned with the code, updated at every milestone, and used as the source of truth for the test plan, the SBOM scope, and the postmarket plan.
The approach is documented in my 2026 book, Medical Device Cybersecurity: An In-Depth Guide (see the chapter overview). The threat modeling chapter is the longest in the book on purpose; it is the place where MedTech programs most often save (or burn) months of timeline.
Related guides: SBOM hygiene for medical devices, Postmarket vulnerability management, and What the FDA actually wants in a 2026 premarket submission.