More than half of networked medical devices had at least one known critical flaw in 2025, and 77% of U.S. healthcare groups were hit by ransomware. So if I’m looking at medical device threat modeling, I should treat it as a lifecycle job, not a one-time design task.
Here’s the short version: this checklist walks through five phases - from concept to retirement - and shows what each phase should produce, who owns the work, and when risk shifts from the manufacturer to the healthcare delivery organization. The big point is simple: patient safety comes before data privacy, and every cyber risk should tie back to possible patient harm.
If I want the article’s core takeaways fast, they are:
- Start early: define clinical use, key assets, safety impact, and named owners before design begins
- Map the system clearly: build data flow diagrams, mark trust boundaries, and review each boundary with STRIDE
- Rank threats by patient harm: not just by technical severity
- Test what ships: use production-equivalent units for pen testing, fuzzing, code testing, and software component review
- Keep the model current: update it for patches, new CVEs, new remote access paths, and workflow changes
- Close the loop at end-of-life: remove PHI, revoke keys and certificates, document residual risk, and plan for unsupported devices
Medical Device Threat Modeling: 5-Phase Lifecycle Checklist
Threat Modeling for Medical Devices: Practical Steps for Stronger Cybersecurity
sbb-itb-535baee
Quick Comparison
| Phase | Main focus | Typical output | Main owner |
|---|---|---|---|
| Concept & Requirements | Scope, assets, safety impact and security risks, ownership | Risk plan, security requirements, early architecture sketch | Manufacturer |
| Design & Development | Data flows, trust boundaries, threat analysis, controls | Threat model, DFDs, security architecture, trace links | Manufacturer |
| Verification & Validation | Test high-risk threats and record residual risk | Pen test reports, test evidence, traceability matrix, SBOM | Manufacturer |
| Maintenance | Patching, CVEs, change control, deployment settings | Patch logs, updated SBOM, disclosure records, updated threat model | Shared |
| End-of-Life | Data removal, access shutdown, support transition | Decommission record, sanitization log, end-of-support notice | Shared, then HDO at late support stages |
The article then expands that checklist phase by phase so I can see what to document, what to test, and where accountability changes over time.
Phase 1: Concept, Requirements, and Use Case Checklist
This phase sets the ground rules. The goal is to define what the device does, which assets matter, and who owns the work before early guesses get locked into the architecture. If scope is weak here, risk tends to spread into design, validation, and support.
Define Clinical Context, Assets, and Safety Impact
Start by documenting intended use, care setting, patient population, system scope, and lifecycle workflows before the architecture is locked in. That includes update, service, and decommissioning paths too.
Be specific about the assets in play. Include therapy functions, alarms, credentials, PHI, dose data, cryptographic keys, audit logs, and connectivity services. Dose values, dose history, cryptographic keys, and audit logs are critical assets. They are not just background support data.
Then map each cyber event to patient harm and connect every credible threat to the ISO 14971 risk file. A compromised infusion pump or ventilator doesn’t just create an IT issue. It creates direct clinical risk. That means the controls need to match the level of possible patient harm. Keep each threat tied to the ISO 14971 risk file so safety and security decisions stay traceable.
Once the clinical scope is set, the next job is clear ownership for the threat model and its acceptance criteria.
Set Threat Modeling Requirements and Assign Ownership
Threat modeling should be a formal quality-system requirement, not an informal exercise. FDA QMSR-aligned guidance says cybersecurity assessments need the same level of rigor as safety risk assessments, and critical risks that remain uncontrolled for cyber devices need a fix or compensating control within 60 days [1].
Assign named owners for the threat model, risk-file integration, and change control across product, security, regulatory, and operations. Spell out trust assumptions early, including hostile networks, third-party cloud reliability, mobile platform integrity, and third-party and off-the-shelf software integration security.
Those owners should review and approve the pre-design artifacts before detailed design starts.
Required Deliverables Before Design Starts
These artifacts should be approved before detailed design begins:
| Pre-Design Deliverable | What It Should Include |
|---|---|
| Initial Architecture Sketch | Device components, external connections, and system boundaries |
| Trust Boundaries | Where data moves between trusted and untrusted zones (e.g., device to cloud, app to backend) |
| Threat Modeling Plan | Method, scope, and threat actors |
| Named Reviewers | Accountable roles across product, security, and regulatory functions |
| Acceptance Criteria | Documented thresholds for residual risk |
| Initial SBOM | Preliminary inventory of commercial, open-source, and off-the-shelf software components |
Keep these deliverables in one place so teams can track them across vendor, product, and enterprise risk workflows. Platforms like Censinet RiskOps™ support that traceability across the full device lifecycle [1].
With scope, ownership, and baseline artifacts in place, Phase 2 can map interfaces and rank threats.
Phase 2: Design and Development Threat Modeling Checklist
With scope, ownership, and baseline artifacts set in Phase 1, this is where threat modeling moves from a sketch to the nuts and bolts.
Map Data Flows, Interfaces, and Trust Boundaries
Start by turning the Phase 1 architecture sketch into a full DFD that shows components, data flows, trust boundaries, and data types [2].
That DFD should cover the whole system, not just the device itself. Include hardware like microcontrollers and sensors, software like mobile apps and cloud backends, and human roles like patients, clinicians, and remote support. Then map every inbound and outbound path: Wi-Fi, Bluetooth Low Energy (BLE), USB, serial, cellular, cloud APIs, and EHR integrations [2]. Be clear about what data moves through those paths and what data sits still, including dose history, patient credentials, and command and control signals [2].
| Documentation Element | Description | Examples |
|---|---|---|
| External Entities | Actors or systems outside the device's direct control | Patients, clinicians, EHR systems, cloud APIs |
| Data Stores | Where data is kept at rest | Local flash memory, cloud databases, app cache |
| Processes | Functions that act on data | Firmware logic, encryption services, authentication modules |
| Data Flows | The path data takes between elements | BLE payloads, TLS-encrypted cloud uploads, HTTPS portal access |
| Trust Boundaries | Points where data moves between different security levels | Device-to-phone (BLE), phone-to-cloud (internet), patient/app boundary |
Keep the DFD current. If the architecture changes, the diagram should change too. That includes a new component, a new trust boundary, or a third-party software dependency. A stale diagram leads to a stale threat model [2]. And that threat model is what you’ll use for boundary-level STRIDE analysis.
Apply STRIDE and Rank Threats by Clinical Risk
Once the DFD is done, apply STRIDE at each trust boundary instead of doing it component by component [2].
| STRIDE Category | Medical Device Example | Potential Clinical Impact |
|---|---|---|
| Spoofing | Attacker mimics a remote monitoring server | Incorrect treatment based on fake data |
| Tampering | Modifying firmware during an OTA update | Device malfunction or total loss of control |
| Repudiation | Log files deleted or never recorded | Inability to perform forensic analysis after an adverse event |
| Information Disclosure | Intercepting telemetry data over Wi-Fi | Breach of patient privacy (HIPAA violation) |
| Denial of Service | Flooding a wearable with requests to drain battery | Device becomes unavailable when needed for emergency |
| Elevation of Privilege | Accessing a debug port to change calibration | Over-delivery of medication or energy (e.g., radiation) |
After that, rank each threat with a two-dimensional matrix: likelihood of exploit on one axis, severity of patient harm on the other. This is a big deal. Cybersecurity teams should not score patient safety impact on their own. Bring in clinical specialists for that part [4][5].
In practice, a technically severe flaw may rank below a simpler exploit if that simpler exploit can hit a life-sustaining function [4][5]. That’s the shift here: you’re not just asking, “How bad is the bug?” You’re asking, “What happens to the patient if this goes wrong?”
Use that ranked threat list to drive mitigations, traceability, and verification inputs.
Document Controls, Traceability, and Method Selection
Every material threat needs a mapped mitigation. The match should be direct, not hand-wavy.
For example:
- Spoofing threats need cryptographic authentication or digital certificates.
- Tampering threats need code signing and integrity checks.
- Denial of service threats need rate limiting, traffic filtering, watchdog timers, and fault-tolerant design.
- Elevation of privilege threats should be handled with least privilege, RBAC, application sandboxing, and code reviews [6].
Those mitigations then need to move into the formal design record as design inputs. Each one should link to design outputs, verification, and validation. Cybersecurity threats should also connect straight to hazardous situations in the EN ISO 14971 risk file [2].
Method choice matters too, and it changes by lifecycle stage. Use STRIDE during design and development, PASTA during concept work, and CVSS after release.
These controls then feed Phase 3 as test cases, evidence, and deployment guidance.
Phase 3: Verification, Validation, and Operational Maintenance Checklist
Turn High-Risk Threats into Test Cases and Deployment Guidance
Use the Phase 2 threat register to shape validation tests and secure deployment requirements before release.
| Test Type | What It Targets |
|---|---|
| Penetration Testing | Simulates real-world attacks on final, production-equivalent units |
| Fuzz Testing | Uses randomized inputs to uncover crashes or memory corruption in software interfaces |
| SAST & DAST | Examines code at rest and during execution to find hardcoded credentials or logic flaws |
| SCA | Identifies third-party or open-source components and their associated vulnerabilities |
| Attack Surface Analysis | Identifies and safeguards points where threat actors may initiate an attack |
Test final, production-equivalent units only. Results from a pre-production build do not show the actual risk profile of what gets deployed in a healthcare setting.[1]
Each high-risk threat should also produce secure deployment guidance for U.S. healthcare settings. That includes:
- network segmentation requirements
- firewall rules
- required identity controls
- logging integration with the hospital's SIEM
Use that same mapping to define validation evidence and release gates.
Verify Residual Risk Acceptance and FDA-Aligned Evidence
Before production, document test evidence, mitigation status, and a residual-risk rationale for every major threat. Tie each residual risk to ISO 14971 clinical harm. The submission record should also include the threat model, security controls, SBOM with exploitability ratings, CVD process, and patching commitments.
"Cybersecurity risk assessments must happen at the same stage and with the same rigor as safety risk assessments, not as an afterthought staged before submission." - Blue Goat Cyber [1]
Under the FDA's February 2026 guidance, cybersecurity testing is a mandatory QMSR element mapped to Clause 7.3.7 as part of design validation.[1] Critical uncontrolled risks need either a fix or a compensating control within 60 days of identification, and healthcare organizations must be notified of uncontrolled vulnerabilities within 30 days.[1] After release, those same records should continue to guide patching and change control.
Keep the Threat Model Current During Patching and Change Control
The threat model should stay active through the device's full operational life. Postmarket changes should trigger these threat-model updates:
| Operational Change | STRIDE Category Affected | Required Threat Model Action |
|---|---|---|
| New third-party CVE disclosed | Tampering, Information Disclosure | Update SBOM-linked risks; verify compensating controls |
| Software patch or firmware update | Tampering, Spoofing | Verify image signing, integrity checks, and rollback protection |
| Clinical workflow change | Denial of Service | Reassess safety impact on clinical functions and alarms |
| Remote service access added | Elevation of Privilege, Spoofing | Map service-tool trust boundaries and authentication |
If a device moves into a new care setting or a new integration, go back and check the model's assumptions. Update the related trust boundaries, user roles, and network dependencies.
Track ICS-CERT advisories and H-ISAC intelligence so new CVEs trigger immediate threat model updates and patching. In early 2026, CISA warned about remote-access vulnerabilities in patient monitors, which underscores the need for immediate model updates and patching.[1]
For HDOs managing many devices and vendors, Censinet RiskOps™ can centralize assessments, remediation tasks, and benchmarking. Those maintenance records should also carry into decommissioning planning.
Phase 4: End-of-Life, Decommissioning, and Key Takeaways
Decommission Devices Without Leaving Data, Credentials, or Unmanaged Risk Behind
After patching and change control, decommissioning is the last step that clears out data, access, and leftover risk. It is not just an IT cleanup task. It is a TPLC phase with active security work.
Before a device is retired, remove sensitive data and revoke active access. That means checking that PHI, credentials, certificates, and keys are gone. If any of that stays behind, a retired unit could still be used to spoof identity or get onto the network.[3]
Manufacturers also need to give healthcare providers transition guidance and residual-risk documentation, ideally with at least two years of advance notice before end-of-support dates.[1] If a device stays in use after support ends, document the exact compensating controls in place, such as network segmentation and disabled unused ports. Then update the threat model so it shows "Limited Support" status.[1]
Use the table below to line up each end-of-life path with the control and record it needs.
| End-of-Life Scenario | Required Security Action | Documentation Needed |
|---|---|---|
| Support Ends / Continued Use | Deploy final security patch; disable remote access ports; implement network isolation/segmentation | Final SBOM, known vulnerability report, and updated threat model reflecting "Limited Support" status |
| Device Retirement | Full data sanitization (NIST 800-88); credential revocation | Certificate of destruction or sanitization log |
| Transfer of Ownership | Reset to factory defaults; remove all proprietary keys/certs | Transition guidance and residual risk disclosure |
When those steps are done, update the asset record and close the risk entry. This part matters more than it may seem. A retired device that still shows up in scans can create false confidence and leave a very real gap. Censinet RiskOps™ can centralize retired-device records and close out risk entries in enterprise risk records.
Conclusion: What a Complete Lifecycle Threat Modeling Program Should Demonstrate
A complete lifecycle threat model should leave a clean audit trail from the first design choice to the final decommissioning record.
Each phase in this checklist - concept, design, verification, operations, and retirement - should leave documented evidence showing who owned each risk decision, what controls were put in place, and what residual risk was accepted and why. That record lines up with FDA's February 2026 QMSR guidance.[1] A complete program documents ownership, controls, residual risk, and decommissioning evidence for every phase.
FAQs
When should device threat modeling begin?
Device threat modeling should start in the design phase of the medical device lifecycle.
Who owns threat modeling after deployment?
The manufacturer owns threat modeling across the entire device lifecycle - from design and deployment to maintenance and decommissioning.
That also means handling updates over time and staying responsible for risk management after deployment.
How often should the threat model be updated?
Update the threat model any time the architecture, components, trust boundaries, or data types change.
It also needs a regular review as the design shifts over time and new threats show up.
