Threat Modeling Connected & Implantable Devices

Reviewed September 17, 2026

A vulnerability in a hospital billing system leads to a data breach and a regulatory fine. The same class of vulnerability in an implantable cardiac device's telemetry link can let an attacker alter therapy delivery. Medical device threat modeling exists to catch that second category before it ships, and the FDA now expects to see the work, not just the conclusion.

Manufacturers that treat threat modeling as a paperwork exercise tend to submit models with partial STRIDE coverage, missing trust boundaries, and no link between a threat and an actual mitigation. Those gaps show up as Major deficiencies during premarket review, often adding months to a submission cycle. This guide walks through the practical steps: scoping, diagramming, applying STRIDE, rating harm with ISO 14971, deriving requirements, and building the traceability a reviewer expects to see.

Why This Matters

The FDA's premarket cybersecurity guidance, finalized February 3, 2026, applies to any cyber device under Section 524B of the FD&C Act and makes threat modeling a required design control input rather than an optional supporting document. Reviewers now ask for the model itself, along with evidence that it informed architecture and mitigation decisions during development, not just a summary table added before submission.

For connected and implantable devices, the stakes are different from a typical enterprise application. A missed threat on a hospital scheduling system causes an operational headache. A missed threat on an insulin pump's wireless command interface or a neurostimulator's programming link can translate directly into patient harm, which is why ISO 14971 risk management sits alongside the security analysis rather than behind it.

Manufacturers that start threat modeling early, at architecture definition, generally produce cleaner submissions because the model shapes design decisions instead of documenting them retroactively. Those that wait until the submission deadline tend to discover trust boundaries they never analyzed, third-party components with no documented threat coverage, and mitigations that were never verified with a test. Both AAMI TIR57 and ANSI/AAMI SW96:2023 give manufacturers a recognized structure for connecting the threat model to the risk management file the FDA expects to review. Building the model early, keeping it under version control, and updating it with every architecture or firmware change is the difference between a threat model that supports a submission and one that becomes the reason for a deficiency letter.

How Do You Scope a Threat Model for a Connected Medical Device?

Scoping starts with defining every component that touches the device, not just the device itself. A connected or implantable device threat model has to include the implant or wearable, any external programmer or reader, a companion mobile app, cloud services, hospital network infrastructure, and any third-party components embedded in the software.

Teams that scope only the device firmware routinely miss the mobile app's authentication logic or the cloud API that pairs a patient's implant to their clinician's dashboard. Both are common attacker entry points precisely because they are outside the device boundary that engineering teams instinctively focus on.

[KEY REQUIREMENT] The scope statement in your threat model documentation must list every component, every interface, and every third-party library or platform involved in the system, with a rationale for anything explicitly excluded.

Scoping also means defining assets: patient safety functions, protected health information, therapy delivery commands, firmware update mechanisms, and any cryptographic keys or credentials. Each asset becomes an anchor point for the STRIDE analysis in the next step.

How Do You Build a Data Flow Diagram With Trust Boundaries?

A data flow diagram maps how information moves between components, and trust boundaries mark every point where that data crosses into a domain with a different level of trust. For a connected implantable, that typically includes the implant-to-programmer wireless link, the programmer-to-cloud connection, the mobile app-to-cloud API, and the cloud-to-clinician-portal boundary.

Each boundary needs to be drawn explicitly, not implied. Reviewers checking a submission's threat model look for a diagram where every arrow crossing a boundary line has a corresponding STRIDE entry; a diagram without visible trust boundaries is one of the more common reasons a threat model gets flagged as incomplete.

How Do You Apply STRIDE to a Medical Device System?

STRIDE works by walking every trust boundary and asking whether each of six threat categories, spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, applies to that crossing. The output is a threat register, not a narrative document, with one row per identified threat.

Applying STRIDE consistently across a system with an implant, a programmer, and a mobile app means repeating the six categories at every boundary rather than applying them once to the system as a whole. Skipping categories at any boundary, even ones that seem low risk, is the fastest way to leave a gap a reviewer will find.

[KEY REQUIREMENT] Every trust boundary in the data flow diagram must have all six STRIDE categories evaluated and documented, even where the conclusion is "not applicable," with a stated reason.

For related coverage of alternative threat modeling methods and how they compare, see Comparing DREAD, STRIDE, and PASTA Threat Models and FMEA vs Threat Modeling for Medical Devices.

Why Rate Risk Against Patient Harm Instead of CVSS Alone?

CVSS scores technical severity, but it was built for general IT systems and does not account for clinical consequence, so a medical device threat model needs an ISO 14971-based harm rating layered on top of it. A vulnerability with a moderate CVSS score can carry a severe harm rating if it affects therapy delivery, while a high CVSS score on a component with no patient safety impact may warrant a lower priority.

ISO 14971 asks two questions for every identified threat: what is the severity of harm if this is exploited, and what is the probability of that harm occurring. Multiplying or combining those two factors, per your risk matrix, produces the risk level that actually drives mitigation priority, and AAMI TIR57 and ANSI/AAMI SW96:2023 describe how to connect that scoring back to the security risk assessment the FDA reviews.

See also: TARA Threat Analysis and Risk Assessment, Data Flow Diagrams for Medical Device Security, and Brainjacking: The Real Cyber-Physical Threat to NeuroTech.

How Do You Derive Security Requirements and Build Traceability?

Every threat in the register needs to produce at least one security requirement, and every requirement needs a mitigation and a verification test, forming a chain a reviewer can follow from threat to test result. Without that chain, a reviewer cannot confirm that an identified risk was actually addressed rather than just documented.

A traceability matrix is the standard way to show this: columns for threat ID, STRIDE category, harm rating, security requirement, implemented control, and verification test result. Manufacturers that maintain this matrix as a living document, updated whenever architecture or firmware changes, avoid the scramble of reconstructing traceability right before submission.

[KEY REQUIREMENT] Every entry in the threat register must trace forward to a documented security requirement and a verification test result before the threat model is considered submission-ready.

What Does the FDA Expect to See in the Submission?

The FDA expects a threat model that reads as a design artifact, complete with a documented scope, a data flow diagram with trust boundaries, full STRIDE coverage, harm-based risk ratings, and a traceability matrix connecting threats to mitigations and tests. The February 3, 2026 premarket cybersecurity guidance describes this as an expected component of the cybersecurity documentation accompanying a 510(k), De Novo, or PMA submission.

Reviewers also look for evidence that the model was maintained through development rather than created once at the end. A version history showing updates tied to architecture changes, added third-party components, or new interfaces demonstrates that the threat model actually functioned as a design input.

A Worked Example: Implantable Device With Clinician Programmer and Mobile App

Consider an illustrative, generic implantable neurostimulator system with three components: the implant itself, a clinician programmer used during in-office visits, and a patient-facing mobile app that adjusts therapy within physician-set limits. This example is not based on any real product or customer; it is meant to show the process end to end.

Scoping identifies the implant, programmer, mobile app, a cloud backend that syncs settings, and the wireless links connecting each. The data flow diagram places trust boundaries at the implant-to-programmer link, the programmer-to-cloud connection, and the mobile app-to-cloud API. Applying STRIDE at the implant-to-programmer boundary surfaces a spoofing threat, an unauthorized programmer could attempt to pair with the implant, rated as high harm under ISO 14971 because a successful pairing could allow unauthorized therapy changes.

That threat drives a security requirement for mutual, cryptographic device authentication before any programming session, a mitigation implemented in the pairing protocol, and a verification test confirming that a programmer without valid credentials cannot establish a session. The same pattern repeats at each boundary: a spoofing threat at the mobile app login surfaces a requirement for multi-factor authentication, and a tampering threat on the cloud sync surfaces a requirement for signed configuration payloads. The resulting traceability matrix, in this illustrative case, would show three boundaries, roughly a dozen STRIDE entries, and a requirement, mitigation, and test for each one flagged above the acceptable risk threshold.

How Blue Goat Cyber Approaches This

Blue Goat Cyber builds threat models for connected and implantable device manufacturers that are structured for FDA review from the start: scoped data flow diagrams, full STRIDE coverage at every trust boundary, ISO 14971 harm ratings, and a traceability matrix linking threats to requirements and verification tests. The work is done alongside engineering teams during architecture definition, not retrofitted before a submission deadline. For manufacturers looking for this as an ongoing service rather than a one-time deliverable, see Threat Modeling Services, which covers initial modeling, updates through the design lifecycle, and submission-ready documentation packages.

Frequently Asked Questions

Is STRIDE required by the FDA?

The FDA does not mandate STRIDE by name, but its premarket cybersecurity guidance expects a structured threat categorization method, and STRIDE is the most commonly used and recognized approach in medical device submissions. Whatever method a manufacturer chooses, it needs to demonstrate coverage of every trust boundary and trace each threat to a mitigation.

How is medical device threat modeling different from IT threat modeling?

The core method, scoping, diagramming, and categorizing threats, is similar, but medical device threat modeling adds an ISO 14971 harm rating layer tied to patient safety outcomes. IT threat modeling typically stops at technical impact, while medical device work has to connect each threat to a clinical consequence.

When should threat modeling start in the development lifecycle?

Threat modeling should start at architecture definition, before major design decisions are locked in, so the model can actually influence choices about authentication, encryption, and interface design. Starting it just before submission usually means findings arrive too late to fix without a redesign.

How often does a threat model need to be updated?

A threat model needs to be updated whenever the architecture changes, a new interface or third-party component is added, or firmware is significantly revised. Treating it as a version-controlled living document, rather than a static file, keeps it aligned with what reviewers expect to see reflected in the current design.

Does a low-risk device still need a full threat model?

Yes, though the depth of analysis can scale with the device's risk classification and connectivity. Even a device with limited connectivity still needs a documented scope, trust boundary analysis, and a rationale for why certain STRIDE categories were deemed low risk or not applicable.

Related Reading

• STRIDE threat modeling for medical devices: the pillar guide behind this walkthrough.
• Comparing DREAD, STRIDE, and PASTA threat models: how the common methodologies differ in practice.
• Threat trees vs attack trees in FDA submissions: when each diagram earns its place in the documentation.

CTA

If your team needs a threat model built to support an upcoming premarket submission or to close a cybersecurity deficiency, talk to Blue Goat Cyber about scoping the work, from data flow diagrams through traceability documentation.

Christian Espinosa is the founder of Blue Goat Cyber and writes on medical device cybersecurity, threat modeling, and FDA premarket strategy. Read more from him at his author page.