If you’re asking how to conduct a cybersecurity threat model for a connected or implantable medical device, the first thing to understand is that this is not the same exercise as modeling a web application or enterprise network. The stakes are categorically different. A missed attack vector on a hospital SaaS platform leads to a data breach. A missed attack vector on a networked insulin pump or an implantable cardiac device can directly harm a patient. That distinction shapes every decision in the process, from how you define scope to how you score and document risk.
The FDA’s 2023 and 2026 premarket cybersecurity guidance makes threat modeling a regulatory requirement, not an optional best practice. Manufacturers must document threat modeling activities across the entire device system and demonstrate that threats were identified, assessed, and mitigated throughout the design process. For teams that haven’t built this capability internally, Blue Goat Cyber runs this process end-to-end, producing threat model outputs structured for FDA review and traceable to every design decision. What follows is the five-step process we use.
Why FDA reviewers pay close attention to your threat model
The FDA’s 2023 guidance established that threat modeling must be performed throughout the design process and must cover all medical device system elements, not just the device hardware. The 2026 guidance tightened this further, embedding threat model requirements directly into design controls under Section 524B of the FD&C Act. Reviewers now expect to see a detailed, traceable model as a core design input, not a document assembled retroactively before submission.
What “sufficient” means to an FDA reviewer is specific. They expect manufacturers to show that trust boundaries were identified across the full system, that threats were enumerated across every interface, and that mitigations are verifiable. The EU MDR similarly recognizes threat modeling as a recommended best practice for demonstrating cybersecurity risk reduction. Both frameworks reflect the same underlying logic: a manufacturer who cannot document how they identified and addressed threats has not demonstrated control over their device’s security posture.
What the FDA premarket guidance actually requires
The FDA’s premarket cybersecurity guidance specifies several concrete documentation elements for threat modeling. Manufacturers must identify assets (patient data, firmware integrity, therapy algorithms, device availability), map data flows with explicit trust boundaries, enumerate threats and misuse cases prioritized by clinical impact, and capture supply chain risks introduced through manufacturing, deployment, and decommissioning. The 2026 guidance adds that security architecture documentation must include communication path diagrams, protocol specifications, and third-party component inventories, all traceable back to the threat model.
How ISO 14971 and AAMI TIR57 extend to cybersecurity
ISO 14971 provides the foundational risk management process that the FDA references when evaluating medical device safety. AAMI TIR57 provides the cyber-specific extension that connects security risk analysis to patient safety harm scenarios. The relationship between the two is direct: a cybersecurity threat identified through threat modeling must be evaluated not just as a technical vulnerability but as a potential contributor to patient harm. That connection between security exploitability and clinical hazard is what regulators expect to see documented in your risk management file.
Step 1: Define the system boundary and map your data flows
Most threat models fail not because of bad analysis but because the scope is too narrow. The system is not just the device. It includes the companion mobile app, the cloud backend, the hospital network, clinical workstations, external firmware update servers, and, for implantable devices, proprietary RF programming interfaces. Every element that a threat actor could interact with belongs inside the model boundary.
The MITRE/MDIC Playbook for Threat Modeling Medical Devices structures this using data flow diagrams that progress from a high-level overview to detailed sub-diagrams. The high-level diagram shows major components and their relationships. The detailed diagrams expand each component to reveal trust boundaries, specific communication channels, and external entities like hospital systems and update servers. Trust boundaries are the critical element here because threats live at those boundaries, where one zone of control hands off data to another. For more references and templates, see our Medical Device Threat Modeling Resources, Blue Goat Cyber.
Setting the device perimeter: what belongs inside the model
For connected devices, five zones consistently belong in scope: the device itself (firmware, hardware interfaces, debug ports), the device-to-app communication channel, the mobile or web application, cloud APIs and storage, and the clinical environment, including hospital network segments and EHR integrations. For implantable devices, the model adds the complexity of proprietary RF programming interfaces, which typically have a narrow physical range but carry high-consequence command authority over therapy delivery.
Building a data flow diagram that an FDA reviewer can follow
A well-labeled DFD uses five element types: actors (clinicians, patients, administrators), processes (therapy engine, data logger), data flows (telemetry stream, firmware update packages), data stores (cloud patient records, device logs), and external entities (update servers, hospital systems). Each data flow crossing a trust boundary gets labeled with the protocol, the authentication method, and the encryption status. That level of specificity is what allows an FDA reviewer to trace from the diagram directly to the security controls documented in your submission.
Step 2: Identify critical assets and map the attack surface for connected medical devices
Assets in a medical device context are not just data. They include therapy algorithms, firmware integrity, device availability, command authentication, and the communication channels that deliver programming instructions. The right question to drive asset identification is: what could an adversary target to cause patient harm or operational disruption? Organizing assets into four categories makes this systematic:
- Patient safety assets: therapy delivery parameters, dosage settings, alarm thresholds
- Data integrity assets: PHI, sensor readings, audit logs
- System integrity assets: firmware, boot chain, cryptographic keys
- Availability assets: device uptime, monitoring continuity, remote access channels
Attack surfaces for connected devices span wireless interfaces (Bluetooth, proprietary RF), wired interfaces (USB, debug ports), telemetry streams, over-the-air firmware update channels, and cloud APIs. Implantable devices have a narrower surface but higher consequences at each point. Consider two real-world examples that illustrate the stakes. The 2017 Abbott/St. Jude recall affected approximately 500,000 pacemakers due to unauthorized access vulnerabilities. Separately, demonstrated lab attacks on insulin pump command channels showed that adversaries could manipulate dose delivery remotely. These surfaces are not theoretical. They are actively researched and, in some cases, exploited.
Step 3: Apply STRIDE to enumerate threats across every interface
STRIDE is the framework most aligned with FDA and MITRE/MDIC guidance for medical device threat modeling. It maps naturally to DFD elements, produces a systematic enumeration rather than an ad hoc list, and generates documented rationale for each threat category applied or excluded. Applied across the four primary interface types, the threat picture becomes concrete quickly.
Wireless interfaces
- Spoofing: a rogue controller impersonates a legitimate programmer to trigger unauthorized dose delivery on an insulin pump
- Tampering: commands altered in transit to modify therapy settings mid-transmission
- Denial of service: signal jamming interrupts continuous monitoring
Firmware update channels
- Spoofing: a fake update server delivers malicious firmware to the device
- Tampering: an OTA package is modified in transit to inject a persistent backdoor
- Elevation of privilege: a firmware vulnerability exploited to achieve root access
Cloud APIs
- Spoofing: the cloud service is impersonated to inject false data into clinical dashboards
- Information disclosure: a misconfigured IAM role exposes full tenant data
- Denial of service: a monitoring endpoint is flooded to disable remote oversight
Telemetry streams
- Tampering: false sensor data is injected to trigger incorrect treatment decisions
- Information disclosure: unencrypted PHI is intercepted in transit
- Denial of service: telemetry gateway capacity is exhausted, creating monitoring blind spots
Each mapped threat requires three additional fields in your documentation: the hazardous patient safety outcome that results if the threat is realized, the attack path sequence, and the proposed mitigation with its verification method. When a STRIDE category genuinely does not apply to a DFD element, that documented rationale also belongs in the submission. FDA reviewers notice gaps in enumeration just as readily as they notice gaps in mitigations.
STRIDE for medical devices: when to supplement with other methods
For implantable devices with complex multi-step attack chains, for example, a scenario where an attacker compromises a home monitoring unit, pivots to the programming interface, and modifies pacing parameters, attack trees provide additional depth that STRIDE alone does not capture. PASTA adds business-context framing that can be useful when presenting risk to cross-functional stakeholders. The FDA does not mandate a specific framework. They require a justified, documented methodology, and they expect to see that choice explained in the threat model report.
Step 4: Score and prioritize threats using clinical impact
Standard CVSS scoring was designed for enterprise IT environments. It does not account for patient safety outcomes, and applying it without modification to a medical device threat analysis produces prioritization decisions that can be clinically misleading. A UI authentication flaw on an infusion pump’s web interface and a dosage parameter manipulation vulnerability both receive scores from the same base metrics, but their clinical consequences are not remotely equivalent.
The FDA-qualified MITRE Rubric for Applying CVSS to Medical Devices (MDDT Q171974) addresses this directly. It provides structured decision trees that guide cross-functional teams through scoring each vulnerability in clinical context, examining how it affects therapy delivery, monitoring continuity, and clinical workflow. Published analysis of CVSS 4.0 scoring with environmental modifiers applied to hospital device profiles indicates that a meaningful share of vulnerabilities shift severity tiers when clinical context is factored in, a finding consistent with the rubric’s design intent. That shift matters for resource allocation and for the residual risk acceptance rationale your submission must include.
Documenting the safety-security tradeoff
The tension between security controls and patient safety is unique to this domain and must be explicitly documented. Adding password-protected authentication to a defibrillator’s emergency access workflow improves cybersecurity posture but creates latency risk in a cardiac emergency. That tradeoff is not a problem to be hidden; it is a design decision to be analyzed, documented, and resolved with a justified benefit-risk position. This documentation belongs in the design history file and supports FDA reviewers who need to see that manufacturers recognized and addressed these tensions deliberately rather than defaulting to IT-standard controls without clinical adaptation.
Step 5: Build traceable mitigations and structure your FDA submission output
The threat model deliverable is not a spreadsheet. It is a traceable artifact that connects every identified threat to a specific mitigation control, a verification method, and pre- and post-mitigation risk scores. An FDA reviewer reading your submission’s cybersecurity section expects to follow a thread from each threat enumerated in the DFD analysis through to the control that addresses it and the testing evidence that verifies the control works.
A complete threat model report for a premarket submission includes six components: the system description with labeled DFDs and trust boundaries, the asset identification and classification, the threat enumeration with methodology justification, the risk scoring with clinical context using the MITRE rubric, the mitigation specification with verification evidence, and the residual risk acceptance rationale. eSTAR submissions have a specific cybersecurity section structure, and every element of the threat model output needs to map to it. Structure matters as much as analysis here.
This is also where Blue Goat Cyber earns its role in a device program. The firm builds exactly this output for manufacturers, running the full threat modeling exercise from initial system boundary sessions with engineering through final report delivery. The documentation is structured to match what FDA reviewers look for in premarket cybersecurity packages, not assembled generically and adapted after the fact. Teams that receive deficiency letters citing missing traceability or unexplained methodology choices typically produced threat models without that submission-specific structure. Getting the structure right the first time eliminates those letters. For organizations that prefer expert execution, Blue Goat Cyber offers end-to-end Medical Device Threat Modeling Services, Blue Goat Cyber that deliver submission-ready artifacts.
Conclusion: a defined process, not a blank page
How do you conduct a cybersecurity threat model for a connected or implantable medical device? You follow a defined, repeatable sequence. Define the system boundary, build data flow diagrams with labeled trust boundaries, identify critical assets across four categories, enumerate threats systematically with STRIDE, score with clinical context using the MITRE rubric, and produce a traceable report structured for your submission format. The same sequence holds whether you are modeling a networked infusion pump or an implantable cardiac device, the interfaces differ, but the discipline does not.
The FDA’s 2026 premarket cybersecurity guidance treats the threat model as evidence of a manufacturer’s cybersecurity posture, not a compliance checkbox. A well-built threat model created early in design becomes the foundation for every subsequent cybersecurity decision: penetration test scope, SBOM risk analysis, postmarket monitoring priorities, and deficiency responses if they arise. For teams that need this capability without building it internally, Blue Goat Cyber runs the full process and delivers submission-ready documentation built to survive review. Starting early is the clearest advantage you have.
Related: Medical Device Cybersecurity: A Complete Lifecycle Guide