On this page
Published:
Key Takeaways
- A cloud-based device threat model covers the device, the mobile app, the cloud services, and every connection between them, not just the hardware.
- The cloud provider secures its infrastructure; the manufacturer still owns identity, configuration, data, code, and logging in its own account.
- Each threat should trace to a control, a test, and, where relevant, a hazardous situation and patient harm.
- Multi-patient threats, such as a compromised clinician portal or tenant isolation failure, usually carry the highest impact in cloud systems.
- This example is fictional and simplified; a real submission needs device-specific architecture and evidence.
What does a threat model for a cloud-based medical device look like?
A threat model for a cloud-based medical device maps the whole system: the device, the phone app, the cloud services, the clinician portal, and each data flow between them. You draw trust boundaries, apply STRIDE to each element and flow, link each threat to possible patient harm, and record the control and the test that proves it. The fictional example below walks through each step for a wearable heart rhythm monitor.
The device, company, and findings here are fictional. Use the structure, not the specific risk ratings. For the method itself, see STRIDE for medical devices and the threat model template.
Step 1: Describe the system
Fictional device: a wearable patch that records heart rhythm, sends data over Bluetooth Low Energy (BLE) to a patient phone app, which uploads to a cloud platform. Clinicians review alerts in a web portal. The patch receives firmware updates through the app.
| Element | Type | Notes |
|---|---|---|
| Wearable patch | Device | Sensor, BLE radio, firmware, local storage |
| Patient app | Process | iOS and Android, stores tokens, relays data and updates |
| API gateway | Process | Public entry point for app and portal traffic |
| Ingestion and analysis service | Process | Detects arrhythmias and raises alerts |
| Patient data store | Data store | Rhythm data and alert history for all patients |
| Firmware update service | Process | Hosts signed images |
| Clinician portal | Process | Web app used by hospital staff |
| Identity provider | External | Accounts for patients and clinicians |
| Hospital EHR | External | Receives reports through an integration |
Step 2: Draw trust boundaries
- Patch to phone (BLE link, physical proximity).
- Phone to internet (untrusted networks).
- Internet to API gateway (public edge).
- Gateway to internal cloud services (manufacturer cloud account).
- Cloud to hospital EHR (third-party network).
- Clinician browser to portal (hospital and home networks).
Step 3: Agree shared responsibility
| Layer | Cloud provider | Manufacturer |
|---|---|---|
| Physical data centers and hardware | Yes | No |
| Managed service patching | Yes | Selects and configures services |
| Identity and access in the account | No | Yes |
| Network rules, encryption settings, and keys | Tools provided | Configures and owns |
| Application code and dependencies | No | Yes, including SBOM entries |
| Logging, monitoring, and incident response | Tools provided | Enables, reviews, and responds |
Record this table in the threat model. The FDA expects the manufacturer to address risks in the whole system, including cloud components it operates.
Step 4: Apply STRIDE
| ID | Element or flow | STRIDE | Threat | Possible harm |
|---|---|---|---|---|
| T-01 | Patch to phone | Spoofing | A nearby attacker pairs a rogue phone and reads or injects data | Missed or false arrhythmia alert for one patient |
| T-02 | Firmware update path | Tampering | A modified firmware image is pushed through the app | Patch stops recording or reports false data |
| T-03 | API gateway | Elevation of privilege | Broken object-level authorization lets one patient read another's data | Privacy breach; possible data alteration |
| T-04 | Clinician portal | Spoofing | Phished clinician credentials give access to all assigned patients | Alerts dismissed or altered for many patients |
| T-05 | Patient data store | Information disclosure | Misconfigured storage exposes records publicly | Multi-patient privacy breach |
| T-06 | Analysis service | Denial of service | Request flooding delays alert processing | Delayed treatment for many patients |
| T-07 | Ingestion service | Tampering | Unvalidated uploads alter rhythm data before analysis | Wrong clinical decision |
| T-08 | Cloud admin accounts | Elevation of privilege | Stolen administrator keys allow full account control | Loss of service and data for all patients |
| T-09 | Audit logging | Repudiation | Portal actions are not attributable to a user | Cannot investigate dismissed alerts |
| T-10 | EHR integration | Information disclosure | Integration credentials leaked from configuration | Data exposure in hospital systems |
Step 5: Rate and link to safety
Use your security risk method (for example, ANSI/AAMI SW96) for exploitability and impact, and hand threats with safety effects to ISO 14971 risk management. Multi-patient threats (T-04, T-05, T-06, T-08) usually rank above single-patient threats because one exploit affects many people.
| ID | Exploitability (illustrative) | Impact | Safety link |
|---|---|---|---|
| T-02 | Medium | High | Yes: loss of monitoring function |
| T-04 | High | High | Yes: alerts suppressed |
| T-06 | Medium | High | Yes: delayed alerts |
| T-03 | Medium | Medium | Indirect |
Step 6: Assign controls and tests
| ID | Control | Test evidence |
|---|---|---|
| T-01 | Authenticated BLE pairing with out-of-band confirmation; application-layer encryption | Pairing and injection tests with BLE tooling |
| T-02 | Code signing verified by the patch bootloader; anti-rollback | Unsigned, altered, and downgrade image tests |
| T-03 | Server-side authorization on every object request | API authorization testing with two patient accounts |
| T-04 | Phishing-resistant MFA for clinicians; session timeout; alert action confirmation | Portal penetration test; MFA bypass attempts |
| T-05 | Private storage by default; configuration scanning; encryption at rest | Cloud configuration review |
| T-06 | Rate limiting; autoscaling; alert-path priority queue; downtime alert to clinicians | Load and resource exhaustion testing |
| T-07 | Message integrity from patch to cloud; input validation | Malformed and replayed upload tests |
| T-08 | Least-privilege roles; no long-lived admin keys; MFA; break-glass procedure | Identity and access review |
| T-09 | Immutable audit log of portal actions with user identity | Log review after scripted portal actions |
| T-10 | Secrets manager; scoped integration credentials; rotation | Configuration and secrets review |
Step 7: Record residual risk and labeling
For each threat, record residual risk, the manufacturer's acceptance decision, and anything users must do. For this example, labeling would tell clinicians to enable MFA, tell patients to keep the app updated, and describe what the system does when cloud services are unavailable.
Step 8: Keep it current
Update the threat model when you add a cloud service, change the app, change the identity provider, or learn of a new vulnerability through postmarket monitoring. Cloud components belong in the SBOM where they are part of the software you ship or operate.
Common gaps in cloud device threat models
- Treating the cloud as a single box with no internal boundaries.
- Leaving out the clinician portal or administrator access.
- Assuming the cloud provider handles account configuration.
- No multi-patient impact analysis.
- Threats with no matching test.
- No description of safe behavior when the cloud is unreachable.
How Blue Goat Cyber helps
We build device-specific threat models for cloud-connected systems, then test them through penetration testing of the device, apps, APIs, and cloud configuration. Evidence maps to the FDA's February 3, 2026 premarket cybersecurity guidance and to standards such as IEC 81001-5-1 and IEC 62443.
FAQ
Does the FDA expect cloud components in the threat model?
Yes. The FDA's guidance asks manufacturers to consider the full system the device connects to, including cloud services and other connected components, when assessing cybersecurity risk.
Who is responsible for cloud security, the provider or the manufacturer?
Both. The provider secures its infrastructure. The manufacturer owns identity, configuration, code, data protection, and monitoring in the services it operates.
Should SaMD with no hardware use the same method?
Yes. Remove the device and BLE elements and keep the app, APIs, cloud services, and portals. See SaMD cybersecurity requirements.
Is STRIDE the only acceptable method?
No. The FDA does not mandate a method. STRIDE, attack trees, and other methods work if the result is complete, traceable, and tied to device risk.
Sources and primary references
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 3, 2026.
- Section 524B of the FD&C Act, 21 U.S.C. 360n-2.
- MITRE and MDIC, Playbook for Threat Modeling Medical Devices.
- ANSI/AAMI SW96:2023, Standard for medical device security, security risk management for device manufacturers.
- ISO 14971:2019, Medical devices, application of risk management to medical devices.
Sources & references
Primary sources cited in this article. Links open in a new tab.
