STRIDE Threat Modeling for Medical Devices: A Guide

The canonical STRIDE reference for MedTech: how each STRIDE category maps to medical device threats, how to build the data flow diagram FDA reviewers expect, and how STRIDE fits with AAMI TIR57, ISO 14971, and the FDA's threat-modeling expectations.

STRIDE is a taxonomy, not a threat model. This guide shows how to apply the STRIDE mnemonic to a medical device system, in enough depth that the output is FDA-submission-grade. For the broader catalog of common gaps reviewers cite (system boundaries, hostile-network assumptions, multi-patient harm), see 12 Critical Threat Modeling Gaps in Medical Device Submissions. This page focuses on STRIDE itself.

What STRIDE Is (and Isn't)

STRIDE was developed at Microsoft in the late 1990s as a way to categorize threats against software systems. It maps each threat to a violated security property:

Letter	Threat	Property violated
S	Spoofing	Authentication
T	Tampering	Integrity
R	Repudiation	Non-repudiation
I	Information disclosure	Confidentiality
D	Denial of service	Availability
E	Elevation of privilege	Authorization

STRIDE is not a risk-rating method (that's DREAD, CVSS, or your own scoring), it is not an attacker model (that's PASTA or LINDDUN), and it is not a substitute for a system threat model. STRIDE is the category lens you apply during element-by-element analysis of a data flow diagram.

STRIDE in the FDA Context

The FDA's 2026 premarket cybersecurity guidance does not mandate STRIDE by name — it allows any methodology that produces a defensible threat model. In practice, reviewers see STRIDE in roughly 70% of submissions, often combined with attack trees or kill-chain narratives for the most safety-critical paths. STRIDE is sufficient for FDA submissions when:

• It is applied to a complete system data flow diagram, not just the device
• Each STRIDE category is evaluated for every element and trust boundary
• Threats are linked to safety risk per ISO 14971 and AAMI TIR57
• Mitigations trace to verification evidence (pen test, code review, design controls)

When reviewers reject STRIDE-based threat models, the failure is almost never STRIDE itself — it is incomplete DFDs, missing hostile-network assumptions, or no link to safety risk.

STRIDE Categories Mapped to Medical Devices

S — Spoofing (Authentication)

Asset	Concrete spoofing scenario
Device-to-cloud channel	Rogue device registering with cloud using leaked provisioning key
Companion mobile app	Repackaged APK impersonating the legitimate app
Clinician programmer	Stolen service laptop authenticating as a privileged user
Cloud-to-device commands	Attacker forging server identity via DNS or TLS pinning bypass

Common controls: mutual TLS, device-unique certificates, per-device provisioning secrets, hardware-rooted identity (TPM, secure element), short-lived tokens for clinician sessions.

T — Tampering (Integrity)

Asset	Concrete tampering scenario
Firmware in transit	Attacker modifying OTA update payload
Firmware at rest	Physical attack on flash to write modified image
Telemetry in flight	MITM altering glucose readings before they reach the EHR
Configuration store	Modified therapy parameters via debug interface

Common controls: code signing with rollback protection, secure boot, signed configuration blobs, AEAD on telemetry, tamper-evident logging.

R — Repudiation (Non-repudiation)

Asset	Concrete repudiation scenario
Therapy delivery log	Clinician disputes that a dose was programmed
Audit trail	Attacker deletes evidence of a configuration change
Patient consent	App user denies acknowledging a critical alert

Common controls: signed and append-only audit logs, time-synchronized event records, server-side log replication, non-rejectable user acknowledgments.

I — Information Disclosure (Confidentiality)

Asset	Concrete disclosure scenario
PHI in transit	Unencrypted BLE characteristic exposing patient ID
PHI at rest	Mobile app caching identifiable data without encryption
Cryptographic material	Service password recoverable from firmware string dump
Multi-tenant cloud data	RLS bypass exposing one site's patients to another

Common controls: TLS 1.3, BLE LE Secure Connections, encryption of PHI at rest, per-tenant key isolation, strings-clean firmware images.

D — Denial of Service (Availability)

Asset	Concrete DoS scenario
Life-critical alarm	Bluetooth flooding that prevents pairing during an event
Cloud back-end	API rate-limit exhaustion taking down the fleet
Update server	Inability to push a security patch during an active campaign
Battery	Crafted traffic that wakes the radio continuously, draining the device

Common controls: local degradation modes that preserve safety, rate limiting at the device, multi-region cloud failover, energy budgets that cap radio time per hour.

E — Elevation of Privilege (Authorization)

Asset	Concrete EoP scenario
Service interface	Attacker reaches manufacturing-mode commands in production
Firmware update	Update mechanism abused to install attacker-chosen code
Cloud RBAC	A "viewer" role escalates to "fleet admin" via misconfigured API
Companion app	App-to-device protocol allows clinician-only commands from a patient role

Common controls: disable manufacturing interfaces in production firmware, role-based command filtering at the device, principle of least privilege on cloud roles, signed and bound update artifacts.

The 4-Step STRIDE Process for a Medical Device

Step 1 — Build the Data Flow Diagram

A reviewer-grade DFD includes:

• All external entities (patient, clinician, service tech, cloud back-end, EHR, manufacturing tooling, OTA update server)
• All processes running on the device, mobile app, and back-end
• All data stores (config, telemetry buffer, key store, server database)
• All data flows with protocols labeled (TLS, BLE-LESC, USB, cellular)
• All trust boundaries drawn explicitly — cross every flow that traverses one

Use a single legend across all diagrams in the submission. Number elements so STRIDE findings can reference them.

Step 2 — Apply STRIDE Element by Element

Element type	STRIDE letters to evaluate
External entity	S, R
Process	S, T, R, I, D, E
Data store	T, R, I, D
Data flow	T, I, D

This per-element table prevents the most common reviewer finding: "STRIDE applied at the system level, not the element level."

Step 3 — Score, Mitigate, and Trace to Safety Risk

For every threat, document:

• Pre-mitigation risk (likelihood × safety impact)
• Mitigation (control or design change)
• Residual risk
• Link to the ISO 14971 hazard and the AAMI TIR57 security risk file
• Link to the verification artifact that proves the mitigation works

Step 4 — Validate and Maintain

Threat models age. Reviewers expect:

• A change-trigger procedure (any architectural change re-opens the threat model)
• Updates after pen test findings
• A link to the postmarket vulnerability monitoring process

STRIDE vs. Other Methodologies

Method	Best for	Worst at
STRIDE	Element-by-element software analysis	Business-context risk, attacker motivation
PASTA	Attacker-centric scenarios across the org	Heavy process for a single device
LINDDUN	Privacy threats (GDPR, HIPAA framing)	Safety integrity properties
Attack trees	Walking a kill chain to a safety hazard	Coverage breadth
HAZOP / FMEA-Sec	Tying security to safety analyses	Software-only systems

For most FDA submissions, STRIDE for breadth + attack trees for the top 3–5 safety-critical paths is the strongest combination.

Common STRIDE Pitfalls in MedTech Submissions

1. System-level STRIDE only. Reviewers expect STRIDE per element, not "we considered STRIDE."
2. Missing data flows that cross the patient body. BLE channels are often omitted from the DFD.
3. Manufacturing and service interfaces excluded. STRIDE must cover provisioning, calibration, and decommissioning workflows.
4. R (Repudiation) treated as N/A. Almost no medical device is truly repudiation-free; clinicians, patients, and service techs all generate disputable events.
5. No link from STRIDE finding to ISO 14971 hazard. Reviewers will ask, "where does this threat appear in your safety risk file?"

For the wider catalog of submission-killing threat-model gaps, see 12 Critical Threat Modeling Gaps in Medical Device Submissions.

Frequently asked questions

Is STRIDE required by the FDA for medical device submissions?

No specific methodology is mandated. STRIDE is the most common in practice and is reviewer-familiar. Whatever you choose, it must cover the full system, link to safety risk, and trace to verification evidence.

How do you create a Data Flow Diagram (DFD) for a medical device?

Enumerate external entities, processes, data stores, and flows; label every flow's protocol; draw explicit trust boundaries; number every element so STRIDE findings can reference them. Include manufacturing, service, and update workflows — not just clinical use.

What is the difference between STRIDE and PASTA for MedTech?

STRIDE is a taxonomy applied per-element to a DFD. PASTA is a 7-stage attacker-centric process. STRIDE is faster and reviewer-familiar; PASTA is heavier but better when business and adversary context dominate the risk story. They are complementary.

How does STRIDE relate to ISO 14971 risk management?

STRIDE produces threats; ISO 14971 produces hazards. Each STRIDE-derived threat that can lead to patient harm becomes (or links to) an ISO 14971 hazard, with controls and residual risk evaluated under the safety risk file per AAMI TIR57.

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

Per-element analysis of every DFD node and flow, explicit hostile-network assumptions, multi-patient harm scenarios where applicable, mitigation traceability, and a residual-risk rationale tied to verification evidence.

Do I need to repeat STRIDE for every release?

Re-run STRIDE on any architectural change — new interface, new data flow, new third-party dependency, or a change in trust boundaries. Document the change-trigger criteria in your SPDF.

Where this fits in the cluster

• 12 Critical Threat Modeling Gaps in Medical Device Submissions
• The SPDF Playbook for FDA-Ready Medical Devices
• Security Risk Assessment per IEC 81001-5-1
• The MedTech Cybersecurity Standards Decoder

Related from Blue Goat Cyber

• Medical Device Threat Modeling Services
• FDA Premarket Cybersecurity Services
• Medical Device Penetration Testing
• Secure MedTech Product Design Consulting

Sources & primary references

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions — FDA
• Microsoft STRIDE Threat Model — Microsoft Learn
• AAMI TIR57: Principles for medical device security — Risk management — AAMI
• ISO 14971: Application of risk management to medical devices — ISO
• NIST SP 800-154: Guide to Data-Centric System Threat Modeling — NIST

Talk to a threat-modeling team

If you need a STRIDE-based threat model that survives FDA review on the first pass, we ship them as a deliverable inside our Threat Modeling Service. Book a discovery session.