Threat Modeling
for Medical Devices
FDA's premarket cybersecurity guidance expects a threat model as part of your 510(k), PMA, or De Novo submission, covering the device's architecture, interfaces, and exploitable vulnerabilities. ThreatTree gives your team a structured place to build that model and the risk assessment behind it.
Submission expectations, mapped to ThreatTree
FDA's guidance describes several cybersecurity documentation elements. Here is where each one fits in a ThreatTree forest.
| Guidance expects | In ThreatTree | |
|---|---|---|
| 1 | Global system view Device, its components, and how it connects to the wider system (network, EHR, companion apps) |
A Data Flow Diagram tree covering the device, its interfaces, and external entities, with trust boundaries around each connection |
| 2 | Multi-patient harm view How a single compromised device or component could affect multiple patients |
Attack Trees tagged with impact severity, decomposed down to the shared component or service an attacker could pivot through |
| 3 | Threat modeling & vulnerability identification Systematic identification of exploitable threats against the device |
STRIDE tagging across every DFD element, with Attack Trees decomposing each threat into AND/OR attack steps tagged with CAPEC and MITRE ATT&CK |
| 4 | Risk assessment Likelihood and severity of patient harm from each identified threat |
Likelihood x Impact scoring generates a ranked risk register automatically across the forest |
| 5 | Submission documentation Evidence reviewers can trace from architecture to threat to mitigation |
Export the forest as a PDF report with architecture, attack trees, and risk register as a submission appendix, or as JSON for your document management system |
What this is, and isn't: ThreatTree is a threat modeling tool, not regulatory counsel or a substitute for your quality and regulatory affairs team. It helps you build and document the threat model and risk assessment artifacts FDA's guidance describes -- whether a specific submission satisfies FDA's requirements is a determination your regulatory team and FDA reviewers make, not something this page or product can guarantee.
Evidence reviewers can trace, end to end
Every threat traces back to a device component, and every mitigation traces back to a rated attack path.
-
Architecture-Anchored Threats
Model the device, its embedded components, wireless interfaces, and connections to EHRs or companion apps as DFD elements. Every threat is grounded in a real interface, not a floating assumption.
-
Attack Path Decomposition
Break each threat into an Attack Tree with AND/OR logic, from attacker goal to atomic step, so reviewers can see exactly how a device could be compromised and where the mitigation sits.
-
Prioritized Risk Register
Likelihood x Impact scoring generates a ranked risk register automatically across every tree in a forest, weighted toward patient safety impact.
-
Submission-Ready PDF Reports
Generate a report with architecture views, attack trees, and a ranked risk register in a single PDF -- built to sit as an appendix in a 510(k), PMA, or De Novo submission.
Medical device threat modeling, answered
What device manufacturers ask before adopting ThreatTree for premarket cybersecurity documentation.
Does ThreatTree guarantee my FDA submission will be accepted?
No. ThreatTree is a threat modeling tool, not regulatory counsel or a substitute for your quality and regulatory affairs team. It helps you build and document the threat model and risk assessment artifacts FDA's premarket cybersecurity guidance describes -- what satisfies a specific submission is a determination your regulatory team and FDA reviewers make.
Does ThreatTree generate a Software Bill of Materials (SBOM)?
No. ThreatTree focuses on the threat model and risk assessment, not SBOM generation. It's designed to complement a dedicated SBOM tool -- reference your components as DFD assets and link the threats that apply to them.
Can ThreatTree produce the architecture views FDA guidance asks for?
ThreatTree's Data Flow Diagrams cover the global system view and multi-patient harm view -- device components, interfaces, and data flows between them. Update and patchability views describe your deployment process rather than your architecture, so those typically live in your quality system documentation, not the threat model itself.
Who on our team should own the ThreatTree forest?
Most manufacturers have their security/systems engineering lead own the forest and invite regulatory affairs as viewers, so risk register updates stay traceable to one source instead of being re-transcribed into submission documents by hand.
Start your device threat model in ThreatTree
Free plan available -- no credit card required. Be up and running in minutes.