STRIDE for Medical Devices: A Complete Threat Modeling Framework

When it comes to medical device cybersecurity, knowing where threats might come from is half the battle. That's the beauty of STRIDE, a threat modeling method that can give you a heads up on six types of security threats:

• Spoofing
• Tampering
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

Besides the callout on threat types, STRIDE also hits its stride in helping to uncover potential security weaknesses. A STRIDE threat modeling workshop puts this play into action by using a data flow diagram to examine individual parts of a medical device system.

These findings then feed into the cybersecurity risk assessment described in Section V.A of FDA's February 2026 premarket cybersecurity guidance.

STRIDE is valuable in your FDA reviewer journey. So is this article. Think of it as your practical companion to our STRIDE threat modeling guide. While the guide explains the methodology, relevant standards, and a worked example, we'll focus on putting STRIDE into practice. Here's where you can learn how to run sessions, what questions to ask, and especially important, what documentation your team should walk away with when it's finished.

What STRIDE is for, and what it isn't

STRIDE is useful for answering one important question in medical device threat modeling: What can go wrong?

That's a big question, but STRIDE doesn't provide all the answers. It won't tell you which parts of the system to examine, how serious a threat might be, or what steps to take to address it.

Even the MITRE and MDIC Playbook for Threat Modeling Medical Devices cautions that STRIDE isn't a magic solution for identifying every possible threat.

What it does provide is structure. Without it, a discussion can easily get stuck on the same handful of cybersecurity threats everyone already knows about. STRIDE encourages teams to look beyond those familiar concerns and consider vulnerabilities they might otherwise overlook.

There's also an important FDA connection.

Section V.A.1 of FDA's premarket cybersecurity guidance recommends threat modeling throughout the design process, covering all elements of the medical device system. Manufacturers also need to explain why they selected their particular threat modeling methodology.

FDA doesn't require STRIDE specifically. However, applying STRIDE per element to a data flow diagram gives manufacturers a practical way to document their approach.

It also helps that STRIDE is covered in the MITRE and MDIC playbook cited by FDA. Teams can show which threats they considered, where they looked for them, and how they arrived at their findings.

Before the session

Trying to run a STRIDE session without a diagram is a little like trying to navigate an unfamiliar city without a map (or WAZE). You might get somewhere, but you'll probably miss a few important turns.

A productive threat modeling workshop starts with preparation. Here's what your team should have ready:

• A data flow diagram with trust boundaries. This is your roadmap. It should identify external entities, processes, data store, data flows, and trust boundaries marked with closed, dashed shapes. See our guide on how to create data flow diagrams for medical devices.
• A list of assumptions. What are you assuming about the network, users, smartphones, and cloud providers? For example, FDA's guidance describes a scenario in which an attacker controls the hospital network and can easily modify, drop, or replay data packets. Your team needs to know which assumptions apply to the system you're evaluating.
• Existing and planned security controls. What protections are already in place, and where could they fail? The MITRE and MDIC playbook recommends considering threats even when security controls exist. In other words, don't assume a threat disappears just because you've planned a safeguard.
• The right people in the room. Include a firmware engineer, someone familiar with the app and cloud environment, and a systems or risk engineer who understands how the device is used clinically. You'll also need someone to document the threats as they're identified. Plan on roughly two hours for each major trust boundary.

The better prepared your team is, the less time you'll spend figuring out how the system works and the more time you'll have to examine what could go wrong.

The six questions, phrased for a device

Most generic STRIDE training materials use examples involving websites, corporate networks, or enterprise software.

Those examples can be useful, but medical devices introduce different concerns. A compromised account might expose patient information. A malicious firmware change could affect therapy delivery. A disrupted connection might interfere with patient monitoring.

That's why it helps to frame each STRIDE category around the device itself.

The following table shows the six threat categories, questions to ask about each system element, examples of what could go wrong, and the FDA security control categories that typically address those threats.

STRIDE type	The question to ask of each element	Device examples	Controls that usually answer it
Spoofing	Could something impersonate this entity and fool the system into accepting it?	A rogue phone pairs as the companion app; a replayed token sends a command; a fake update server	Authentication; Cryptography
Tampering	Could someone change data, code, or settings without the system detecting it?	Firmware altered during transmission; a therapy limit changed in flash memory; a reading modified between the sensor and display	Code, Data, and Execution Integrity; Firmware and Software Updates
Repudiation	Could someone deny taking an action, leaving us unable to prove what happened?	A technician denies changing a setting; an alarm acknowledgment can't be traced to a user; a therapy record is disputed	Event Detection and Logging
Information disclosure	Could someone access information they shouldn't be able to see?	Patient readings exposed through an unpaired Bluetooth connection; credentials stored in a debug log; patient information exposed in a backup	Confidentiality; Cryptography; Authorization
Denial of service	What could prevent this part of the system from working, and how might that affect the patient?	Excessive pairing requests; a software crash that interrupts monitoring; battery drain caused by radio abuse	Resiliency and Recovery; Code, Data, and Execution Integrity
Elevation of privilege	Could someone gain access to functions or information beyond what their role permits?	A patient account accesses another patient's records; maintenance mode opens without authentication; a debug port provides root access	Authorization; Authentication

There are also two practical rules from the MITRE and MDIC playbook worth remembering.

First, assign each threat to the element it affects. For example, someone might tamper with data traveling between two components, while a separate spoofing threat could involve impersonating the process receiving that data. Keeping those distinctions clear makes your threat model easier to follow.

Second, don't get bogged down debating categories. Some threats fit more than one STRIDE category. That's fine. Choose the best fit, note the other possibility, and keep going.

After all, the purpose of STRIDE threat modeling isn't to win an argument over terminology. It's to identify and document potential threats before they become real problems.

Running the session

A successful threat modeling workshop needs some structure. Otherwise, it's easy to spend too much time discussing one vulnerability while overlooking others.

The best approach is to work through your data flow diagram in a consistent order. Here's how:

1. Start with the flows that cross a trust boundary. Medical device systems can have hundreds of elements, as the MITRE and MDIC playbook points out. That's a lot of ground to cover. Start where data crosses trust boundaries, since these are important places to look for potential attacks. Once you've examined those connections, work your way inward if time allows.
2. For each element, ask only the applicable STRIDE questions. Not every question applies to every component. Under the STRIDE per element approach described in our guide, external entities have two applicable questions, processes have six, and data flows and stores have three each. Work through them systematically. Even when you don't identify a threat, document that finding and explain why.
3. Describe each threat in a complete sentence. Be specific about who is doing what, which asset is affected, and how the attack could happen. For example: "An attacker on the hospital network replays a captured configuration command to the device over Wi-Fi." That's much more useful than simply writing "replay attack" in your threat table.
4. Give each threat a permanent ID. Think of these IDs as reference numbers that follow each threat throughout the cybersecurity process. They connect threats to risk scores, security requirements, tests, and architecture views. Don't worry if the numbers aren't consecutive. And if a threat is retired, keep its original ID so the documentation remains traceable.
5. Identify existing safeguards and consider how they might fail. Just because a security control is in place doesn't mean the threat has disappeared. For example, Transport Layer Security (TLS) helps protect information in transit. But what happens if certificate validation was disabled in a debug build? That's the kind of weakness your team needs to consider.
6. Make sure every applicable question has been addressed. Your team can wrap up this stage of STRIDE threat modeling once every applicable question has either an identified threat or a documented explanation of why no threat was found. At that point, you've completed the structured threat-identification exercise and can move on to evaluating the risks.

The category teams skip

Repudiation tends to get overlooked during threat modeling sessions. Why? Often, it's because teams have a hard time picturing what this type of threat actually looks like.

The MITRE and MDIC playbook offers a useful way to think about it. Look for actions where manipulating or disputing what happened could have legal or financial consequences.

For medical devices, that might involve therapy delivery records, alarm acknowledgments, service changes, or a patient's consent to share information.

Here's an important distinction: Repudiation isn't the same as spoofing.

Spoofing involves pretending to be someone or something else. Repudiation concerns whether an action can be reliably attributed to the person or system responsible for it. In fact, the person disputing an action might be a legitimate, authorized user.

One way to address this threat is through tamper-evident event logs that identify users and rely on trustworthy timestamps. These safeguards align with the Event Detection and Logging category in Appendix 1 of FDA's guidance.

Denial of service deserves just as much attention.

It's easy to think of denial of service as an IT problem. A server goes down, an application stops responding, or a network connection becomes unavailable.

But consider what happens when the affected system is a medical device.

Could a disruption interrupt therapy? Could it prevent clinicians from monitoring a patient? Could the failure of one cloud service affect hundreds of connected devices?

Those are the questions that matter in medical device threat modeling.

FDA's Multi-Patient Harm View, described in Section V.B.2, helps manufacturers examine how a cybersecurity problem affecting shared infrastructure could put multiple patients at risk.

The lesson here is straightforward. Don't stop at asking whether a system could fail. Ask what that failure could mean for the people depending on it.

What you leave the room with

Once your STRIDE session wraps up, you should have more than a collection of ideas about potential cyberattacks.

You need a threat table that documents what your team found and provides a starting point for the next steps in your cybersecurity risk assessment.

Each entry should include a threat ID, the affected system element and trust boundary, the STRIDE category, a description of the threat, and any assumptions behind it. Leave room for the risk score, too.

That score comes later.

Section V.A.2 of FDA's premarket cybersecurity guidance calls for evaluating cybersecurity risks using exploitability rather than the probability of a threat occurring. Steps 3 and 4 of our guide explain the full set of table columns and scoring options, including CVSS and the MITRE rubric.

But the threat table isn't something you create, file away, and forget.

It's an important part of your FDA threat model documentation because the findings help support three areas reviewers will examine:

• The cybersecurity risk assessment. This connects the threats you've identified with their associated risks and security controls. Our FDA cybersecurity traceability matrix article explains how to connect each threat to its corresponding test.
• The security architecture views. These show where security controls fit into the system and how they address identified threats. Threat IDs help reviewers follow those connections. Learn more in security architecture as the foundation of your device.
• The controls and their tests. Identifying a threat is only part of the job. You also need to demonstrate how your security measures address it. Our article on how to implement cybersecurity controls covers this process. You'll also want to consider the update process described in secure software updates and patch management.

Ultimately, the goal is to create a clear record of what your team examined, what threats it identified, and how those findings influenced the device's security design.

For more on organizing that information for regulatory review, see our book section on threat model documentation for eSTAR submission.

Common mistakes

Even experienced teams can stumble when using STRIDE for medical devices. Sometimes it's a matter of missing an important system component. Other times, it's assuming the job is finished when there's still more work to do.

Here are five mistakes worth avoiding:

• Running STRIDE on a block diagram. A block diagram might show the major parts of a system, but it won't necessarily show how data moves between them or where trust boundaries exist. Without that information, it's difficult to apply STRIDE per element. Start with a data flow diagram (DFD) instead.
• Skipping elements you don't own. Just because your company doesn't control the app store, cloud provider, or hospital network doesn't mean you can ignore them. These external entities still belong in your diagram, and you still need to consider spoofing and repudiation threats associated with them.
• Treating planned controls as proof of no threat. It's tempting to assume that having a security control in place means you've solved the problem. Not necessarily. Document the threat first, then identify the control intended to address it. And don't forget to consider what could happen if that control fails without anyone noticing.
• Three sessions, three formats. Imagine trying to combine the findings from three different threat modeling workshops, each using its own table format and numbering system. It's a recipe for confusion. Agree on one format and a consistent threat ID system before the first session. You'll save yourself considerable trouble when it's time to connect threats with risks, requirements, and tests.
• Modeling once. Threat modeling isn't something you check off a list and forget about. FDA recommends conducting it throughout the design process. If an interface changes, a new dependency appears, or a cloud component is updated, revisit the affected part of your model. The same goes for findings from a penetration test or security code review that uncover threats your team hadn't considered.

Where STRIDE sits in the lifecycle

Think of STRIDE threat modeling as one important part of a much larger cybersecurity process.

It starts with a data flow diagram that shows how the system works and where information travels. STRIDE helps your team identify what could go wrong. Those findings then feed into the cybersecurity risk assessment, which informs the security controls, tests, and architecture views.

But here's the important part: The process doesn't end after the first threat modeling workshop.

As your medical device evolves, new components, software updates, and changes to connected systems can introduce new threats. That's why STRIDE should be part of your secure software development lifecycle, not just an exercise you conduct before submitting documentation to FDA.

Done consistently, medical device threat modeling gives your team a reliable record of the threats it considered and the steps taken to address them. That record also helps connect the cybersecurity documentation needed for regulatory review.

For a deeper look at the methodology, its relationship to ISO 14971, TIR57, and SW96, and a worked example, see our STRIDE threat modeling guide. If your device connects to the cloud, our article on threat modeling for cloud-connected medical devices addresses those additional considerations.

Finally, our book chapter on threat modeling explores the attacker's perspective that makes this entire process work.

Need help running STRIDE on your device? We facilitate the sessions and write the threat model, and our penetration testing checks the result. Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• MITRE and MDIC. Playbook for Threat Modeling Medical Devices, November 2021. https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers.
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management.
• ISO 14971:2019. Medical devices, Application of risk management to medical devices.
• Microsoft. Threats: Microsoft Threat Modeling Tool (STRIDE categories). https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats