A Comprehensive Guide to Threat Modeling for Cloud-Connected Medical Devices

Connecting a medical device to the cloud opens up a world of possibilities. Medical professionals love it. Patients benefit. The downside? It also opens the door to cybersecurity risks that manufacturers might not see coming.

That's why threat modeling for cloud-connected medical devices is important. What you're searching for takes much more effort than finding weaknesses in a medical device itself. You must zero in on specific areas of potential vulnerability, including:

• Companion apps
• Software updates
• Cloud services
• The wireless connection
• Networks that keep everything running

It may seem like overkill, but a security problem anywhere along that chain could be bad news for the entire system.

FDA recognizes these risks as covered in its February 2026 premarket cybersecurity guidance. Take a look. Here you will find where FDA recommends threat modeling throughout device design and expects manufacturers to document their findings as part of the submission.

So in this article, we'll walk through five steps for threat modeling a medical device that communicates with a smartphone and the cloud. You'll also learn about how cloud connectivity complicates the process and what documentation belongs in your submission.

For an even closer look at the methodology, see our STRIDE threat modeling guide.

What FDA expects the threat model to do

FDA makes one thing clear in Section V.A.1 of its February 2026 premarket cybersecurity guidance: Threat modeling needs to look at the entire medical device system, not just the device itself.

The goal is to identify security risks and vulnerabilities, then determine how to prevent, reduce, monitor, or respond to potential threats. FDA also recommends making medical device threat modeling part of the design process rather than something you tackle just before submission.

Specifically, your FDA threat model should:

• Identify risks and mitigations. Show how threats were identified, what controls you put in place, and how those decisions inform cybersecurity risk assessments before and after mitigation.
• Explain your assumptions. For example, FDA recommends treating hospital networks as potentially hostile environments where attackers could intercept, alter, or replay data.
• Look beyond the device. Consider risks involving suppliers, manufacturing, deployment, interoperability, maintenance, software updates, and decommissioning that traditional safety risk assessments might overlook.

FDA doesn't require a particular threat modeling method. However, you need to explain why you chose yours. The agency also points to the MITRE and MDIC Playbook for Threat Modeling Medical Devices as a useful resource.

For cloud medical device security, there's another important consideration. Your threat model needs to account for cloud services, identity providers, and update servers, even when outside vendors manage them.

In other words, outsourcing part of your system doesn't mean outsourcing responsibility for its security.

Step 1: Model the system, including the parts you don't own

Before you can identify cybersecurity threats, you need to understand what you're protecting. And that means looking beyond the medical device itself to see how information moves through the entire system.

Start with a data flow diagram. It gives you a visual picture of where data travels, which systems handle it, and where potential security gaps might exist. Our post on how to create data flow diagrams for medical devices explains the notation.

For a cloud-connected device, the elements usually include:

• Embedded Microcontroller: Runs the firmware, processes sensor data, and may store security credentials.
• Bluetooth Communication: Carries patient data between the device and a mobile app.
• Mobile Application: Lets users view device information and sends data to cloud services.
• Cloud Portal: Stores and analyzes patient data and supports remote monitoring.
• Data Flow Mapping: Shows how information moves between components and where trust boundaries exist.

Here's something manufacturers sometimes overlook. A device can be secure on its own while the connections to other systems leave it exposed.

That's why medical device threat modeling needs to account for third-party cloud services, authentication systems, and software update servers, even when another company manages them.

Step 2: Find what can go wrong

Now that you've mapped your system, it's time to look for trouble. Where could someone break in? What information could they steal or change? And could an attack interfere with patient care?

One widely used approach is STRIDE. The STRIDE medical device threat modeling approach helps manufacturers identify potential security weaknesses across six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

The STRIDE per element method helps narrow your search. For example, external entities are examined for spoofing and repudiation, while processes are checked against all six categories. Data stores and data flows are examined for tampering, information disclosure, and denial of service. Our STRIDE for medical devices post explains how this works.

Start by examining the places where data crosses trust boundaries. For a typical device, app, and cloud system, here's what could go wrong:

Where	STRIDE type	Example threat
BLE link, device to app	Spoofing	A rogue app pairs with the device and reads or injects data
BLE link	Information disclosure	Readings captured over an unencrypted or weakly paired connection
Update path to device	Tampering	Modified firmware accepted because signature or version checks are missing
Cloud API	Elevation of privilege	A patient account reaches another patient's records through a missing authorization check
Cloud API	Spoofing	Stolen or replayed tokens used to send commands to a device
Cloud portal	Denial of service	Request flooding takes the portal offline during a clinical workflow
Clinician portal	Repudiation	A dosing change cannot be attributed to a user because logs lack identity or a trustworthy clock
Cloud data store	Information disclosure	Misconfigured storage exposes a database of readings

Keep in mind that an attacker doesn't necessarily need physical access to the medical device. A vulnerability in a cloud service or mobile application may be enough to compromise the system.

Step 3: Assess risk by exploitability, then by harm

Here's where things can get tricky. Many manufacturers approach cybersecurity risk assessment the same way they evaluate traditional safety risks. They multiply probability by severity and assign a score.

But cyberattacks don't work that way.

Section V.A.2 of FDA's premarket cybersecurity guidance explains that cyber incidents are difficult to predict. Historical data can't reliably tell you how likely an attack is to occur. Instead, FDA recommends focusing on exploitability, or how easily someone could take advantage of a vulnerability.

This approach also aligns with ANSI/AAMI SW96:2023, which calls for evaluating exploitability alongside the potential impact on confidentiality, integrity, and availability. While AAMI SW96 threat modeling isn't a separate methodology, the standard provides a risk management framework that helps manufacturers evaluate the threats they've identified. AAMI TIR57 goes further, recommending that manufacturers consider an attacker's skills, motivation, and whether the potential payoff makes an attack worthwhile.

So, what does this mean for medical device threat modeling?

Under Section V.A.2, manufacturers generally have two options for assessing each threat:

• Assume worst-case exploitability. Identify the necessary security controls and put them in place.
• Justify a reasonable exploitability assessment. Explain your assumptions, consider how threats could evolve throughout the device lifecycle, and document how the risk is controlled.

There's another consideration. Vulnerabilities discovered during testing may become easier to exploit over time as attackers develop new techniques. And vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog should be eliminated through design rather than simply scored and accepted.

Here's how these assessments might look for a cloud-connected medical device:

Threat	Exploitability	Impact (C/I/A)	Potential Patient Harm	Pre-Mitigation Risk
Rogue app pairs over BLE	High (adjacent, no privileges)	Integrity, Confidentiality	Incorrect readings shown to patient	High
Modified firmware accepted	Medium (requires update path access)	Integrity, Availability	Device malfunction	High
Cross-patient access through cloud API	High (network access, low privileges)	Confidentiality, Integrity	Incorrect patient data influences clinical decisions	High
Cloud portal denial of service	High (network access, no privileges)	Availability	Delayed clinical review	Medium

These ratings are illustrative. Actual assessments depend on the device, its architecture, intended use, and existing security controls.

Now comes an important connection between cybersecurity and patient safety.

If a threat could lead to patient harm, it needs to be carried into the ISO 14971:2019 safety risk assessment. The threat ID links the cybersecurity finding to the hazardous situation, while the safety process evaluates the severity of potential harm.

FDA also expects manufacturers to document three things: the scoring method used before and after mitigation, the criteria for accepting risk, and how cybersecurity risks are transferred into the safety risk assessment.

If you're using CVSS to evaluate vulnerabilities, our post on medical device risk assessment using CVSS explains FDA's reference to CVSS v3.0 and the MITRE rubric.

Step 4: Choose controls and check them against FDA's categories

You've identified the threats and assessed the risks. Now comes the part where you do something about them.

Section V.B.1 of FDA's premarket cybersecurity guidance identifies eight categories of security controls manufacturers should consider: Authentication; Authorization; Cryptography; Code, Data, and Execution Integrity; Confidentiality; Event Detection and Logging; Resiliency and Recovery; and Updatability and Patchability.

Appendix 1 provides additional recommendations for each category.

The idea is to match your security controls to the threats you've identified, then check all eight categories to make sure nothing important slipped through the cracks.

For cloud medical device security, several controls deserve particular attention:

• Authentication and authorization. Make sure the device and app recognize each other, and the same goes for the app and cloud. Every cloud API request should be checked for authorization. Just because someone has a valid patient token doesn't mean they should have access to another patient's records. FDA also recommends authenticating code, commands, and data, not just users.
• Cryptography and confidentiality. Use current NIST-recommended encryption algorithms and protocols, along with unique keys for each device. FDA cautions against storing master keys on devices, creating keys from serial numbers, or allowing connections to fall back to weaker protocols. AES-256 and TLS 1.3 are common choices, although FDA doesn't specifically require either.
• Code and data integrity. Firmware updates should be digitally signed, checked before execution, and protected against unauthorized rollbacks. Treat information coming from the mobile app or cloud as untrusted until it's validated. That includes configuration changes pushed to the device.
• Event detection and logging. Keep reliable security logs on both the device and cloud. Record what happened, when it happened, and which user or system was responsible. These records are especially important when investigating unauthorized changes or other suspicious activity.
• Resiliency and recovery. What happens if the cloud goes offline? Or worse, what if it sends incorrect information to the device? Your security plan should address how the device responds to these situations and how normal operations can be restored after a compromise.
• Updatability and patchability. Make sure your software update process works from beginning to end, from building the update to installing it on the device. And don't just document the process. Test it. Our article on secure software updates explains what's involved.

There's one final piece that manufacturers shouldn't overlook: documentation.

Every security control should connect to a specific requirement, a test that verifies it works, and an assessment of any risk that remains after implementation.

That connection is what makes your FDA threat model useful beyond the design stage. It gives reviewers a clear trail from the original threat to the security measures you've put in place.

For more on documenting those connections, see our guide to how to implement cybersecurity controls.

Step 5: Document, submit, and keep it alive

You've identified the threats, assessed the risks, and put security controls in place. But your work isn't finished. Now you need to show FDA what you've done and keep that information current.

Your FDA threat model belongs in the premarket submission as part of the Security Risk Management Report described in Section V.A of FDA's guidance. It sits alongside the cybersecurity risk assessment, Software Bill of Materials (SBOM), and unresolved anomaly assessment.

The good news? You don't have to document everything twice.

FDA recognizes that the Security Architecture Views described in Section V.B.2 can communicate much of the same information. For a cloud-connected device, the Global System View typically starts with your top-level data flow diagram, supplemented by the details FDA recommends in Appendix 2.

You'll also likely need more Security Use Case Views than you would for a device that only connects through USB. Our post on the architecture security view explains how to put these together.

Two other documents also depend on your threat model:

• The Cybersecurity Management Plan (Section VI.B). This explains how you'll monitor vulnerabilities, including those in CISA's Known Exploited Vulnerabilities catalog, issue patches, and communicate security information to customers. For cyber devices, Section 524B(b)(1) requires a plan to monitor, identify, and address postmarket vulnerabilities. Section 524B(b)(3) also requires an SBOM covering commercial, open-source, and off-the-shelf software components, including applicable cloud-side software. For more information, see FDA Section 524B requirements and SBOM generation for medical device software.
• Postmarket reporting. Cybersecurity responsibilities don't end when the device reaches the market. Manufacturers must evaluate vulnerabilities and determine whether remediation or reporting is required under applicable FDA rules. The agency's December 2016 postmarket cybersecurity guidance, along with 21 CFR Parts 806 and 803, helps establish those responsibilities. Our article on FDA post-market cybersecurity responsibilities explains the reporting requirements and timelines.

And here's something worth remembering: Medical device threat modeling isn't a one-and-done exercise.

Cloud environments change constantly. Your cloud provider might update its infrastructure next week. Your mobile app could get a new release next month. Meanwhile, your device firmware might not change for another year.

Any of those changes could introduce new security risks.

That's why your cloud medical device security process should include clear triggers for revisiting the threat model. Changes to cloud architecture, new third-party components, additional interfaces, penetration testing findings, or emerging postmarket threats should all prompt another look.

Finally, keep your threat model versioned and dated. FDA reviewers should be able to see which threats were evaluated, what changed, and how the documentation matches the device you're submitting.

The cloud changes the scope, not the method

When you get right down to it, threat modeling for cloud-connected medical devices follows the same basic principles as any other threat modeling process.

The difference? There's more to worry about.

You're dealing with systems you don't control, cloud services that can change without warning, and security failures that could affect hundreds or even thousands of patients.

That's why it's important to look at the entire system, identify where your control ends, assess threats based on exploitability, and match security measures to FDA's eight categories.

And don't forget to revisit your threat model as technology and threats evolve.

For a deeper understanding of how to approach this process, see our book chapter on threat modeling.

Need help with threat modeling for a connected device? Our FDA cybersecurity documentation service builds the model and the views. 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
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• 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. https://array.aami.org/doi/book/10.2345/9781570208621
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management. https://doi.org/10.2345/9781570206122.ch1
• 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