What threat modeling is
The Threat Modeling Manifesto defines threat modeling as analyzing representations of a system to highlight concerns about its security and privacy characteristics. It reduces the work to four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?
For a medical device, "what we are working on" is never only the device. FDA's premarket cybersecurity guidance uses the term medical device system for the device plus the networks, other devices, and software update servers it connects to, and recommends that threat modeling be inclusive of all medical device system elements. Section 524B(b)(2) of the FD&C Act uses the phrase "device and related systems" for the same idea. The Section 524B guide covers that obligation.
STRIDE is one way to answer the second question. It is a mnemonic for six threat types: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. It works best when applied to a data flow diagram, which is the answer to the first question. This guide walks through both, then shows how the output feeds the risk assessment and the architecture views a reviewer opens.
What FDA expects the threat model to contain
Section V.A.1 of the guidance states what the threat model should do. It should identify the medical device system risks and mitigations, and inform the pre-mitigation and post-mitigation risks in the cybersecurity risk assessment. It should state assumptions about the system and its environment of use. The guidance gives an example assumption: hospital networks are hostile, so assume an adversary controls the network and can alter, drop, and replay packets. It should capture risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance and update activities, and decommissioning.
FDA does not prescribe a method. The guidance says a number of methodologies, or combinations, may be used, and asks that the rationale for the method be provided with the documentation. Its footnote names the MDIC and MITRE Playbook for Threat Modeling Medical Devices as an educational resource. Appendix 4 lists the threat model as part of the cybersecurity risk management report and notes that it may include the architecture views.
The guidance also says threat modeling should be performed throughout the design process and can be performed or reviewed during design reviews. A threat model produced once, after the design is frozen, is the pattern that draws a deficiency. The document FDA reads should show dates and revisions.
Step 1: Build the data flow diagram
The playbook uses the DFD3 notation, which has five element types. Keeping to five makes the diagram usable in a design review and readable when printed in black and white.
| Element | Drawn as | Represents |
|---|---|---|
| External entity | Sharp-cornered rectangle | Anything outside your control: people, and systems run by other organizations |
| Process | Rounded rectangle | Any running code: firmware, a mobile app, a cloud service, a stored procedure |
| Data store | Drum | Anywhere data rests: flash, a database, cloud storage, a log file |
| Data flow | Arrow, usually double-headed | Every way processes talk to each other or to data stores |
| Trust boundary | Closed dashed shape | A change in trust level between elements |
Label every element. Group and nest elements where it helps; a device can contain several processes and stores. Use a double-headed arrow for most flows, because responses travel back, and mark which side initiates the connection if it matters. Use a one-way arrow only for traffic that is truly one way, such as a UDP broadcast.
The playbook's advice on stopping is practical. Move to the next stage when the diagram covers every interface in the product requirements, every party that touches the device across its lifecycle, and every place data rests. If a later STRIDE session keeps producing threats against an element that is not on the diagram, the diagram is incomplete.
Where to draw trust boundaries
Trust boundaries are assumptions, not hardware. The playbook says they belong wherever the team wants to enforce control over how two entities interact. Its rule of thumb: where a control mechanism exists, such as a firewall, an access control list, a lock, or a login, that is a good place for a boundary. When code or data crosses to a party you do not control, draw one. When an adversary could bypass a control that legitimate users never cross, such as a physical fence or a sealed case, still document the boundary, because adversaries do not follow the normal process.
Draw every boundary as a complete closed shape. An arc or a single line hides which elements are inside. A boundary with no drawn communication path across it is itself a finding: the playbook notes it implies a path exists, approved or not, that needs analysis. Physical access to a debug header, a sensor that reads an untrusted input, and a service port all fall into this category.
How much of the system to model
The guidance expects scope to match the "device and related systems" of Section 524B(b)(2): other devices, software that performs other functions, update servers, and healthcare facility networks. Model the companion app, the cloud tenant, the update server, and the clinician workstation as processes with their own boundaries, even when another team or a vendor owns them. The threat model states what is assumed about those elements, and those assumptions become requirements on the vendor or labeling for the facility.
The guidance also scales documentation with cybersecurity risk, not with software documentation level. A device with a single USB port needs a small diagram. A device with wireless, cloud, and a commercial operating system needs several diagrams at different levels of abstraction, and the playbook recommends pairing a high-level DFD with swim lane or state diagrams for the protocols.
Step 2: Apply STRIDE per element
The six STRIDE categories, with the healthcare examples the playbook uses:
| Type | Description | Example from the playbook |
|---|---|---|
| Spoofing | A falsified entity is accepted as a true one | Stolen credentials used to log in as another nurse |
| Tampering | Unauthorized modification | Patient data changed to incorrect values |
| Repudiation | Disputing that an action took place | Denying that a prescribed treatment was delivered |
| Information disclosure | Restricted information exposed | Health data sent over an unencrypted Bluetooth link |
| Denial of service | Legitimate access or function blocked | A sensor flooded with bad pairing requests |
| Elevation of privilege | Access beyond the intended security policy | A patient uses a portal flaw to see all patient records |
STRIDE per element narrows the questions to the ones that usually apply. The playbook's mapping:
| Element | Spoof | Tamper | Repudiate | Disclose | Deny | Elevate |
|---|---|---|---|---|---|---|
| External entity | Yes | Yes | ||||
| Process | Yes | Yes | Yes | Yes | Yes | Yes |
| Data store | Yes | Sometimes | Yes | Yes | ||
| Data flow | Yes | Yes | Yes |
External entities take only spoof and repudiate because you cannot model the inside of a system you do not own. Data flows take tamper, disclose, and deny because the analysis is about the data in transit; spoofing and elevation belong to the process that receives the data. The question mark on data store repudiation reflects that some teams log that threat against the store and others against the process that manages it. The playbook's point is that recording the threat matters more than which cell it lands in.
Prioritize elements and flows that cross a trust boundary. Modern device DFDs can have hundreds of elements, and the crossings are where attacks arrive. Work inward afterward as time allows. The table also tells you when to stop: when every element has entries for its applicable types, or a written reason why a type does not apply, the brainstorming stage is complete.
Repudiation, the category teams skip
The playbook singles out repudiation as the category newcomers miss. Its shorthand: look for places where subverting the process has a monetary or legal consequence. In a medical device system that includes therapy delivery records, alarm acknowledgments, configuration changes by a service technician, and consent to data sharing. Repudiation differs from spoofing because the risk is in how parties interpret an action after the fact. A legitimate user may be the one being deceptive. The control is usually a tamper-evident audit log with a trustworthy clock and user attribution, which is also a control the guidance's Appendix 1 event detection and logging category expects.
Step 3: Build the threat table
The playbook recommends one summary table that maps each component to the STRIDE types found, with reference IDs that link to a detailed record for each threat. The IDs are links, not counts, and they need not be contiguous. CyberMed's threat tables use these columns for the detailed record, which line up with what TIR57 clause 4.3 asks the analysis to identify and what the guidance's Appendix 2 asks the architecture views to trace:
| Column | What goes in it |
|---|---|
| Threat ID | Stable identifier, reused in the risk assessment, requirements, tests, and architecture views |
| Element and boundary | The DFD element, and the trust boundary crossed if any |
| STRIDE type | One primary type; note a secondary type if the threat spans two |
| Threat description | Who does what to which asset through which interface |
| Assumption | The environment or actor assumption the threat depends on |
| Asset and adverse impact | The asset per TIR57 4.3.3, and the impact of losing its confidentiality, integrity, or availability per 4.3.4 |
| Pre-mitigation risk | Score under the documented method, with the factors shown |
| Response | Eliminate, mitigate, accept, or transfer, with rationale |
| Control | The security requirement that implements the response, by ID |
| Residual risk | Score after the control, same method |
| Verification | The test case or analysis that shows the control works |
| View | The architecture view where the reviewer can see the control in place |
The playbook's documentation checklist asks for completeness, clarity, specificity, traceability, consistency with the built device, stated assumptions, and rationales for decisions, especially where risk is accepted or transferred. A table with those columns answers each of those points. Store it in a spreadsheet or database, generate the summary view from it, and keep the diagram IDs in sync.
Step 4: Score and decide
The four responses in the playbook are eliminate, mitigate, accept, and transfer. TIR57 clause 6.2 gives the order of preference for controls, parallel to ISO 14971: inherent security by design first, then protective measures in the device or manufacturing process, then information for security such as requirements placed on the network operator. TIR57 warns that leaning on network configuration requirements is the weakest option, because no one can assure every network is configured that way.
For scoring, the playbook describes three mechanisms: DREAD, CVSS with the MITRE Rubric for Applying CVSS to Medical Devices, and the scales in NIST SP 800-30 Rev. 1 appendices D through I. It warns against using any score as the sole criterion for acceptability, and recommends the security score be an input to the safety risk assessment. TIR57 clause 4.4 asks for a documented, repeatable estimation process where experts can agree on each factor.
FDA's guidance adds two constraints. First, security risk is not probabilistic. Section V.A.2 says it is not possible to assess likelihood from historical data, so the assessment focuses on exploitability, and a premarket assessment can either assume worst case and control it or justify a reasonable exploitability across the lifecycle. Second, vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog should be designed out, not scored and accepted, because they are already being exploited. The guidance also asks that the scoring methods and acceptance criteria used pre-mitigation and post-mitigation be provided in the submission.
How STRIDE maps to ISO 14971, TIR57, and SW96
ISO 14971:2019 defines the risk management process for medical devices. AAMI TIR57 applies it to security risk during design, and ANSI/AAMI SW96:2023 turns that guidance into requirements across the lifecycle. Both keep security risk management inside the ISO 14971 framework but run it as a separate, coupled process, because a breach of data and systems security or a loss of effectiveness may not be a safety harm in the ISO 14971 sense. FDA's guidance names TIR57 and SW96 as the references for security risk management plans and reports.
The playbook maps the four threat modeling questions onto the TIR57 process. The table below extends that mapping to the SW96 clause numbers.
| Threat modeling step | TIR57 clause | SW96 clause | ISO 14971 counterpart |
|---|---|---|---|
| Build the DFD, list assets | 4.2 intended use and security characteristics; 4.3.3 assets | 5.2 intended use and reasonably foreseeable misuse; 5.3 assets | Clause 5.2 intended use; 5.3 characteristics related to safety |
| Apply STRIDE, record threats and vulnerabilities | 4.3.1 threats; 4.3.2 vulnerabilities; 4.3.4 adverse impacts | 5.4 vulnerabilities and threats | Clause 5.4 identification of hazards and hazardous situations |
| Score each row | 4.4 risk estimation | 5.5 risk estimation | Clause 5.5 risk estimation |
| Decide acceptability | 5 risk evaluation | 6.1 and 6.2 evaluation, including safety impact | Clause 6 risk evaluation |
| Choose and implement controls | 6.1 to 6.3 control hierarchy and implementation | 7.1 and 7.2 control option analysis and implementation | Clause 7.1 to 7.3 |
| Residual risk and new risks from controls | 6.4 to 6.7 | 7.3 to 7.6 | Clause 7.4 to 7.6 |
| Overall residual risk and report | 7 and 8 | 8 and 9 | Clause 8 and 9 |
| Keep the model current | 9 production and post-production | 10 production and post-production; Annex D.3.3 | Clause 10 |
Two rules keep the processes coupled. Every threat with a safety impact becomes a hazardous situation in the ISO 14971 file, with the threat ID as its cause. Every control added on either side is checked for new risk on the other: an authentication timeout that blocks a clinician in an emergency is a safety risk introduced by a security control, and TIR57 Annex A.5 addresses emergency access for that reason. SW96 Annex D describes threat modeling as the source of the "table of threats with defined mitigations" that is then managed like any other requirement or defect.
From the threat model to the architecture views
Section V.B.2 of the guidance asks for four security architecture views: global system, multi-patient harm, updatability and patchability, and security use case views. It says the views are an effective way to provide threat modeling information to FDA and that a threat model which sufficiently captures a view need not be duplicated. In practice the DFD is the global system view once the Appendix 2 details are added: protocol names and versions, ports, authentication and session mechanisms, credential lifecycle, and the intended behavior on error.
The multi-patient harm view answers a STRIDE question at fleet scale: if one instance is compromised, what path leads to many, through the cloud tenant, the update server, or the facility network. The updatability view is the update data flow with its signing, verification, and rollback drawn end to end, including segments the manufacturer does not control. Each security use case view is a slice of the DFD for one clinical function, with the threats and controls for that slice. The threat IDs from Step 3 appear on the views, which gives the reviewer the traceability the guidance asks for. CyberMed's post on security architecture views covers the content of each view.
Worked example: a cloud-connected patient monitor with a companion app
The example is illustrative and does not describe a specific client device. It is a Class II bedside monitor that streams vital signs over Wi-Fi to a manufacturer cloud service, pairs with a companion mobile app over Bluetooth Low Energy for patient-side viewing, receives firmware from a manufacturer update server, and exposes a USB port for factory provisioning and field service.
Diagram. External entities: patient, clinician, service technician, hospital network operator, cloud platform provider, app store. Processes: monitor firmware, monitor application, companion app, cloud ingestion service, cloud web portal, update server. Data stores: on-device measurement buffer, on-device configuration and credentials, cloud patient database, update package repository. Flows: BLE between monitor and app, Wi-Fi and TLS between monitor and cloud, HTTPS between app and cloud, HTTPS between monitor and update server, USB between technician laptop and monitor. Trust boundaries: the monitor enclosure, the app sandbox, the hospital network edge, the cloud tenant, the update signing environment, and the USB service interface.
Threats found at the boundary crossings. A sample of rows, with the IDs used across the file:
| ID | Element | Type | Threat | Response and control |
|---|---|---|---|---|
| T-01 | BLE flow | Information disclosure | Vital signs read by a nearby receiver during pairing or streaming | Mitigate: LE Secure Connections pairing with authenticated encryption; requirement SR-07; test TC-07 |
| T-02 | Companion app (process) | Spoofing | A rogue app presents itself as the companion and requests data | Mitigate: mutual authentication with per-device credentials provisioned at pairing; SR-08; TC-08 |
| T-03 | Wi-Fi flow to cloud | Tampering | Packets altered or replayed on the hospital network, per the guidance's hostile network assumption | Mitigate: TLS with certificate pinning and message sequence numbers; SR-11; TC-11 |
| T-04 | Update server flow | Elevation of privilege | Unsigned or downgraded firmware installed through the update path | Eliminate: signed packages with anti-rollback version check; SR-15; TC-15; shown in the updatability view |
| T-05 | USB service interface | Elevation of privilege | Technician port used to read credentials or load code | Mitigate: authenticated service mode, credentials in a secure element, port disabled in clinical mode; SR-19; TC-19 |
| T-06 | Cloud ingestion service | Denial of service | Malformed telemetry crashes the ingestion path for every connected monitor | Mitigate: input validation, rate limiting, per-tenant isolation; SR-22; TC-22; shown in the multi-patient harm view |
| T-07 | Monitor application | Repudiation | Alarm acknowledgment disputed after an event | Mitigate: signed audit log with synchronized time and user attribution; SR-25; TC-25 |
| T-08 | Configuration store | Tampering | Alarm limits changed through the service interface without a record | Mitigate: integrity-protected configuration with change logging; SR-26; TC-26 |
Assumptions recorded. The hospital network is hostile. The patient's phone may be compromised. The cloud provider's infrastructure controls are inherited under a shared responsibility model and are listed as a transfer with the provider's attestation referenced. The USB port is physically accessible to anyone at the bedside.
Scoring and decisions. Each row is scored with the CVSS rubric before and after controls. T-04 is eliminated rather than mitigated because an update path compromise is a multi-patient harm path. T-06 is carried into the multi-patient harm view and the risk assessment as a fleet-scale event. T-07 is the row most teams would have missed without the STRIDE per element table, since the monitor application had spoof, tamper, and deny entries after the first pass and no repudiation entry.
What the reviewer sees. The global system view is the diagram above with protocol details. The multi-patient harm view traces T-06 and T-04. The updatability view traces T-04 end to end. Four security use case views cover pairing, streaming, alarm handling, and service mode. Every view carries the threat IDs, every threat has a requirement and a test, and the cybersecurity risk assessment lists the same IDs with pre-mitigation and residual scores.
Common reviewer findings on threat models
These are the gaps CyberMed sees most often when it reviews a threat model before submission, stated against the guidance section each one misses. No frequencies are given, because CyberMed does not publish client data.
- Device-only scope. The diagram stops at the enclosure. The guidance asks for the medical device system, and Section 524B(b)(2) says device and related systems. Add the app, cloud, update server, and facility network.
- No stated assumptions. Section V.A.1 asks for assumptions about the system and environment. Without them, a reviewer cannot tell whether a hostile network was considered.
- No method rationale. The guidance asks for the rationale for the methodology chosen. One paragraph explaining why STRIDE on a DFD fits the device, and what it was supplemented with, closes this.
- Threats without IDs, or IDs that do not appear anywhere else. Appendix 2 asks for precise links between diagram elements, hazards, controls, and testing. Traceability is the finding, not the threat count.
- Lifecycle gaps. The guidance names supply chain, manufacturing, deployment, maintenance and update, and decommissioning. Provisioning, service mode, and end-of-life data handling are the usual holes.
- Probabilistic scoring. A likelihood column based on "unlikely" with no exploitability reasoning contradicts Section V.A.2. Score exploitability, and show the factors.
- Accepted risks without rationale. The playbook's checklist and TIR57 clause 6.5 both ask for the reasoning, including a risk-benefit analysis where risk reduction is not practicable.
- A frozen model. No revision history, and no link to the postmarket plan required by Section 524B(b)(1).
Keeping the model alive
SW96 Annex D.3.3 describes post-production as the point where new features, reported vulnerabilities, and third-party component advisories send the team back to the model. When a new vulnerability is reported, the threat model shows which data flows it touches and whether existing controls cover it. That analysis is what FDA's postmarket guidance expects when a manufacturer decides whether a risk is controlled or uncontrolled, and what Section 524B(b)(1) expects the vulnerability plan to describe.
The premarket guidance says the same thing from the other side: manufacturers should update the threat model and risk assessment as new risks, threats, vulnerabilities, assets, or adverse impacts are discovered through the lifecycle, so vulnerability impacts can be identified quickly once the device is released. A model kept in a spreadsheet with IDs, a revision log, and a link from the cybersecurity management plan meets that expectation. A model exported once to a PDF for the submission does not.
Where CyberMed fits
CyberMed builds the threat model, the risk assessment, and the four architecture views as one traced set, with the same IDs in each. The FDA cybersecurity documentation service covers that file. Medical device penetration testing then tests the controls in the threat table against the threats it lists, which is the evidence Section V.C of the guidance asks the test report to tie back to the threat model. The 30-day Cybersprint delivers both for teams with a submission date.
If your threat model exists but has not been checked against the points above, the FDA 524B readiness assessment takes three minutes and flags the gaps a reviewer would.