Medical Device Threat ModelingThreat models for FDA premarket submissions and vulnerability assessments.
DFD3 data flow diagrams with trust boundaries, STRIDE per element, CIA attack trees, and an eSTAR-ready Threat Table where every row traces to a control, a test, and a patient harm. Security architecture views are a separate deliverable.
The short answer
What is medical device threat modeling?
Medical device threat modeling is the structured analysis of how an attacker could compromise a device's safety, effectiveness, or data - documented so an FDA reviewer can audit it. A reviewer-ready package decomposes the system into a DFD3 data flow diagram with trust boundaries, enumerates threats with STRIDE per element, scores each threat on exploitability and patient-safety impact rather than CVSS alone, and traces every threat to a control, a test case, and an ISO 14971 harm. The threat model is the input to the cybersecurity risk assessment and the vulnerability assessment, and it is documentation that may reuse sufficient threat-model or overlapping architecture content from the security architecture views.
275+ FDA submissions supported, zero cybersecurity rejections.
- AAMI TIR57 / SW96
- ISO 14971 + IEC 62304
- Trust boundaries mapped
- Threat → Control → Test
- Reviewer-ready
- Free 30-min call
- No obligation
- Expert-led from minute one
- Fixed-fee quote in 24 hours
- NDA available on request
Start the threat model at design
The threat model is a design input. Started at concept, it shapes which processor you choose, how firmware updates are signed, which ports stay open, and how the cloud separates one hospital's data from another's. Started 60 days before submission, it can only describe what was already built.
Threat modeling scope
What is in a threat modeling engagement?
What you get
- Architecture views with trust boundaries and data flows for the device system.
- STRIDE analysis per interface, with threats traced to security risk controls.
- Security risk scoring connected to your ISO 14971 safety risk file.
- Documentation formatted for the eSTAR cybersecurity attachments.
What we need from you
- System architecture, interface list, and intended use.
- Existing risk management file and any prior threat model.
- Access to engineers who can answer design questions.
How pricing works
Fixed fee, quoted after a scoping call. Scope depends on the number of interfaces and system elements. Risk acceptance remains a documented manufacturer decision.
Why most threat modeling fails medical devices
Generic cyber risk workshops miss what FDA reviewers care about. A useful medical device threat model must decompose the system, identify threats across the total product lifecycle, and show how controls protect safety and effectiveness.
Incomplete coverage
Missing elements, trust boundaries, entry points, or lifecycle threat sources leave reviewers unable to trace cybersecurity risk to patient safety.
Architecture diagrams passed off as a threat model
Security architecture views are documentation that may reuse sufficient threat-model or overlapping architecture content. Supplying them in place of a threat model - or the reverse - is a named deficiency pattern.
No traceability to harm
Threats with no control, no test case, and no link to a patient consequence read as narrative, not evidence.
What the threat model contains
The threat model identifies and classifies what can go wrong. It is the anchor artifact other deliverables consume - it is not the security architecture views, and it is not the cybersecurity risk assessment.
System decomposition
- DFD3 notation: external entities, processes, data stores, data flows
- Trust boundaries drawn as closed shapes, each justified
- Numbered entry points with an Entry Point Descriptions table
- Named protocols, versions, and cipher suites
STRIDE per element
- Every in-scope element walked through all six threat types
- Boundary crossings analyzed first
- Six lifecycle threat sources: supply chain through decommission
- Foreseeable misuse and abuse scenarios
CIA attack trees
- One tree each for confidentiality, integrity, availability
- Roots stated as real patient-relevant goals
- AND / OR branching to expose shared choke points
- Every leaf resolves to a Threat Table row
The Threat Table
- Minimum eight columns, eSTAR-ready
- Initial (pre-control) risk with a named mitigation strategy
- Test-case IDs that scope penetration testing
- Threat IDs that join to the cybersecurity risk assessment
What a STRIDE / AAMI threat model covers
Threat models are scoped to the data flows and trust boundaries of your system. Every element below is enumerated and each STRIDE category exercised against it before a control is proposed.
- 01External actors (clinician, patient, attacker, supply chain)
- 02Trust boundaries
- 03Data flows in / out of the device
- 04Process / component nodes
- 05Data stores (on-device + cloud)
- 06Update + key-management paths
- 07Closed-loop control surfaces
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
Our process simplifies FDA clearance
A clear path from system decomposition to a submission-ready threat model.
- 01
1 · Discovery & scoping
30-minute call to understand your device, intended use, connectivity, submission path, and current cybersecurity evidence.
- 02
2 · System decomposition
We build the DFD3 diagram: elements, data flows, trust boundaries as closed shapes, and numbered entry points with named protocols and versions.
- 03
3 · Threat identification workshop
STRIDE per element plus three CIA attack trees, with clinical, engineering, quality, and regulatory teams aligning on threats, controls, and patient harm.
- 04
4 · Threat Table & handoff
You receive the eSTAR-ready Threat Table with test-case IDs and Threat IDs that hand residual risk to the cybersecurity risk assessment.
Reviewer-ready deliverables in one engagement
Every engagement ships with documented artifacts, traceable, complete, and aligned with current guidance.
- ANSI/AAMI SW96 + ISO 14971 alignment
- Full medical device system coverage
- Threat-to-mitigation traceability
- Justified methodology and assumptions
Public premarket cybersecurity history
Recalls, CISA ICS-MA advisories, and disclosed research that shape what reviewers ask about, and what this engagement is built to cover.
- the FDA·2024-2026
Architecture View and STRIDE gap as recurring deficiency
CDRH deficiency letters in this period consistently call out threat models that fail to enumerate trust boundaries, miss the update channel as an element, or stop at network and ignore internal buses. The 2026 final guidance is more explicit on each.
"Blue Goat's knowledge of regulatory requirements versus cybersecurity challenges was highly valuable and readily apparent as we were guided by and worked alongside their team towards the development of a comprehensive and compliant cybersecurity plan for our new medical device. Especially helpful for our company as we are a startup. Their team and competencies nicely filled our resource needs. Thank you Blue Goat!"
Medical Device Threat Modeling for these segments
See how this service applies to your specific MedTech segment.
Resources on this topic
Curated reading for teams working on threat modeling - grouped by format so you can jump to what you need.
Guides
3Long-form reference reading, architecture, frameworks, and end-to-end how-tos.
Articles
6Shorter posts on the specific gotchas, deficiencies, and reviewer expectations we see most.
Try the free tool first.
Pressure-test the work yourself before you scope an engagement. No signup, results are yours to keep.
Questions medical device teams ask before threat modeling
What is medical device threat modeling and why does FDA care?
Threat modeling is the structured analysis of how an attacker could compromise your device's safety, effectiveness, or data. The FDA's February 2026 premarket cybersecurity guidance, AAMI TIR57, and ANSI/AAMI SW96 all expect a threat model that ties cybersecurity risk to patient safety - not a generic IT checklist. Reviewers look for documented assets, trust boundaries, attack paths, mitigations, and residual risk traced to your ISO 14971 hazard analysis. Without that linkage, expect an Additional Information request.
Is the threat model the same as the security architecture views?
No. They are separate eSTAR attachments with separate jobs. The threat model identifies and classifies threats and produces the Threat Table. The security architecture views (global system, multi-patient harm, updateability and patchability, security use cases) illustrate the boundaries and interfaces the model draws. The views derive from the model; they do not replace it, and a submission that supplies one in place of the other draws a deficiency. We produce both, but they are scoped, priced, and reviewed separately - the views are delivered under our premarket cybersecurity service.
Do you align with the latest FDA cybersecurity guidance?
Yes. Every engagement aligns with the FDA's February 2026 final premarket cybersecurity guidance and Section 524B of the FD&C Act. Artifacts are built to the standards reviewers cite in deficiency letters: AAMI TIR57, AAMI TIR97, ANSI/AAMI SW96, ISO 14971, IEC 62304, IEC 81001-5-1, NIST 800-30, MDCG 2019-16, and the QMSR (21 CFR Part 820). The threat model, SBOM, and labeling are formatted for eSTAR submission so your regulatory team can drop them straight into the package.
Can you work with our existing QMS and regulatory team?
Yes. We deliver evidence in formats your QMS can absorb - ISO 13485 / QMSR-friendly templates, version-controlled artifacts, and traceability that maps to your design history file. We collaborate directly with regulatory, quality, clinical, and engineering stakeholders, attend your design reviews, and produce the threat model in a format that drops into your submission narrative without rework. If you use Jama, Polarion, Helix ALM, or a similar requirements tool, we'll deliver in a format that round-trips cleanly.
Do you support 510(k), De Novo, PMA, PDP, and HDE submissions?
Yes. We tailor the depth of the threat model and supporting evidence to the pathway, device class, and connectivity profile. For IDE submissions we focus the package on cybersecurity risks that could affect study-subject safety - a threat model with clinical-environment assumptions and a security risk assessment that gives the reviewer enough confidence to avoid a Clinical Hold under 21 CFR 812.42. For 510(k), De Novo, and PMA we deliver the full Section 524B / February 2026 guidance package that drops into eSTAR or PMA modular content.
What do you need from our team to get started?
A 30-minute discovery call, then access to your current architecture diagrams, intended use statement, indications for use, interface inventory, third-party component list or draft SBOM, and any existing risk or cybersecurity documentation. We also benefit from a short technical walkthrough with engineering. We bring the methodology, templates, regulatory mapping, and the senior threat modeler who runs the engagement end to end - so your team isn't asked to learn AAMI SW96 on a deadline.
How long does a typical threat modeling engagement take?
Most engagements complete in 3-6 weeks depending on system complexity, number of interfaces, connectivity profile (BLE, Wi-Fi, cellular, cloud), and how much existing documentation we can build on. Single-interface devices often finish closer to three weeks; multi-component connected platforms with cloud back-ends and mobile apps run closer to six. We provide a fixed-fee quote and a written timeline within 24 hours of the scoping call - no hourly billing and no scope creep.
What if FDA issues a cybersecurity deficiency?
We handle that too. Our deficiency-response service rebuilds or extends the threat model to address reviewer feedback within the 180-day deficiency clock, and existing threat modeling clients get priority response. The work typically includes a targeted re-analysis of the cited gap, additional attack paths or misuse cases as needed, updates to the security risk assessment, and a written response narrative the reviewer can follow line by line. Most deficiency packages turn around in 2-4 weeks.
Do you include security risk traceability?
Yes. Every identified threat is mapped to its control, the cybersecurity risk assessment entry, the test or evidence that validates the control, the residual risk after mitigation, and the corresponding safety risk in your ISO 14971 hazard analysis. The traceability matrix is delivered as a structured artifact (typically a controlled spreadsheet or requirements-tool export) so reviewers can follow the chain from threat to test to residual risk without manual cross-referencing - which is exactly what they look for under AAMI TIR57.
Can you support teams that already have a threat model?
Absolutely. Many of our engagements begin as gap assessments against an existing threat model. We benchmark the current artifact against the February 2026 FDA guidance, AAMI TIR57, and ANSI/AAMI SW96, identify missing coverage (most often lifecycle threat sources and multi-patient harm paths), rework trust boundaries that are too coarse, add the misuse-case and abuse-case analysis, and refresh the safety-impact mapping. You keep your existing artifact as the baseline; we make it submission-ready.
Threat models FDA reviewers accept - and engineers will maintain.
DFD3 data flow diagrams with trust boundaries, STRIDE per element, CIA attack trees, and an eSTAR-ready Threat Table where every row traces to a control, a test, and a patient harm. Security architecture views are a separate deliverable.