FDA-Grade Medical Device Threat Model: Template & Worked Example

Pillar Guide · Updated 2026 · 18 min read

Talk to a MedTech cybersecurity expert

TL;DR

• FDA reviewers expect a threat model that is architecture-led, STRIDE-based, mapped to AAMI TIR57/SW96, and traceable to ISO 14971 patient-harm risk - not an IT checklist.
• A reviewer-ready threat model has six artifacts: scope statement, asset inventory, four architecture views, STRIDE threat enumeration, control catalog, and traceability matrix.
• The most common deficiency: trust boundaries are missing or inconsistent between architecture diagrams.
• Use the worked example below as your template and replace the device-specific content.

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). A threat model that ignores either standard will draw a deficiency, regardless of how thorough the IT-style analysis underneath it is.

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.

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.

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. Reviewers want to see 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.

Where to go next

• Threat Modeling Service - we build the artifacts above as a fixed-fee engagement.
• Section 524B of the FD&C Act - the statutory basis.
• FDA Cybersecurity Deficiency Response Playbook - what to do if a thin threat model has already cost you a deficiency letter.