Medical Device Threat Model Template: FDA-Ready Worked Example

Talk to a MedTech cybersecurity expert

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.

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. Reviewers expect 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 scale

Patient and business impact scale

Risk calculation

Multiply or map the two scales into a matrix and pre-agree the acceptance thresholds, so the reviewer sees the decision rule and not just the outcome.

Anything landing in the unacceptable band must be mitigated before submission. High risks need a control plus verification evidence. Medium and low risks can be accepted, but only with a written rationale in the security risk file.

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?

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

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

How is this different from an IT threat model?

How often must the threat model be updated postmarket?

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

Can a single threat model cover a device family?

What tooling do you recommend?

How long does it take to build one from scratch?

What is the single fastest way to fail?

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.

• 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.