Start the Threat Model With Every System Element
Connectivity Threat Model Starter
Companion to Medical Device Connectivity · Updated 2026-09-29
Use this to start a threat model early in design and to keep it current for the life of the product, covering the device and every system element around it. Security engineers run it with systems and safety engineers; “Secure Devices Across Their Whole Life” works it on the bedside monitor and its gateway.
The US Food and Drug Administration’s (FDA) premarket cybersecurity guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, is current in its February 3, 2026 revision, which aligned the June 2025 final guidance with the Quality Management System Regulation. It recommends threat modeling throughout design, covering all medical device system elements, and four security architecture views: global system, multi-patient harm, updatability and patchability, and security use cases. Separately, section 524B of the Federal Food, Drug, and Cosmetic Act has required, since March 29, 2023, that premarket submissions for cyber devices include an SBOM and a postmarket vulnerability plan, and that manufacturers address updates and patches. FDA counts even a brief Universal Serial Bus (USB) service connection as an ability to connect, so an unnetworked device still belongs on this worksheet. Apart from the section 524B requirements, the guidance is nonbinding. This starter is the first step of a threat model, and a premarket submission needs the complete analysis.
Fill in one row per system element, including the elements the manufacturer doesn’t own. Name an owner for every control.
The Connectivity Threat Model Starter: one row per system element, including the ones the manufacturer doesn’t own.
| System element | Entry points | What an attacker could reach or change | Consequence (one patient or many) | Controls, and who owns them |
|---|---|---|---|---|
| Device | ||||
| Gateway | ||||
| Network segment | ||||
| Enterprise systems (electronic health record, laboratory information system, imaging archive, alarm, tracking) | ||||
| Vendor cloud service | ||||
| Update service and build environment | ||||
| Service interfaces (USB, service port, remote service) | ||||
| Accessories and consumable readers | ||||
| Users and roles |
With the table filled in, check the lifecycle items:
- The SBOM lists commercial, open-source, and off-the-shelf software components in machine-readable form, with each component’s level of support and end-of-support date.
- Every entry point has authentication and authorization, or a documented reason it doesn’t.
- The update path appears in the table as an entry point, and every update is signed.
- The multi-patient harm view shows what an attacker could do across the whole fleet at once.
- Security events are logged in a format the institution’s security monitoring tools can consume.
- The postmarket plan names how the team monitors, discloses, and fixes vulnerabilities.
- End of support is planned: the date, the notice to customers, and how risk transfers if devices stay in service.
- No security control blocks the institution from its own device data.
A threat that reaches many patients through one shared element (the gateway, the update service, the vendor cloud) ranks above any single-device threat, so fix those first. Any system element nobody claims as its owner is the first finding.