Medical Device Threat Model Template: Worked Example for FDA Premarket Submissions

Talk to a MedTech cybersecurity expert

STRIDE and the six-artifact structure below are Blue Goat’s recommended template and methodology, not an FDA-mandated format. The FDA’s February 3, 2026 guidance recommends threat modeling without prescribing this template.

What FDA actually expects in a threat model

The February 2026 final premarket cybersecurity guidance and Section 524B of the FD&C Act both require manufacturers to identify cybersecurity risks across the total product lifecycle. Reviewers operationalize that requirement against AAMI TIR57 (security risk management) and ANSI/AAMI SW96 (security risk management for medical device software). The FDA cites both references; omission of a particular citation alone does not guarantee a deficiency. Document the methodology and its applicability.

The six required artifacts

1. Scope statement - device under analysis, intended use, intended users, operating environment, in-scope and out-of-scope components.
2. Asset inventory - data assets (PHI, telemetry, credentials), functional assets (therapy delivery, alarming, OTA update), and trust assets (signing keys, root of trust).
3. Architecture views - global system view, multi-patient harm view, updateability view, security use-case view. Each view shows trust boundaries explicitly.
4. Threat enumeration - STRIDE per element, with each threat tied to a specific component or trust boundary crossing.
5. Control catalog - one row per control, with type (preventive/detective/corrective), implementation reference, and verification evidence.
6. Traceability matrix - threat → control → verification → residual risk → ISO 14971 harm. This is what reviewers grade you on.

The four architecture views (and why each one is non-negotiable)

Global system view

Every component a packet can reach: device, mobile companion app, cloud backend, update server, hospital network, home network, third-party services, and admin tooling. Trust boundaries marked at every interface a different actor controls.

Multi-patient harm view

Where a single compromise affects more than one patient: shared cloud tenancy, fleet-wide OTA, central provisioning. This is the view reviewers ask about most often when the device sits behind a cloud.

Updateability view

The complete OTA path: code signing, update authentication, rollback protection, key management, and end-of-support behavior. Required to demonstrate ongoing patchability under Section 524B.

Security use-case view

How the device behaves under therapy delivery, alarming, programming, and standby states - and how attacker actions map to safety impact in each state. This is where ISO 14971 mapping lives.

Worked example: connected infusion pump

A simplified working example below. Use it as the skeleton and replace device-specific content.

Scope

• Device: Class II large-volume infusion pump with Wi-Fi connectivity to hospital EHR via HL7.
• In scope: pump firmware, Wi-Fi stack, HL7 interface, drug-library update path, biomed service interface.
• Out of scope: hospital EHR internals, hospital network controls (documented as assumptions).

Sample threat → control row

• Threat (Tampering): Attacker on hospital LAN modifies HL7 infusion order in transit.
• Control: TLS 1.3 with mutual authentication between pump and EHR gateway, certificate pinning, replay protection.
• Verification: Pen test report section 4.3 + unit test ITR-227.
• Residual risk: Low after control; documented in security risk file SRF-014.
• ISO 14971 harm: Wrong dose delivered → severe patient harm. Pre-control: high. Post-control: low.

Scoring the threats: exploitability, impact, and the risk matrix

The threat model tells the reviewer what can go wrong. The cybersecurity risk assessment tells them how bad it is and what you did about it. FDA guidance recommends a documented, repeatable scale rather than an engineer's gut call, and they expect it to be different from your safety risk scale under ISO 14971. Safety risk estimates probability of occurrence; cybersecurity risk estimates exploitability, because an attacker is a deliberate agent, not a random failure.

Publish both scales in the submission and apply them consistently.

Exploitability

Score the five CVSS v4.0 exploitability metrics and read the rating from the Exploitability field of FIRST's CVSS v4.0 calculator. Per Table 24 of the CVSS v4.0 Specification, it uses Attack Vector, Privileges Required, and User Interaction:

Security impact (every finding)

Take the highest of the six CVSS v4.0 impact ratings (confidentiality, integrity, and availability for the vulnerable and subsequent systems): High gives High, Low gives Medium, all None gives Low.

Severity of harm (findings that can reach a patient)

Use the manufacturer's own ISO 14971 hazard analysis: Negligible, Minor, Serious, Critical, or Catastrophic. A finding whose only effect is data disclosure, such as PHI, stays on the security matrix.

Two matrices, not a formula

The security matrix sets remediation priority. The safety matrix decides controlled or uncontrolled on the residual risk. Blue Goat Cyber's default line treats Low and Medium as controlled and High and Very High as uncontrolled, but the acceptance criteria belong to the manufacturer and are fixed in the security risk management plan before scoring. The matrix shape is Blue Goat Cyber's convention; the FDA does not prescribe one.

Where you want a numeric score in addition to the qualitative bands, use the MITRE Rubric for Applying CVSS to Medical Devices. It adapts CVSS base metrics to clinical context, which matters because raw CVSS consistently understates harm to a patient and overstates confidentiality loss. Never submit CVSS scores alone: pair every score with the ISO 14971 harm it maps to.

From threat model to vulnerability assessment and SBOM

The threat model and the vulnerability assessment are separate deliverables that share one spine. The threat model is design-driven and asks what an attacker could do to the architecture you built. The vulnerability assessment is component-driven and asks what is already known to be wrong with the parts you used.

The handoff works like this:

1. Freeze the SBOM against the same system boundary as the threat model. If the threat model covers the cloud back end and the companion app, the SBOM must too. A mismatch in boundary is a fast way to earn an Additional Information request.
2. Map each component to the DFD element it lives on. A CVE in a TLS library on the telemetry service is a different risk from the same CVE in a build-time tool that never ships.
3. Triage each known vulnerability for reachability, not just presence. Document whether the vulnerable code path is executed, exposed across a trust boundary, and reachable by any threat already enumerated in the model.
4. Publish the outcome as VEX statements. Affected, not affected, fixed, or under investigation, each with a justification the reviewer can check.
5. Score exploitable findings on the same matrix as the threat model so the security risk file has one consistent risk language.
6. Feed the residual items back into the threat model. A component vulnerability that is exploitable in your implementation is a new threat row with its own control, test, and harm mapping.

Devices with critical, exploitable components need deeper analysis and a documented patchability plan. For components you judge non-critical, write down the rationale - "not critical" without a justification is treated as an omission. AAMI TIR57 and the postmarket guidance both describe this loop, and the February 3, 2026 premarket guidance expects the resulting evidence in the submission.

Common deficiencies that get cited

• Trust boundaries differ between the global view and the architecture diagram in the design history file.
• STRIDE applied to the system as a whole rather than per element - reviewers cannot tell which component owns which threat.
• Controls listed without verification evidence - the traceability column is empty or points to documents not included in the submission.
• Multi-patient harm view missing entirely for cloud-connected devices.
• Safety impact stated qualitatively without ISO 14971 risk-file references.

Before a penetration test, our week 1 test readiness review checks your threat model against this same structure, plus your hazard analysis and eSTAR architecture diagram.

Frequently asked questions

Is STRIDE required, or are PASTA/LINDDUN acceptable?▾

STRIDE is the methodology FDA reviewers see most often and the one AAMI TIR57 references most directly, so it is the path of least friction. PASTA and LINDDUN can satisfy the guidance if applied rigorously and mapped to the same six artifacts above. The methodology matters less than the traceability and the architecture-led structure.

How many threats should a typical medical device threat model identify?▾

For a connected Class II device with cloud and mobile components, expect 80-200 distinct threats after deduplication. Fewer than 50 typically signals incomplete enumeration. More than 300 usually signals threats listed at the wrong abstraction level (instance threats instead of class threats).

Do I need a threat model for a 510(k) where my predicate had none?▾

Yes. Section 524B applies to any cyber device regardless of predicate. The 2026 final guidance is explicit that historical predicate practice does not exempt new submissions from current cybersecurity expectations.

How is this different from an IT threat model?▾

Three differences. First, every threat must trace to patient-safety harm under ISO 14971, not just CIA impact. Second, multi-patient harm and updateability are required architecture views. Third, the control catalog must include lifecycle controls (postmarket monitoring, coordinated vulnerability disclosure, end-of-support) - not just design-time controls.

How often must the threat model be updated postmarket?▾

On any architecture change, any new attack vector disclosed against your tech stack, any major SBOM component change, and at least annually as part of postmarket cybersecurity review. The update cadence belongs in your postmarket cybersecurity management plan.

Does my threat model need to cover the cloud backend even if it is hosted on AWS or Azure?▾

Yes. The shared-responsibility model does not transfer your obligation. AWS or Azure controls the substrate; you control your configuration, IAM, and application layer. FDA guidance recommends threat-model content for the application layer and for the configuration assumptions you depend on the hyperscaler to enforce.

Can a single threat model cover a device family?▾

Yes, with a documented variance analysis. The base model covers the common architecture, then variance sections call out where individual products diverge (different connectivity, different sensors, different intended use). Reviewers accept this approach when the variance analysis is explicit.

What tooling do you recommend?▾

Microsoft Threat Modeling Tool, IriusRisk, OWASP Threat Dragon, or a structured spreadsheet all work. Tooling does not move the needle on FDA acceptance - the artifacts and traceability do.

How long does it take to build one from scratch?▾

For a Class II connected device, 4-6 weeks elapsed with active engineering participation. The slow step is workshop scheduling, not the modeling itself.

What is the single fastest way to fail?▾

Hand the reviewer a STRIDE spreadsheet without architecture views. Architecture views are how reviewers orient themselves. Without them, every other artifact reads like noise.

Filling the template without producing a wish list

The most common failure with any threat model template is enumeration without discipline: a few hundred rows generated by applying every STRIDE category to every element, most of them implausible, none of them prioritized. Reviewers read that as effort, not analysis, and it makes the genuinely serious threats harder to see.

Three rules keep the model honest:

• Every threat needs a harm statement. Not "attacker gains access to the database" but "attacker modifies stored therapy parameters, causing the next scheduled delivery to exceed the prescribed dose." If you cannot write the harm, the row is an IT finding, not a device threat.
• Score against patient impact, not asset value. A denial of service on a therapy path outranks confidentiality loss on a log store, even when CVSS says the opposite. Document the scoring method so the inversion looks deliberate.
• Close every row. A threat with no mitigation and no accepted-risk justification is an open question a reviewer will ask on your behalf.

Traceability identifiers: the cheapest quality improvement

Assign each threat a stable identifier at creation (THR-014) and carry it into the risk assessment, the control list, the test plan, and the test report. It costs nothing during authoring and it is the single change that most reduces deficiency risk, because the reviewer's central question, "was this threat actually addressed," becomes a text search rather than an inference.

Keep the identifiers stable across revisions. Renumbering between rev B and rev C breaks every cross-reference in the package and, in a deficiency response, makes it impossible for a reviewer to see what changed.

Keeping the model current

A threat model is stale the moment the architecture moves, and reviewers notice when the submitted model describes an earlier design. Tie updates to specific triggers rather than a calendar: a new external interface or protocol, a change to the update or authentication mechanism, a new data type or trust boundary, a component with a materially different security posture, or a field incident that reveals an attack path the model did not anticipate.

Record the trigger and the resulting change in the model's revision history. That history is also what supports a predetermined change control plan, because it demonstrates that design changes route through security analysis rather than around it. For the full methodology behind this template, see the STRIDE threat modeling guide.

Where to go next

A template gets you a structure. It does not get you a threat model. The difference shows up the first time someone tries to fill in the harm column and discovers that nobody has agreed what counts as a clinical harm for this device.

Settle the harm taxonomy first, before a single threat is written. Define the small set of clinical harm categories that apply to your device, drawn from your existing ISO 14971 hazard analysis and expressed in the same language: delayed therapy, incorrect dose, loss of monitoring, unauthorized disclosure of PHI, and so on. Every threat in the model then terminates in one of those categories. Teams that skip this step produce models where the impact column says "confidentiality breach" for forty rows, which tells a reviewer nothing about patient safety and generates the request for more clinical linkage.

Next, build the data flow diagram to a consistent notation and freeze it before enumerating threats. Every element gets an identifier. Every trust boundary gets an identifier. Threat IDs then reference the boundary or element they belong to, which is what makes the model auditable. Without identifiers you cannot prove coverage, and coverage is exactly what a reviewer checks by sampling boundaries and looking for all six STRIDE categories against each one.

Then enumerate honestly and accept that some threats will have weak mitigations. A model where every threat is fully mitigated by an existing control is a model that was written to describe the design rather than test it. Residual risk entries are not admissions of failure. They are evidence that the analysis was real, and they belong in the security risk assessment with a documented acceptability rationale.

Finally, decide who updates the model and when. Tie it to your change control: any architecture change, new third-party component, new interface, or new deployment target triggers a review. A model frozen at submission becomes inaccurate within one release and is worthless during postmarket triage.

If you are starting this week, spend the first session on the harm taxonomy and the diagram identifiers. Everything else is faster once those two exist.

Starting early? See how Blue Goat supports threat modeling from the design phase: medical device cybersecurity consulting.

• Threat Modeling Service - we build the diagram, the harm taxonomy, and the full threat table as a fixed-fee engagement.
• Section 524B of the FD&C Act - the statutory basis that makes the threat model a submission requirement.
• FDA Cybersecurity Deficiency Response Playbook - what to do if a thin threat model has already cost you a deficiency letter.
• Threat Model Starter (STRIDE) - build a STRIDE threat model per DFD element and export it for the submission.