Threat Model Starter
Pick the interfaces your device exposes and the assets it protects. We generate a STRIDE threat register with abuse cases, safety impact, and mitigations mapped to AAMI TIR57 / ANSI-AAMI SW96 control IDs - ready to drop into your formal threat model.
Reviewed by
Christian Espinosa
Founder & CEO, Blue Goat Cyber
Communication and physical interfaces
Each interface adds its own seeded STRIDE threats with mitigations and control IDs.
Wireless
Wired / physical
Cloud / app
Update / service
High-value assets
Adds asset-centric threats (e.g. signing-key disclosure, model poisoning, audit-log tampering).
What you'll see after you submit
Interfaces + assets → threats, abuse cases, safety impact, mitigations, control IDs
- 17 interface entries spanning Wi-Fi, Cellular, BLE, Bluetooth Classic, NFC, RFID, USB data, USB-OTG, Serial/CAN, JTAG/SWD/UART, removable media, paired phone, vendor cloud API, companion app, clinician portal, and OTA.
- 8 high-value asset categories with their own threat seeds: PHI, AI/ML model weights, firmware-signing key, audit log, session token, calibration parameters, pairing keys, telemetry.
- Every threat carries an abuse case, an ISO 14971 safety-impact note, mitigations, and traceable control IDs (AAMI TIR57, ANSI/AAMI SW96, IEC 81001-5-1, FDA 2025 Final).
- Heatmap, severity counters, and a machine-readable JSON export ready to feed your formal threat model or GRC system.
Common misconceptions
What teams usually get wrong
-
Myth: Threat modeling is a one-time premarket deliverable.
Reality: The FDA expects the threat model to be a living artifact - updated on architecture changes, new interfaces, and significant CVEs. Submit the latest version with every supplement.
-
Myth: STRIDE is for IT systems, not medical devices.
Reality: AAMI TIR57 and the current FDA premarket cybersecurity guidance explicitly cite STRIDE (and DREAD / attack trees) as acceptable medical-device threat-modeling frameworks. The categories map cleanly to safety and effectiveness.
-
Myth: If we have a risk file (ISO 14971), we don't need a threat model.
Reality: ISO 14971 captures safety risk from hazards. A threat model captures security risk from adversaries. The FDA expects the two to be linked but distinct artifacts, with traceability between them (TIR57 §6.2).
-
Myth: An exported diagram is enough.
Reality: Reviewers want the rationale: why each interface is in scope, why each threat is rated, and which control mitigates it. Diagrams without a narrative get deficiency letters.
-
Myth: Wireless threats only matter for Wi-Fi and Bluetooth.
Reality: NFC tap-to-configure, UHF RFID consumable authentication, and rogue cellular base stations are all reviewer-relevant attack surfaces. If your device exposes them, they belong in the threat register.
References & further reading
Primary sources behind this tool
- AAMI TIR57:2016/(R)2023 - Principles for Medical Device Security: Risk Management - AAMI
- ANSI/AAMI SW96:2023 - Standard for Medical Device Security - AAMI
- IEC 81001-5-1:2021 - Health software and health IT systems safety, effectiveness, and security - IEC
- STRIDE Threat Modeling Methodology - Microsoft Security Engineering
- Playbook for Threat Modeling Medical Devices - MITRE / MDIC
Recent regulatory + supply-chain activity
Tracked signals that change what reviewers expect. Items move on as new ones land.
From starter register to formal threat model.
Threat modeling services
STRIDE/PASTA threat models with traceability into design inputs and the risk file.
Learn moreSTRIDE for medical devices
How reviewers expect STRIDE applied to a cyber device.
Learn moreFDA premarket cybersecurity
Full SPDF + eSTAR-ready submission.
Learn moreMore tools
PCCP, 524B checker, SBOM readiness, pen-test scope.
Learn more