Skip to main content
    MedTech Cyber Tips
    The Ultimate Guide
    All topics
    Concept · Premarket

    Threat Modeling for Medical Devices

    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.

    For: Medical device manufacturers, regulatory, quality, and engineering teams. 7 min readLast updated · yesterday
    By · Reviewed by MedTech Cyber Tips Editorial Team·Last reviewed July 2026
    STRIDE for medical devices

    Six threat categories, mapped to real-world device risk

    Select a letter on the wheel to jump to its MedTech example.

    • SSpoofing

      Forging a clinician identity to a connected pump.

    • TTampering

      Altering pacing parameters on an implantable device.

    • RRepudiation

      Removing audit traces of an unauthorized firmware push.

    • IInformation disclosure

      PHI leak from an unsecured DICOM share.

    • DDenial of service

      Ransomware locks the imaging fleet mid-care.

    • EElevation of privilege

      Service-mode menu reached without authentication.

    12 structured tips

    The walk-through

    01
    Documentation

    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.

    02
    Process

    Address Incomplete Threat Modeling

    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.

    03
    Documentation

    Provide Compliant Documentation

    Beyond engineering diagrams, your documentation should satisfy FDA expectations by detailing security architecture, assumptions, residual risks, and clear traceability of controls to patient safety.

    04
    Strategic

    Connect Threats 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.

    05
    Compliance

    Align with Key Compliance Standards

    Ensure your threat model and report align with FDA 2026 Guidance, AAMI TIR57, ISO 14971, IEC 62304, and other relevant medical device cybersecurity standards.

    06
    Documentation

    Focus on FDA-Ready Documentation

    Develop submission-focused documentation tailored to the latest FDA cybersecurity guidance and reviewer expectations to avoid rewrites and streamline the submission process.

    07
    Strategic

    Incorporate Security and Safety Risk Logic

    Connect threats to exploitability, true residual risk, safety impact, and foreseeable misuse, not just traditional confidentiality concerns.

    08
    Technical

    Build Comprehensive Architecture Views

    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).

    09
    Technical

    Integrate Supply Chain Risk

    Utilize SBOM-informed threats, assess third-party software risks, and identify end-of-support assumptions and supplier-control gaps within your threat model.

    10
    Process

    Ensure Risk Traceability

    Map threats to controls, cybersecurity risk assessments, testing evidence, residual risk, and relevant safety files for a complete and traceable risk story.

    11
    Process

    STRIDE Per Interface

    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.

    12
    Process

    Include Misuse and Abuse Cases

    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.

    Common pitfalls

    • Missing assets, trust boundaries, update paths, or clinical workflows can lead to incomplete threat models that fail to satisfy FDA reviewers and may compromise patient safety.
    • Relying solely on engineering diagrams for documentation, without clear narratives on security architecture, assumptions, residual risk, and control traceability, will not meet FDA expectations.
    • Generic cyber risk workshops, which do not specifically address medical device safety and effectiveness, will likely miss critical aspects that FDA reviewers care about.
    • Overlooking threats related to device availability, therapy delivery, diagnostic integrity, or multi-patient safety can increase patient risk.
    • Failing to align threat models with recognized medical device compliance standards such as FDA 2026 Guidance, AAMI TIR57, and ISO 14971 will result in non-compliant documentation.

    Your next steps

    1. 1Conduct a discovery session to align on your device's specifics, intended use, submission path, and existing cybersecurity evidence.
    2. 2Perform an architecture intake to thoroughly map assets, interfaces, trust boundaries, data flows, users, clinical states, update paths, and operating environments.
    3. 3Facilitate a threat modeling workshop with clinical, engineering, quality, and regulatory teams to gather input on threats, assumptions, misuse cases, controls, and safety impact.
    4. 4Develop an FDA-ready package including diagrams, rationale, risk traceability, mitigation recommendations, and submission-ready narrative support.

    Sources & references

    Authoritative guidance and standards underpinning this topic. Always confirm the latest revision with the publisher.

    Frequently asked questions

    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.

    Continue by phase

    Jump to all guides for the lifecycle phase that fits where you are.