Connected medical devices are no longer a niche security concern. They are active targets, and regulators know it. The FDA’s 2023 and 2026 cybersecurity guidance makes clear that a spreadsheet of generic risks is insufficient for premarket submissions. Manufacturers need a structured method for decomposing their device architecture, identifying how each component can be attacked, and documenting what they’ve done about it. Applying the STRIDE threat model to medical devices gives that process a framework that’s both rigorous and repeatable. At Blue Goat Cyber, we’ve applied this method across hundreds of FDA submissions, and the difference between manufacturers who use it correctly and those who don’t shows up directly in review outcomes.
This article walks through all six STRIDE categories with real medical device attack scenarios, maps each category to actionable mitigation controls, explains how to structure a data flow diagram and threat model checklist, and covers exactly what FDA reviewers expect to see in your submission documentation. By the end, you’ll have a working framework you can apply to your next threat model.
What STRIDE Actually Means for Medical Device Security
The Six Categories and How They Map to Connected Device Risks
STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category represents a distinct class of attack surface rather than a generic risk label. Spoofing covers identity-based attacks, where an adversary impersonates a legitimate user or system component. Tampering addresses unauthorized modification of data, firmware, or device settings. Repudiation captures the risk of actions going unrecorded, leaving no trail to reconstruct what happened. Information Disclosure covers unauthorized access to sensitive data in transit or at rest. Denial of Service threatens device availability, which in a clinical context carries consequences far beyond inconvenience. Elevation of Privilege addresses scenarios where an attacker gains higher system access than authorized, often as a pivot point for broader compromise.
For connected medical devices, these categories translate directly to physical risk. Tampering maps to unauthorized firmware changes on an insulin pump. Denial of Service maps to disrupting drug delivery during active infusion. These aren’t abstract classifications, they describe real attack paths against real clinical systems.
Why STRIDE Fits Medical Device Threat Modeling Better Than Generic Frameworks
Generic IT risk frameworks were built for enterprise environments. They don’t account for patient safety consequences, real-time device control, or the constraints of embedded clinical systems. STRIDE was designed to decompose system components methodically, which aligns naturally with how connected medical devices communicate, store, and process data across trust boundaries. That methodical decomposition is exactly what FDA reviewers want to see.
IEC 81001-5-1, the health software security standard, integrates STRIDE threat modeling into its Secure Product Development Framework requirements. FDA’s own cybersecurity guidance references threat modeling as a core element of the SPDF and expects manufacturers to demonstrate that threat identification is embedded in the development lifecycle, not appended at the end. This approach provides the structure that satisfies both.
Applying the STRIDE Threat Model to Medical Devices: Six Categories with Real Attack Scenarios
Spoofing and Tampering: Identity and Integrity Under Attack
Spoofing in a medical device context carries immediate physical consequences. Consider an attacker who obtains stolen clinician credentials and uses them to remotely access an infusion pump management interface, modifying dosage settings without any alert to clinical staff. The harm isn’t a data breach, it’s a patient receiving the wrong dose of medication. The Animas OneTouch Ping vulnerability, documented in 2016, demonstrated exactly this: unencrypted RF communications allowed an attacker to spoof the pump’s wireless remote and trigger unauthorized insulin doses from up to 150 feet away. Johnson & Johnson issued warnings to 114,000 users as a result.
Tampering scenarios are equally credible. A glucose monitor with a compromised firmware update could report false blood sugar readings, causing a patient to under-dose or over-dose in response to inaccurate data. Supply chain data reinforces this risk: industry research has found that a significant majority of connected medical devices are affected by supply chain vulnerabilities, making tampered software updates a realistic attack vector rather than a theoretical one.
Repudiation and Information Disclosure: The Quiet Risks in Connected Care
Repudiation is the risk most manufacturers underestimate. When a clinical incident occurs and a clinician denies changing settings on an anesthesia machine, the only way to confirm or refute that claim is a complete and tamper-evident audit log. Many clinical device management interfaces lack that capability entirely. The absence of logging doesn’t just create a security gap, it creates a liability gap that surfaces during patient safety investigations.
Information Disclosure in connected devices frequently involves wireless protocols. A connected insulin pump that broadcasts unencrypted patient data over Bluetooth exposes protected health information to anyone within range running a passive listener. This isn’t hypothetical. PHI has been shown to carry significant black-market value, giving attackers clear financial motivation to intercept unprotected medical transmissions. That exposure violates HIPAA and puts patient privacy at direct, quantifiable risk.
Denial of Service and Elevation of Privilege: Availability and Access Gone Wrong
A flood attack that overwhelms a networked infusion pump’s communication stack can render the device unresponsive during active drug delivery. Research has shown that healthcare organizations affected by ransomware-style attacks frequently lose access to critical systems for hours at a stretch; see a systematic review of medical device cybersecurity impacts for deeper context. For a device maintaining continuous drug infusion, even brief unavailability can be life-threatening. Denial of Service against medical devices is a patient safety event, not an IT inconvenience.
Elevation of Privilege often serves as the entry point for lateral movement across a clinical network. An attacker who exploits a vulnerability in a vital signs monitor’s administrative interface can gain system-level access, then pivot to other networked devices in the ICU. The scale of this risk is significant: the vast majority of IoMT devices carry known exploited vulnerabilities, meaning the attack surface for privilege escalation is nearly universal in deployed hospital environments.
Mitigation Controls Mapped to Each STRIDE Category
Technical Controls for Each Threat Type
Each category maps to a specific set of technical controls. The mapping should drive engineering decisions, not just documentation. Here’s how the controls align:
- Spoofing: Mutual authentication using digital certificates; multi-factor authentication for administrative interfaces; identity verification through encrypted handshakes.
- Tampering: Cryptographic hashing for data integrity; firmware signing with verified boot chains; runtime integrity checks on critical device processes.
- Repudiation: Immutable, timestamped audit logging on all configuration changes and clinician interactions; non-repudiable event records stored separately from the device.
- Information Disclosure: End-to-end encryption for all data in transit; access-controlled data flows with documented trust boundaries; encryption at rest for stored patient data.
- Denial of Service: Rate limiting on communication interfaces; hardware and software fail-safes that maintain safe operating states under network stress; resource isolation for critical device functions.
- Elevation of Privilege: Role-based access control with least-privilege enforcement; sandboxing of application components; separation of administrative and operational access paths.
Secure Design and Process Controls Across the Device Lifecycle
Technical controls address the symptoms of poor security design. Process controls address the underlying conditions. Threat modeling integrated into early design stages catches architectural problems before they harden into firmware problems. Inserting a threat model at the end of development to satisfy a submission requirement doesn’t improve the device’s security posture, it just documents gaps that were baked in months earlier.
IEC 62304 establishes the software development lifecycle framework for medical device software. ISO 14971 governs risk management. STRIDE-based threat modeling slots directly into the hazard identification process within ISO 14971, extending it from functional safety risks to cybersecurity threats. Penetration testing tied to specific threat scenarios provides empirical evidence that identified threats are actually mitigated, not just listed. Post-market surveillance plans should include mechanisms to detect when threat profiles shift after clearance, since new vulnerabilities emerge continuously as the environment evolves.
How to Run a STRIDE Threat Model: Process and Reusable Template
Starting with a Data Flow Diagram as the Foundation
Before applying any threat categories, the team needs a complete data flow diagram. A DFD maps every external entity, process, data store, and data flow in the system. Without it, analysis produces incomplete results because analysts can only identify threats they can visualize. The DFD forces the full scope of the system onto paper before threat identification begins.
For a practical example: an insulin pump connected to a clinician dashboard via a cloud API produces a DFD with the pump as a process, the cloud API as a data flow, the dashboard as an external entity, and the cloud database as a data store. Trust boundaries sit between the device’s local wireless environment, the internet-facing API layer, and the hospital’s internal network. Each boundary marks a location where an attacker transitions between zones of different privilege or trust, and those boundaries are where STRIDE medical device security analysis is most consequential.
The MITRE Playbook for Threat Modeling Medical Devices recommends a “STRIDE per element” approach: for each DFD element, systematically ask which categories apply. The mapping follows a logical pattern. External entities face Spoofing and Repudiation. Data flows face Tampering, Information Disclosure, and Denial of Service. Processes face all six categories because they actively execute logic, handle credentials, and interact with both data and interfaces.
For each identified threat, the documentation should capture five elements: a threat description, a concrete attack scenario, a severity rating using CVSS or a similar scoring system, a control mapping that links the threat to its mitigation, and a residual risk statement. This five-part structure is the reusable artifact that an auditor or FDA reviewer examines. It demonstrates that your team didn’t just identify risks in the abstract, you traced each threat to a specific component, scored it, and documented what you did about it. That documentation persists through design iterations and is directly referenced in your risk management file. For perspective on when to choose STRIDE vs other approaches, see our comparison of DREAD vs STRIDE vs PASTA Threat Modeling for Medical Devices.
What the FDA Expects from a STRIDE-Based Premarket Submission
Evidence FDA Reviewers Evaluate in Threat Model Documentation
The FDA’s 2026 cybersecurity guidance requires manufacturers to include cybersecurity risk management documentation in all premarket submissions, covering 510(k), De Novo, and PMA pathways. Starting March 29, 2023, this became a submission requirement, not an optional supplement. As of October 1, 2023, incomplete cybersecurity sections in eSTAR submissions trigger technical screening holds before the application even reaches substantive review.
Reviewers evaluate whether the threat model identifies assets, attack surfaces, and adversary objectives at the component level. They check whether each threat carries a risk score and connects to a specific mitigation. Submissions that contain only general risk statements without component-level threat analysis routinely receive cybersecurity deficiency letters. A well-executed threat model, tied to your DFDs and mapped to ISO 14971 risk management outputs, gives reviewers the evidence chain they need. The threat model doesn’t stand alone, it integrates with your SBOM, architecture views, and cybersecurity management plan to form a complete picture of how you’ve analyzed and addressed risk across the device. For an expanded discussion of aligning threat models to FDA expectations, see Medical Device Cybersecurity Risk Analysis: The FDA Playbook.
How Specialized Cybersecurity Partners Prepare FDA-Ready Threat Model Documentation
Building STRIDE documentation that satisfies FDA review requires deep familiarity with both the regulatory framework and the specific technical architecture of the device. A generalist cybersecurity firm can produce a threat model. Whether that threat model maps correctly to FDA’s SPDF expectations, integrates with your IEC 62304 documentation, and presents residual risk in a format aligned with ISO 14971 is a separate question with real consequences for your timeline.
At Blue Goat Cyber, STRIDE analysis is built into our end-to-end premarket cybersecurity work. We integrate threat models directly into SPDF deliverables, risk management files, and eSTAR submission packages. For manufacturers without in-house cybersecurity expertise, this removes the guesswork. The threat model becomes a regulatory asset rather than an afterthought, and the risk of receiving a deficiency letter that delays clearance by months drops significantly. We’ve seen what FDA flags, and we build documentation that pre-empts those questions before they’re asked.
The Case for Doing This Right
The STRIDE threat model for medical device security is not a compliance checkbox. It’s a systematic method for understanding how your device can be attacked before that attack happens in a hospital. When you apply it correctly, with a complete DFD, per-element analysis, documented mitigation mapping, and supporting regulatory evidence, your threat model becomes one of the most valuable artifacts in your entire submission package.
Manufacturers who invest in rigorous threat modeling build safer devices. They also move through FDA review faster because reviewers can see the work. The alternative is a deficiency letter, a request for additional information, and weeks or months of delay while competitors who did the work move forward. A complete threat model is not overhead. It’s infrastructure, one that supports your design decisions and your post-market surveillance for the full lifecycle of the product.
If your team is preparing for a first submission or updating documentation for a cleared device, the framework in this article gives you a starting structure. For manufacturers who want it done thoroughly and correctly the first time, Blue Goat Cyber is built for exactly that.
Related: Medical Device Cybersecurity: A Complete Lifecycle Guide