This is a ready-to-use threat model. It is the analytical core of a premarket cybersecurity file: it enumerates how an attacker could compromise the device, what is at stake, and what controls reduce the risk. Replace every <<FILL: ...>> placeholder, keep it a living document updated each release, and feed unresolved residual risk into the security risk assessment and, where an exploit could harm a patient, into the ISO 14971 safety risk file. A filled specimen follows. This content is educational reference, not legal or regulatory advice; confirm current FDA cybersecurity guidance before you rely on it.
Document control
| Field | Entry |
|---|---|
| Title | Cybersecurity Threat Model |
| Document number | <<FILL: DOC-ID, e.g. SEC-TM-009>> |
| Device / system | <<FILL: device or system name and version>> |
| Method | STRIDE per data-flow-diagram element |
| Prepared by (Product Security) | <<FILL: name, date>> |
| Reviewed by (Risk / Systems) | <<FILL: name, date>> |
1. Scope and system description
| Field | Entry |
|---|---|
| Device and intended use | <<FILL: what the device does>> |
| Interfaces in scope | <<FILL: network, wireless, USB/service ports, update mechanism, debug interface, mobile app, cloud>> |
| Assets to protect | <<FILL: patient data, therapy-control parameters, credentials, firmware integrity, audit logs>> |
| Out of scope (with rationale) | <<FILL: e.g. hospital network beyond the device boundary; note the transfer-of-responsibility to the operator>> |
2. Data-flow diagram and trust boundaries
Describe (or attach) the data-flow diagram. List each element and each trust boundary, since a trust boundary (where data crosses from a less trusted to a more trusted zone) is where threats concentrate.
| DFD element | Type (external entity / process / data store / data flow) | Trust boundary crossed? |
|---|---|---|
<<FILL: e.g. mobile app to device BLE link>> | <<FILL>> | <<FILL: Y/N>> |
<<FILL>> | <<FILL>> | <<FILL>> |
3. STRIDE scoring scales
Set explicit scales so ratings are reproducible. Security risk uses exploitability, not just random-failure probability.
Likelihood (exploitability):
| Level | Meaning |
|---|---|
| High | Remotely exploitable with low skill and no special access |
| Medium | Requires adjacency, some skill, or partial access |
| Low | Requires physical access, high skill, or an improbable chain |
Impact:
| Level | Meaning |
|---|---|
| High | Patient harm possible, therapy compromised, or large-scale data exposure |
| Medium | Limited data exposure or degraded function without direct harm |
| Low | Minimal effect on safety, effectiveness, or privacy |
Risk = combination of likelihood and impact (<<FILL: define your matrix, e.g. High x High = Unacceptable>>).
4. Threat enumeration (STRIDE)
For each DFD element, walk the six categories and record credible threats. STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
| ID | DFD element | STRIDE category | Threat description | Asset affected | Likelihood | Impact | Inherent risk | Control(s) | Residual risk | Safety-risk link |
|---|---|---|---|---|---|---|---|---|---|---|
<<FILL: T-01>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: ISO 14971 hazard ref or N/A>> |
5. Controls and residual risk summary
| Field | Entry |
|---|---|
| Threats identified | <<FILL: count>> |
| Threats with residual risk acceptable | <<FILL: count>> |
| Threats requiring further action | <<FILL: count / IDs>> |
| Residual security risk statement | <<FILL: overall acceptability and basis>> |
| Exploits that could cause patient harm | <<FILL: IDs>> reflected in ISO 14971 file ref <<FILL>> |
6. Acceptance criteria
- The threat model covers all interfaces, not only the network: physical/service ports, the update mechanism, the debug interface, the mobile app, and third-party components.
- Each credible threat has a likelihood, an impact, a control, and a residual risk.
- Every exploit that could lead to patient harm is linked to the ISO 14971 safety risk file.
- Residual security risk is stated and accepted per the security risk assessment.
- The model is versioned and scheduled for update each release.
7. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Product Security (owner) | <<FILL>> | ||
| Risk Management | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
Filled specimen
Illustrative fragment for a connected insulin-class delivery device with a companion mobile app (device and numbers illustrative).
| ID | DFD element | STRIDE | Threat | Asset | Likelihood | Impact | Inherent | Control | Residual | Safety link |
|---|---|---|---|---|---|---|---|---|---|---|
| T-03 | App to device BLE link (trust boundary) | Spoofing | A rogue app impersonates the paired phone and sends a delivery command | Therapy-control parameters | Medium | High | High | Mutual authentication + bonded pairing + command signing | Low | HAZ-11 (unintended dose) |
| T-07 | Firmware update channel | Tampering | Unsigned or downgraded firmware installed | Firmware integrity | Low | High | Medium | Signed firmware, anti-rollback version check | Low | HAZ-04 |
| T-12 | Service/debug port | Elevation of privilege | Physical attacker uses debug port to gain admin | Credentials, config | Low | High | Medium | Port disabled in production, authenticated bootloader | Low | HAZ-09 |
| T-15 | Device to cloud telemetry | Information disclosure | Intercepted telemetry exposes patient data | Patient data | Medium | Medium | Medium | TLS 1.2+ with certificate pinning | Low | N/A (privacy, no direct harm) |
Note that the model reaches past the network (T-07 update path, T-12 physical debug port), which is exactly the coverage a reviewer checks. T-03 and T-07 carry a safety-risk link because a successful exploit could harm the patient, so they also appear in the ISO 14971 file.
Common review findings this assessment prevents
- A threat model that treats the network as the only attack surface and ignores physical ports, the update path, and third-party components.
- Security risk scored on random-failure probability instead of exploitability.
- Exploits that could harm a patient not reflected anywhere in the ISO 14971 safety file.
- A one-time submission artifact never updated as the design changed.
- Controls listed with no residual-risk rating, so acceptability cannot be judged.
How to adapt this assessment
- Set your document number and attach or reference the data-flow diagram.
- Define your likelihood x impact matrix explicitly in section 3 so ratings are reproducible.
- Enumerate every interface as a DFD element before you start STRIDE; missing an interface is how threats get missed.
- Wire the safety-risk-link column to your real ISO 14971 hazard IDs.
- Add a review trigger to your change control so the model is revisited each release and on any new architecture change.