DREAD vs STRIDE vs PASTA Threat Modeling

Threat modeling is one of the highest-use activities in medical device cybersecurity. Done well, it helps you identify realistic abuse cases early, design effective controls, and produce evidence that holds up across the product lifecycle.

When MedTech teams ask which method is “most effective,” the most practical answer is this: STRIDE is the industry-default baseline (not an FDA-mandated one) because it is structured, repeatable, and fits naturally with architecture and data flow diagrams. From there, many teams enhance STRIDE with attack-path thinking (PASTA-style) and a lightweight prioritization method to drive execution.

If you want a good starting reference for STRIDE, Microsoft’s overview is a solid baseline:

Microsoft: STRIDE threat modeling overview).

Why this matters

Effective medical device threat modeling is crucial for patient safety and regulatory compliance. The FDA's 'Cybersecurity in Medical Devices' Final Guidance, dated February 3, 2026, emphasizes the need for manufacturers to integrate cybersecurity throughout the product lifecycle, starting with design. Threat modeling directly supports this by enabling early identification of potential vulnerabilities, making it possible to design controls proactively rather than reactively patching weaknesses. This not only reduces development costs but also diminishes the likelihood of post-market recalls or security incidents. Without thorough threat modeling, medical devices face heightened risks of data breaches, unauthorized access, or denial-of-service attacks, all of which can jeopardize patient care. Adherence to standards like IEC 81001-5-1 and AAMI TIR57 / ANSI/AAMI SW96:2023 also mandates systematic risk management, making threat modeling an indispensable practice. It provides the structured evidence needed for regulatory submissions and demonstrates due diligence, safeguarding both manufacturers and patients from cyber threats.

Quick Definitions

• STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a structured way to identify threat categories across a system design.
• DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) is a historical scoring model used to prioritize risk using a set of factors.
• PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric framework that emphasizes attack simulation and traceability from objectives to threats and mitigations.

Why STRIDE Is Often Preferred in Medical Device Cybersecurity

STRIDE tends to be the best “default” for medical device teams because it:

• scales across ecosystems (device, mobile app, cloud, portal, gateway, remote support, service tooling)
• pairs well with data flow diagrams and trust boundary mapping
• provides consistent coverage so teams don’t miss entire categories of threats
• is teachable to cross-functional teams (engineering, QA, RA/QA, IT/OT, product)

The key is to avoid stopping at labels. STRIDE becomes truly effective for MedTech when you translate each threat into:

• abuse cases (what an attacker would try to do), then
• security requirements (what must be true to prevent it), then
• verification evidence (how you prove it works).

For teams looking for practical threat modeling resources and templates, OWASP has a good hub:

OWASP: Threat Modeling.

What Medical Device Teams Actually Need From Threat Modeling

No matter which framework you pick, “good” threat modeling in MedTech usually means you can answer:

• What are the trust boundaries across the device ecosystem?
• What are the highest-risk abuse cases for safety, effectiveness, confidentiality, integrity, and availability?
• What controls reduce those risks?
• What tests and evidence prove the controls are implemented and effective?
• What’s the postmarket plan for monitoring, vulnerability intake, and remediation?

Threat modeling also supports secure development expectations. A helpful reference here is the

NIST SP 800-218 Secure Software Development Framework (SSDF),

which provides a practical structure for secure-by-design practices and evidence.

STRIDE for Medical Devices

Example: STRIDE applied to a connected medical device

Before applying STRIDE, most teams start with a data flow diagram (DFD) that shows components, protocols, and trust boundaries. Below is a simplified example for a connected wearable ecosystem. Each component gets analyzed against all six STRIDE categories, and trust boundaries mark where authentication, integrity checks, and input validation must be enforced.

About the two trust boundaries. This teaching diagram draws boundaries at the two places where the owner, physical control, and network of the data all change at once: between the patient-owned wearable/phone (Zone 1–2, untrusted personal environment) and the vendor-operated cloud (Zone 3), and again between the cloud and the hospital-operated clinician portal (Zone 4, a different user population on a different network). Every arrow that crosses a dashed line is where authentication, integrity checks, input validation, and logging must be enforced, those crossings are where STRIDE findings almost always cluster.

What a real production DFD would add. A submission-grade DFD typically expands this in five ways: (1) more granular processes inside each zone (auth service, telemetry ingestion, firmware update service, audit log writer shown as separate circles rather than one "API Service"); (2) explicit data stores for PHI, credentials/keys, audit logs, and OTA update artifacts (each drawn as parallel lines and analyzed for Tampering and Information disclosure separately); (3) additional trust boundaries around the secure element on the device, the mobile app sandbox, and any third-party/SaaS dependency (analytics, SMS, email); (4) out-of-band flows that teams often forget, such as service/debug ports, factory provisioning, remote support sessions, and OTA rollback paths; and (5) a data classification tag on every flow (PHI, PII, telemetry, control command, config) so reviewers can trace how each class is protected end to end.

STRIDE walkthrough at each trust boundary

The table below walks the two trust boundaries in the diagram above (Wearable/Mobile crossing into Cloud, and Cloud crossing into Clinician Portal) and gives one representative threat and mitigation per STRIDE category. In a real threat model each cell would expand into multiple entries, each traced to a security requirement and a verification test.

Boundary 1: Wearable + Mobile App → Cloud API (BLE, then HTTPS/TLS)

Boundary 2: Cloud API → Clinician Web Portal (REST/OAuth, HTTPS/SSO)

See also: TARA for Medical Devices: FDA Premarket, Data Flow Diagrams for Medical Device, and Brainjacking: The Real Cyber-Physical Threat to NeuroTech.

Where STRIDE shines

• Design-phase clarity: STRIDE works cleanly with architecture diagrams and data flow diagrams.
• Coverage: It helps teams avoid missing threat categories.
• Repeatability: It’s easy to apply consistently across products and releases.

Where STRIDE needs help

• Prioritization: STRIDE identifies threats, but it doesn’t rank them by impact or urgency.
• Execution: without conversion to requirements and tests, STRIDE can become a “list exercise.”

Best MedTech use: Run STRIDE at each trust boundary and interface (pairing, authentication, updates, APIs, remote support, service mode, configuration changes). Capture outputs as abuse-case statements, not just STRIDE categories.

DREAD for Medical Devices

DREAD is most helpful as a lightweight discussion tool for prioritization-especially when you’re trying to sort a backlog. However, it can be subjective and may not naturally account for clinical impact or patient safety context unless you adapt it.

Best MedTech use: If you use DREAD, adjust it. Add explicit factors for patient safety/clinical impact, detectability, and response capability. Use it to drive decisions, not to win debates about scoring.

If your team wants a standard approach for vulnerability severity scoring (separate from threat modeling), CVSS is widely used:

FIRST: Common Vulnerability Scoring System (CVSS).

PASTA for Medical Devices

PASTA is strong when you need end-to-end realism and traceability-especially for complex systems (device + cloud + mobile + portal + service workflows). The tradeoff is overhead: PASTA can be heavier than many teams need for every product iteration.

Best MedTech use: Use PASTA concepts-especially attack simulation-to enhance a STRIDE baseline. Reserve full PASTA for higher-risk products or complex ecosystems where deep traceability is required.

Which Is Most Effective for Medical Device Cybersecurity?

For most medical device teams, the most effective and sustainable approach is:

• STRIDE as the default baseline for consistent coverage and repeatability.
• PASTA-style attack paths to keep the model realistic across the entire ecosystem.
• Lightweight prioritization (DREAD-like or custom) to drive execution and remediation planning.

Recommended STRIDE-First Workflow for MedTech Teams

1. Define the system: device, app, cloud, portal, gateway, remote support, service tooling, manufacturing/test.
2. Map trust boundaries: identify where trust changes and where untrusted input enters.
3. Run STRIDE per boundary: capture threats as abuse cases with attacker goals.
4. Simulate 5-10 attack paths: chain realistic steps across components (PASTA-style thinking).
5. Convert to testable requirements: authentication, authorization, integrity, logging, segmentation, update security.
6. Prioritize: rank by safety impact + likelihood + detectability + feasibility of remediation.
7. Verify and trace: map abuse cases → requirements → test cases → results.
8. Operationalize postmarket: monitoring, vulnerability intake, patch workflow, coordinated disclosure.

Medical Device Threat Modeling Checklist

• We have a clear architecture and data flow view of the entire device ecosystem.
• Trust boundaries are documented and reviewed as the design changes.
• Threats are documented as abuse cases (not just STRIDE labels).
• Each high-risk abuse case maps to testable security requirements.
• Verification evidence exists (tests/results) tied to those requirements.
• Postmarket processes exist for monitoring, vulnerability intake, and patching.

Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.

How Blue Goat Cyber Helps

Blue Goat Cyber helps medical device teams build STRIDE-first threat models that lead to real outcomes: security requirements, verification evidence, and postmarket readiness across the full device ecosystem.

• Medical Device Threat Modeling
• Medical Device Vulnerability & Penetration Testing
• Premarket Cybersecurity Services
• Postmarket Cybersecurity Management
• Contact Blue Goat Cyber

Bottom line: The FDA does not require a specific threat modeling methodology. STRIDE has become the industry-default baseline for medical devices, and the most effective MedTech programs pair it with realistic attack paths and a practical prioritization step, then prove controls with verification evidence.

FAQ

Does the FDA prefer STRIDE over DREAD or PASTA?

No. The FDA's Feb 3, 2026 premarket cybersecurity guidance is methodology-neutral. STRIDE is the industry default and what reviewers see most often, but any documented, defensible methodology is acceptable as long as it produces traceability from threats to controls to verification evidence.

Should we still use DREAD?

DREAD can help with prioritization discussions, but it is subjective and often needs adaptation for MedTech, especially to include patient safety and clinical impact.

When should we use PASTA?

Use PASTA concepts (attack simulation) to enhance STRIDE for realism. Consider full PASTA for complex ecosystems or higher-risk products where traceability is critical.

Does the FDA require a specific threat modeling methodology?

No. The FDA's February 3, 2026 premarket cybersecurity guidance requires a threat model but is methodology-neutral. Reviewers expect traceability from threats to controls to test evidence, which STRIDE, DREAD, and PASTA can each support when applied consistently across the SPDF.

External References (Trusted Resources)

• Microsoft: STRIDE threat modeling overview)
• OWASP: Threat Modeling
• NIST SP 800-218: Secure Software Development Framework (SSDF)
• NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline
• MITRE: CWE Top 25 Most Dangerous Software Weaknesses
• FIRST: Common Vulnerability Scoring System (CVSS)

Related on threat modeling

• STRIDE threat modeling for medical devices: the complete playbook
• Threat trees vs attack trees for FDA submissions
• Step-by-step threat modeling for connected & implantable devices