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.

Microsoft's STRIDE threat modeling overview is a reasonable primer on the categories themselves, but it was written for enterprise software. Everything below translates the three methods into what an FDA reviewer actually reads in an eSTAR attachment.

Why this matters

Methodology choice looks like a documentation preference until you read a deficiency letter. The pattern we see repeatedly on 510(k) holds is not "you used the wrong framework," it is "the submitted threat model does not support the risk determinations in the security risk assessment." That is a traceability failure, and each of these three methods fails it in a different, predictable way.

Teams that lead with DREAD hand reviewers a spreadsheet of 1-to-10 scores with no enumeration behind it, so there is no way to confirm coverage. Teams that lead with PASTA produce a rich attacker narrative for three or four scenarios and leave 40 interfaces unanalyzed. Teams that use STRIDE badly apply the six categories to "the device" as a whole rather than per element, which produces six threats for a system that should have produced two hundred. All three outcomes generate the same cascade: the risk assessment is questioned, the pen test scope is questioned, and the security architecture views no longer match the analysis. Getting the method right up front is the cheapest hold you will ever avoid.

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)

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

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

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

What replaces DREAD for scoring

Dropping DREAD leaves a real gap: you still have to rank two hundred threat rows. The combination that holds up in review is a two-axis score kept deliberately separate.

Keep them in separate columns and show the combination rule. A CVSS 4.3 flaw that halts infusion outranks a CVSS 9.8 flaw that leaks a serial number, and a reviewer will only accept that inversion if your rationale is written down. ANSI/AAMI SW96:2023 supplies the security risk management process that wraps both axes; ISO 14971 owns the final benefit-risk call.

How Blue Goat Cyber approaches this

We run STRIDE per element against a DFD level 3 decomposition, then build three CIA attack trees to capture the multi-step chains a per-element pass will always miss. That is the PASTA contribution, kept without the seven-stage overhead. Scoring is CVSS 4.0 plus a documented ISO 14971 harm adjustment; we do not use DREAD, because its subjective five-factor rating invites a reviewer question we would rather not spend a response cycle answering.

The deliverable is an eSTAR-ready threat table with stable IDs, one row per category per element, each traced to a control, a verification test, and a patient harm. We walk it with your regulatory lead so your team can defend any row in a deficiency response. Full method in the STRIDE threat modeling guide, or see threat modeling services.

Bottom line: the FDA does not require a specific threat modeling methodology, but the three are not interchangeable. STRIDE gives you provable coverage, attack trees give you realism, and a documented safety-weighted score gives you prioritization. DREAD contributes nothing the other two do not do better.

FAQ

Does the FDA prefer STRIDE over DREAD or PASTA?

The FDA's February 3, 2026 premarket cybersecurity guidance names no required methodology, so there is no formal preference. In practice STRIDE has the lowest friction: AAMI TIR97 and the MITRE/MDIC Medical Device Threat Modeling Playbook are both built around STRIDE-style per-element analysis, so reviewers recognize the output and question the method itself far less often. Any rigorous approach is acceptable if it demonstrates coverage of every element and traces each threat to a control, a verification test, and a patient harm.

Should we still use DREAD for medical device threat models?

DREAD is a scoring rubric, not a threat enumeration method, so it cannot serve as your threat model regardless of how carefully it is filled in. As a rubric it is also weak for MedTech: its Damage, Reproducibility, Exploitability, Affected Users and Discoverability factors contain no patient-safety axis, and its 1-to-10 ratings are subjective enough that two engineers score the same threat differently. If your quality system already mandates DREAD, add an explicit clinical-impact factor and document the scoring rules. Otherwise use CVSS 4.0 for exploitability plus an ISO 14971 severity rating for patient harm, kept in separate columns.

When should we use PASTA instead of STRIDE?

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, business-risk-driven methodology that starts from attacker objectives rather than system elements. It produces deeper attack narratives but is heavy to run on every release and hard to prove exhaustive, because nothing in the process forces you to touch every interface. For a complex device ecosystem spanning firmware, mobile app, cloud, and clinician portal, the pragmatic split is to enumerate with STRIDE per element for provable coverage and borrow only PASTA's attack-simulation stage, expressed as three CIA attack trees whose leaves point back to threat IDs in the table.

How do the three methods map to an eSTAR submission?

Only one artifact is submitted: the threat model attachment, and it must contain the enumeration. STRIDE supplies the categories in that table, an attack-simulation pass supplies the multi-step scenarios, and the scoring rubric populates the pre-mitigation and residual risk columns. Security architecture views are a separate eSTAR attachment and do not substitute for the analysis; submitting diagrams in place of an enumerated threat list is a recurring deficiency.

How many threat rows should a medical device threat model contain?

A moderately connected Class II device typically produces 80 to 300 rows, because the count is driven by elements multiplied by applicable categories rather than by how many risks feel important. Fewer than about 40 rows on a connected device usually means the decomposition stopped at a level 1 diagram and the six categories were applied to the system as a whole instead of per element, which is the single most common reason a reviewer calls a threat model incomplete.

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