Explain System and Identify Threats
A comprehensive threat model must clearly describe the medical device system and identify potential threats throughout its entire lifecycle, from concept to postmarket.
This guide provides actionable tips for medical device manufacturers to perform threat modeling that meets FDA expectations and ensures the cybersecurity of their devices across the entire product lifecycle.
Select a letter on the wheel to jump to its MedTech example.
Forging a clinician identity to a connected pump.
Altering pacing parameters on an implantable device.
Removing audit traces of an unauthorized firmware push.
PHI leak from an unsecured DICOM share.
Ransomware locks the imaging fleet mid-care.
Service-mode menu reached without authentication.
A comprehensive threat model must clearly describe the medical device system and identify potential threats throughout its entire lifecycle, from concept to postmarket.
Ensure your threat model covers all critical aspects like assets, trust boundaries, update mechanisms, and clinical workflows to avoid gaps that could compromise patient safety or lead to reviewer concerns.
Beyond engineering diagrams, your documentation should satisfy FDA expectations by detailing security architecture, assumptions, residual risks, and clear traceability of controls to patient safety.
Link identified threats directly to potential impacts on patient safety, including compromise of device availability, therapy delivery, diagnostic integrity, or multi-patient safety.
Develop submission-focused documentation tailored to the latest FDA cybersecurity guidance and reviewer expectations to avoid rewrites and streamline the submission process.
Connect threats to exploitability, true residual risk, safety impact, and foreseeable misuse, not just traditional confidentiality concerns.
Include views for the global system (device, cloud, networks), multi-patient harm scenarios, patchability (update paths, authenticity), and specific security use cases (programming, alarming, therapy delivery).
Utilize SBOM-informed threats, assess third-party software risks, and identify end-of-support assumptions and supplier-control gaps within your threat model.
Map threats to controls, cybersecurity risk assessments, testing evidence, residual risk, and relevant safety files for a complete and traceable risk story.
Apply STRIDE (Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation) to each external interface separately — Wi-Fi, Bluetooth, USB, serial, cloud API, service port. A single device-level STRIDE table is too coarse for reviewers under the Feb 2026 guidance.
Beyond STRIDE, document misuse cases (legitimate features used incorrectly) and abuse cases (malicious actors chaining features). For AI/ML devices, add adversarial ML abuse cases: evasion, poisoning, model inversion, membership inference.
Authoritative guidance and standards underpinning this topic. Always confirm the latest revision with the publisher.
Quick answers to the questions teams most often ask about this topic.
Threat modeling is a structured analysis of how a device could be attacked, what could go wrong, and what mitigations reduce the risk. For medical devices, it must link cybersecurity threats to patient-safety consequences and inform both design and testing.
STRIDE is the most widely used and the one FDA reviewers most often see. LINDDUN (privacy) and PASTA (business-risk-driven) are useful complements. The FDA does not mandate a specific methodology, but expects the model to be systematic, documented, and traceable to controls.
Yes. Each interface (network, Bluetooth, USB, service port, cloud API) has its own trust boundary and attack surface. A single site-wide threat model that lumps interfaces together will draw FDA questions.
Cybersecurity threats are inputs into your ISO 14971 risk management file. Each threat maps to one or more hazardous situations with potential patient harm, and each mitigation becomes a risk control that must be verified.
Start in design (before hardware freeze), refresh at every major architectural change, and update on every material change to interfaces, dependencies, or clinical workflow. It is not a one-time submission artifact.
Jump to all guides for the lifecycle phase that fits where you are.