STRIDE Threat Modeling for Medical Devices

This guide covers how we build threat models that survive FDA review. It assumes you are preparing a 510(k), De Novo, or PMA for a cyber device under Section 524B and need a threat model that a reviewer can follow from system decomposition through residual risk.

Why the threat model is the load-bearing submission document

Almost every other cybersecurity deliverable in a premarket submission depends on the threat model. The security risk assessment scores what the threat model enumerated. Penetration test scope is derived from the threats you claimed were mitigated. The security architecture views illustrate the boundaries the threat model reasoned about. Your controls exist because a threat justified them.

That is why a weak threat model does not produce one deficiency. It produces a cascade of them, and reviewers phrase them that way: "the submitted threat model does not support the risk determinations in the security risk assessment."

What the FDA says about threat modeling methodology

The February 3, 2026 premarket cybersecurity guidance does not name a required methodology. It requires that threat modeling be performed throughout the design process, that it cover the device, its interfaces, and the broader system it operates in, and that it inform the security risk assessment.

In practice, three things follow:

1. STRIDE is the safe default. AAMI TIR97 and the MITRE / MDIC Medical Device Threat Modeling Playbook both work through STRIDE-style analysis. Reviewers recognize it, so you spend your response budget on findings rather than on defending your method.
2. Any rigorous method is acceptable if it is complete. PASTA, attack trees, and kill-chain analysis have all been accepted. What gets rejected is an unstructured narrative that cannot be shown to be exhaustive.
3. Completeness is judged per element. Reviewers check whether every element in your decomposition was analyzed against every applicable threat category. Gaps are visible immediately.

The four STRIDE steps, in the order reviewers expect

Step 1: Decompose the system to DFD level 3

Level 0 is a context diagram and is not sufficient. Level 1 is a marketing diagram. Level 3 is where threats live, because only at level 3 do you name individual processes, data stores, and flows that can each carry a threat.

Every DFD3 must label five element types:

• External entities (clinician workstation, patient mobile app, cloud tenant, service laptop, hospital EHR)
• Processes (firmware bootloader, BLE stack, telemetry service, update agent, web UI)
• Data stores (device configuration, patient log, key store, audit log, firmware partition)
• Data flows (each one annotated with protocol, direction, authentication state, and encryption state)
• Trust boundaries (drawn wherever privilege, physical control, or network ownership changes)

If a flow crosses a trust boundary and you cannot state its protocol and authentication state, you are not at level 3 yet.

Step 2: Apply STRIDE per element

Do not apply STRIDE to "the device." Apply it to each element, then record the result, including deliberate non-applicability. The mapping that matters in MedTech:

Two categories carry disproportionate weight for the FDA. Denial of service matters because unavailability of a therapy or monitoring function is direct patient harm, not an inconvenience. Tampering matters because integrity loss on a therapy parameter can injure a patient without any data ever being stolen.

Step 3: Score for patient harm, not IT impact

Score each threat on two axes and keep them separate:

• Exploitability: attacker position required, skill, tooling, physical access, time window.
• Patient safety impact: what happens to the patient if the threat is realized, expressed in the same harm language your ISO 14971 risk file already uses.

CVSS alone is not sufficient and the FDA has said so in review correspondence. A CVSS 4.3 issue that stops an infusion pump outranks a CVSS 9.8 issue that leaks a device serial number. Use CVSS if you like, then apply a documented harm adjustment and show your rationale. ISO 14971 risk acceptability criteria govern the final call, per ANSI/AAMI SW96.

Step 4: Close the loop with traceability

Every threat needs an outcome: mitigated, transferred to the operator through labeling, or accepted with a written justification. Every mitigation needs verification evidence. Every accepted residual risk needs a benefit-risk statement.

The audit thread a reviewer expects to follow is: DFD element → threat ID → risk score → control → verification test → residual risk → postmarket monitoring item. If any link is missing, the submission has a hole.

The 8-column STRIDE threat table

This is the deliverable. Ship it as a table, not prose.

A real model for a moderately connected Class II device typically lands between 80 and 300 rows. Under 40 rows on a connected device usually means the decomposition stopped at level 1.

CIA attack trees, and where they fit

STRIDE tells you what can go wrong per element. Attack trees tell you how an attacker chains several of those into an outcome that matters. Build three, rooted at loss of confidentiality, loss of integrity, and loss of availability of the device's essential performance, then link each leaf to a threat ID in the table.

This is what turns a list into an argument. It also shows reviewers you considered multi-step attacks rather than isolated defects.

Threat model vs. security architecture views

These are different eSTAR attachments and conflating them is a recurring deficiency.

• The threat model is the analysis: decomposition, enumerated threats, risk, controls, residual risk.
• The security architecture views are the illustrations the guidance calls for: global system view, multi-patient harm view, updateability and patchability view, and security use case views.

Diagrams submitted in place of an analysis get rejected. Our threat modeling services page covers the model itself; the views are delivered under FDA premarket cybersecurity.

Common STRIDE threat modeling pitfalls in submissions

• Stopping at DFD1. No element-level granularity means no element-level threats.
• Skipping categories silently. If repudiation does not apply to a data store, write that down. Silence reads as an omission.
• Ignoring the service and manufacturing paths. Service laptops, JTAG headers, and factory provisioning are in scope and are frequently the softest targets.
• Excluding the cloud and mobile app. If they are part of the device system, they are part of the model.
• CVSS-only scoring. Reviewers ask for the harm rationale nearly every time.
• A threat model that ends at submission. It is a living artifact under design control and must be revisited on architecture changes and postmarket findings.
• No traceability IDs. Without stable IDs, no one can verify the model matches the risk file.

Integrating STRIDE with ANSI/AAMI SW96 and ISO 14971

ANSI/AAMI SW96:2023 is the security risk management standard that sits alongside ISO 14971. The practical division of labor:

• STRIDE produces the threat inventory.
• SW96 provides the security risk management process that scores and dispositions those threats.
• ISO 14971 owns the patient-harm framing and the benefit-risk determination.

Keep security risk in its own file with its own scoring, then feed anything with a safety consequence into the ISO 14971 risk file so the benefit-risk analysis is complete. Reviewers look for that handoff explicitly.

Worked STRIDE example: insulin pump, phone app, and cloud

Method descriptions do not teach the judgment part. Here is a condensed version of the analysis for a common architecture: a wearable pump, a BLE-paired patient phone app, and a cloud tenant that stores therapy history and pushes firmware.

Decomposition (DFD3 fragments). External entities: patient, caregiver, clinician portal user, service technician, cloud tenant. Processes: pump control loop, BLE peripheral stack, bolus command handler, update agent, phone app pairing service, cloud ingest API. Data stores: therapy configuration in flash, event log, key store in secure element, staged firmware slot. Flows: BLE GATT bolus command (encrypted, authenticated after pairing), BLE telemetry push (encrypted), phone-to-cloud HTTPS with OAuth bearer token, cloud-to-pump firmware manifest fetch through the phone, service UART on the pump housing (unauthenticated, physically shrouded). Trust boundaries: pump housing, BLE radio link, phone process sandbox, internet edge, cloud tenant isolation.

Six representative rows from the resulting table, abbreviated to the columns that carry the argument:

Note what the scoring does here. T-033 is a plain denial of service with a modest CVSS score, and it outranks T-061, which would score far higher in an IT context. That inversion is the clearest signal to a reviewer that the model was built for a medical device rather than lifted from an enterprise template.

Note also T-052. It is the only row with fleet-wide scope, which is exactly what the multi-patient harm architecture view exists to illustrate. Threats with fleet-wide reach should be traceable into that view by ID.

Sizing a threat model: effort and who is in the room

For a connected Class II device, expect roughly:

• Decomposition: two to four working sessions of about three hours, to reach a DFD3 everyone agrees describes the real system rather than the intended one.
• STRIDE enumeration: one to two weeks of analyst time, per element against all six categories, including recording deliberate non-applicability.
• Scoring and control mapping: about a week, with the systems engineer present for the patient-impact column.
• Attack trees and write-up: three to five days.

The room must include someone who can say what the device does to the patient when a given function fails. A security analyst working alone produces a defensible IT threat model and an indefensible safety argument. The reverse is equally true, which is why this is a joint artifact.

Keeping the threat model current through design change

A threat model dated eighteen months before submission, describing an architecture that has since gained a cloud service, invites the reviewer to distrust everything downstream of it. Make it a controlled document with revision history, and tie updates to explicit triggers:

• Any new external interface, protocol, or trust boundary.
• Any change to authentication, cryptography, key management, or the update path.
• Any new data store holding PHI or therapy parameters.
• Any postmarket vulnerability whose root cause reveals a threat the model missed. This trigger matters most, because a model never updated after a real finding is provably incomplete.
• Any change executed under a PCCP, so the model and the change plan stay aligned.

Record who reviewed each revision and when. That revision history is the evidence that threat modeling happened throughout the design process, which is what the guidance actually asks for, rather than once at the end.

How Blue Goat Cyber builds threat models

We build the model as a regulated engineering artifact, not a workshop output. Engagements run: architecture intake and interface inventory, DFD3 construction reviewed with your engineers, STRIDE per element, CIA attack trees, the 8-column table with traceability IDs, and a walkthrough with your regulatory lead so your team can defend every row in a deficiency response.

Everything is versioned so it can be updated on the next design change instead of rebuilt.

Where this fits in the cluster

• FDA Section 524B Requirements Explained
• FDA Premarket Cybersecurity Submission Checklist
• Security Risk Assessment and IEC 81001-5-1
• ISO 14971 vs. AAMI Hazard Analysis
• FDA Medical Device Threat Model Template - a submission-ready table structure for your STRIDE output.

Related from Blue Goat Cyber

• Threat Modeling Services
• FDA Premarket Cybersecurity Services
• Medical Device Penetration Testing
• FDA Cybersecurity Deficiency Response

FAQ

Is STRIDE required by the FDA for medical device submissions?

No. The February 3, 2026 guidance requires threat modeling but does not mandate a methodology. STRIDE is the de facto expectation because AAMI TIR97 and the MITRE / MDIC playbook are built around it, and reviewers rarely question it. Choosing something else is allowed, but you will spend review cycles justifying the method instead of discussing findings.

How do you create a data flow diagram for a medical device?

Start from the context view, then expand until every process, data store, and flow is individually named, which is typically level 3. Annotate each flow with protocol, direction, authentication, and encryption state, and draw trust boundaries wherever privilege, ownership, or physical control changes. Include the service laptop, the mobile app, the cloud tenant, and the manufacturing provisioning path.

What is the difference between STRIDE and PASTA for MedTech?

STRIDE is a per-element enumeration method: fast, exhaustive, and easy to audit for coverage. PASTA is a seven-stage, business-risk-driven process that starts from attacker objectives. PASTA produces richer attack narratives but is far heavier and harder to prove complete. Most medical device submissions use STRIDE for coverage and add attack trees for the narrative depth PASTA would have provided.

How does threat modeling relate to ISO 14971 risk management?

The threat model identifies security threats and their exploitability. ISO 14971 owns the patient-harm side: severity, probability of harm, risk acceptability, and benefit-risk. ANSI/AAMI SW96 bridges them. Any security threat with a safety consequence must appear in the ISO 14971 risk file, and reviewers check for that linkage.

What level of detail does the FDA expect in a threat model?

Enough that a reviewer can independently confirm coverage. Practically: DFD3 decomposition, every element analyzed against all six STRIDE categories with non-applicability documented, patient-harm-aware scoring, a named control and verification test per threat, and residual risk with disposition. A connected Class II device usually produces 80 to 300 threat rows.

Sources & primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• Playbook for Threat Modeling Medical Devices (MITRE / MDIC)
• ISO 14971:2019 Application of risk management to medical devices
• ANSI/AAMI SW96:2023 Standard for medical device security
• Section 524B of the FD&C Act