--- title: "Threat Modeling Connected Medical Devices: A Practitioner…" description: "A threat model that survives FDA review names the asset, draws the trust boundary, enumerates every interface, classifies the threat, and ties each mitigation…" lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Person", "@id": "https://christianespinosa.com/#person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "image": "https://christianespinosa.com/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg", "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ], "jobTitle": "Bestselling Author, Keynote Speaker, Entrepreneur", "worksFor": { "@type": "Organization", "name": "Blue Goat Cyber", "url": "https://bluegoatcyber.com/" } }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://christianespinosa.com/#website", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "publisher": { "@id": "https://christianespinosa.com/#organization" }, "inLanguage": "en-US" }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://christianespinosa.com/#organization", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" }, "founder": { "@id": "https://christianespinosa.com/#person" }, "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "Threat Modeling Connected Medical Devices: A Practitioner Guide | Christian Espinosa", "description": "A threat model that survives FDA review names the asset, draws the trust boundary, enumerates every interface, classifies the threat, and ties each mitigation to a verifiable design control. Here is how to build one.", "image": "https://christianespinosa.com/assets/og-default-vx4o85jG.jpg", "datePublished": "2026-06-21T13:10:00Z", "dateModified": "2026-06-21T13:10:00Z", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://christianespinosa.com/guides/threat-modeling-connected-medical-devices-a-practitioner-guide" }, "author": { "@type": "Person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/about" }, "publisher": { "@type": "Organization", "name": "Christian Espinosa", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" } } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Is STRIDE the only methodology FDA accepts?", "acceptedAnswer": { "@type": "Answer", "text": "No. PASTA, LINDDUN, and custom methodologies are all acceptable if they are applied rigorously and produce a traceable threat-to-control-to-verification chain. STRIDE is just the most common and the easiest for reviewers to follow." } }, { "@type": "Question", "name": "How detailed does the architecture diagram need to be?", "acceptedAnswer": { "@type": "Answer", "text": "Detailed enough that every component, data flow, trust boundary, and external interface is visible. One diagram is rarely sufficient for a complex device; use a layered set (system, subsystem, interface) that ties together." } }, { "@type": "Question", "name": "Do I have to threat model the cloud backend separately?", "acceptedAnswer": { "@type": "Answer", "text": "If the cloud backend is part of the device's clinical function or stores patient data, yes. The cloud, the companion app, and the device form one system from a threat-modeling perspective, even if they are reviewed under different regulatory umbrellas." } }, { "@type": "Question", "name": "How do I threat model AI/ML components in SaMD?", "acceptedAnswer": { "@type": "Answer", "text": "Add model-specific threats: data poisoning, model extraction, adversarial inputs, prompt injection for LLM-backed features, and supply-chain compromise of training data and pretrained weights. FDA is actively building expectations here and the conservative position is to address them now." } }, { "@type": "Question", "name": "What is the right size for a medical device threat model document?", "acceptedAnswer": { "@type": "Answer", "text": "Big enough to be complete and small enough to be readable. For a Class II connected device, expect tens of pages of model plus appendices for verification evidence. If the model fits on one page, it is incomplete; if it runs to hundreds of pages, it is probably duplicating content from other artifacts." } } ] } ] --- [Skip to content](#main) [](/) [About](/about)[Speaking](/speaking)[Cybersecurity](/cybersecurity)[Programs](/programs)[Books](/books)[Media](/media) Writing Search Ctrl K[Connect](/connect) Article # Threat Modeling Connected Medical Devices: A Practitioner Guide Direct answer A defensible medical device threat model starts from intended use, draws explicit trust boundaries on a system architecture diagram, enumerates every external interface (wired, wireless, USB, service port, supply chain), classifies threats with a structured methodology like STRIDE, ties likelihood and impact to patient safety, and maps each mitigation to a verifiable design control with traceable evidence. Anything looser draws a deficiency letter. ## 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. On this page 1. [Where does a real threat model start?](#where-does-a-real-threat-model-start) 2. [What does a credible interface enumeration look like?](#what-does-a-credible-interface-enumeration-look-like) 3. [How do you classify threats so the analysis holds up?](#how-do-you-classify-threats-so-the-analysis-holds-up) 4. [How do you tie mitigations to verifiable controls?](#how-do-you-tie-mitigations-to-verifiable-controls) 5. [How does the threat model connect to the rest of the submission?](#how-does-the-threat-model-connect-to-the-rest-of-the-submission) 6. [When and how often do you revisit the model?](#when-and-how-often-do-you-revisit-the-model) ## 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](https://bluegoatcyber.com/) 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. KEY MISTAKE Generating a STRIDE table at submission time, disconnected from the architecture the engineers actually built. Reviewers spot this on the first pass and read the rest of the submission with a skeptical eye. REVIEWER LANGUAGE 'The submission does not adequately address residual cybersecurity risk' usually means your threat model identified threats, named mitigations, and never showed the verification evidence that the mitigations work. ## How Christian approaches this At [Blue Goat Cyber](https://bluegoatcyber.com/) 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](https://medicaldevicecybersecuritybook.com)_ (see the [chapter overview](/books/medical-device-cybersecurity)). 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](/guides/sbom-hygiene-for-medical-devices-a-practical-2026-playbook), [Postmarket vulnerability management](/guides/postmarket-vulnerability-management-for-connected-medical-devices), and [What the FDA actually wants in a 2026 premarket submission](/guides/what-the-fda-actually-wants-in-a-2026-premarket-cybersecurity-submission). ### Get the full playbook in book form This guide is one slice of \*Medical Device Cybersecurity: An In-Depth Guide\*, shipping in 2026. Get launch notification, the full chapter list, and a sample on the book site. [Visit the book site](https://medicaldevicecybersecuritybook.com) Prefer the on-site overview? See the chapter list at /books/medical-device-cybersecurity. ## Frequently asked questions ### Is STRIDE the only methodology FDA accepts? No. PASTA, LINDDUN, and custom methodologies are all acceptable if they are applied rigorously and produce a traceable threat-to-control-to-verification chain. STRIDE is just the most common and the easiest for reviewers to follow. ### How detailed does the architecture diagram need to be? ### Do I have to threat model the cloud backend separately? ### How do I threat model AI/ML components in SaMD? ### What is the right size for a medical device threat model document? ### Get the full playbook in book form This guide is one slice of \*Medical Device Cybersecurity: An In-Depth Guide\*, shipping in 2026. Get launch notification, the full chapter list, and a sample on the book site. [Visit the book site](https://medicaldevicecybersecuritybook.com) Prefer the on-site overview? See the chapter list at /books/medical-device-cybersecurity. About the author [Christian Espinosa](/about), MBA, CISSP, PMP · Founder, Blue Goat Cyber · Author, Medical Device Cybersecurity: An In-Depth Guide (2026) I'm the founder and CEO of Blue Goat Cyber, a medical device cybersecurity firm where my team has supported 250+ FDA submissions with zero failing to clear on cybersecurity. I previously founded and sold Alpine Security. I host The Med Device Cyber Podcast and wrote The Smartest Person in the Room and The In-Between: Life in the Micro, with Medical Device Cybersecurity: An In-Depth Guide out in 2026. Air Force Academy grad, 24x Ironman, climber of two of the Seven Summits. Christian Espinosa Bestselling author, keynote speaker, and Founding CEO of [Blue Goat Cyber](https://bluegoatcyber.com/). Helping technical leaders develop the soft skills that turn brilliance into impact. [](https://www.linkedin.com/in/christianespinosa/)[](https://x.com/Ironracer)[](https://www.instagram.com/christian.espinosa.official/)[](https://www.youtube.com/@ChristianEspinosaOfficial)[](https://www.facebook.com/christian.espinosa.official) Explore - [About](/about) - [Timeline](/timeline) - [Speaking](/speaking) - [Cybersecurity](/cybersecurity) - [Programs](/programs) Read - [Books](/books) - [Guides](/guides) - [Blog](/blog) - [Media](/media) - [Podcast Interviews](/podcasts) - [Success Stories](/success-stories) Connect - [Contact Christian](/connect) - [LinkedIn ↗](https://www.linkedin.com/in/christianespinosa/) - [Blue Goat Cyber ↗](https://bluegoatcyber.com/) - [Resources](/resources) © 2026 Christian Espinosa. All rights reserved. [Privacy](/privacy-policy)[Terms](/terms-of-use)