12 Critical Threat-Modeling Gaps in Submissions

Threat Modeling • Medical Devices • FDA Premarket • STRIDE-aligned

A practical, ungated guide to the threat modeling gaps that trigger FDA cybersecurity questions, mapped to STRIDE so each gap closes a specific class of threat reviewers expect to see addressed.

← All Guides · Our Threat Modeling Service · STRIDE methodology guide

Why Threat Modeling Is Now a Gating Activity, Not a Checkbox

The FDA 2026 Premarket Cybersecurity Guidance (aligned to Section 524B of the FD&C Act) requires a documented threat model that drives security risk management, architecture views, SBOM traceability, and testing evidence across the total product lifecycle. Reviewers are no longer asking whether you threat-modeled - they are asking which methodology you used, which threats you missed, and how each control was verified.

The patterns repeat. Across connected medical device submissions, the same 12 gaps appear again and again - and each maps cleanly to one or more STRIDE categories. Use this guide to pressure-test your threat model before pre-submission, 510(k), De Novo, PMA, or IDE documentation is finalized.

STRIDE in 30 Seconds

If you are not already framing your threat model with STRIDE, do it now - it is the categorisation reviewers default to and the one referenced in AAMI TIR57 / ANSI/AAMI SW96:2023 supporting material.

Letter	Threat	What it attacks
S	Spoofing	Authenticity of identity (users, devices, services)
T	Tampering	Integrity of data, firmware, configuration, traffic
R	Repudiation	Ability to prove who did what (audit, logging, signing)
I	Information disclosure	Confidentiality of PHI, credentials, IP, model weights
D	Denial of service	Availability of therapy, monitoring, alarming, updates
E	Elevation of privilege	Authorisation boundaries (service, debug, admin, kernel)

Every gap below carries a STRIDE tag indicating which categories the gap typically leaves under-covered. A complete threat model produces evidence in all six categories for each trust boundary.

How to Use This Guide

Read each gap as a self-assessment against your current architecture package. Use the STRIDE tags to spot lopsided coverage (most submissions over-index on T and I and under-cover R, D, and E). Where a gap exists, update both diagrams and explanatory text so the reviewer can follow the risk story end-to-end.

Owners: Engineering · Quality & Regulatory · Security · Submission Writers.

The 12 Most Common Critical Gaps

1. Missing Global System View

STRIDE: S, T, I, D, E (every category - you cannot threat-model what you have not drawn).

What we see: The submission describes the device, but not the device plus cloud, mobile app, hospital network, update server, service tools, users, and external dependencies.

How to fix it: Create a full medical device system diagram with assets, interfaces, trust boundaries, data flows, user roles, and environment-of-use assumptions. Each trust boundary should be explicitly enumerated against all six STRIDE letters.

2. No Hostile-Network Assumption

STRIDE: S, T, I (spoofed peers, tampered traffic, eavesdropping).

What we see: Threats are scoped as if hospital or home networks are trusted, even though FDA recommends assuming adversaries can alter, drop, and replay traffic.

How to fix it: Document the hostile-network assumption and map controls for authenticity (mTLS / signed messages), integrity (MAC / signatures), confidentiality (TLS 1.2+), availability (rate limiting, watchdog), and replay protection (nonces, monotonic counters).

3. Safety Risk and Security Risk Are Disconnected

STRIDE: T, D (tampering and denial of service most often produce direct patient harm; spoofing/elevation enable the chain).

What we see: The threat model lists cyber threats but does not show how exploitation could cause patient harm, delayed care, incorrect diagnosis, or therapy disruption.

How to fix it: Trace each credible STRIDE threat to clinical function, safety impact, risk controls, residual risk, and safety-risk-management outputs per ISO 14971 and AAMI SW96.

4. Update Path Is Under-Modeled

STRIDE: S, T, E (impersonating the update server, tampering with images, escalating to kernel via a malicious update).

What we see: Patchability is described at a high level, but the end-to-end update chain, signatures, rollback protection, and deployment failure modes are not analysed.

How to fix it: Build an updateability and patchability view covering update server authentication, image signing, device-side verification, atomic install, rollback protection, logging, and lifecycle support.

5. Multi-Patient Harm Is Ignored

STRIDE: T, D, E at fleet scale.

What we see: Connected devices can fail or be compromised at scale, but the model only evaluates one device and one patient at a time.

How to fix it: Add multi-patient harm scenarios for shared infrastructure, cloud outages, fleet commands, common credentials, and simultaneous compromise - explicitly cross-referenced to your safety risk file.

6. SBOM Risks Are Not Linked

STRIDE: T, I, E (most CVEs in third-party components map to one of these).

What we see: The SBOM exists, but third-party components, end-of-life libraries, supplier constraints, and known vulnerabilities are not connected to the threat model.

How to fix it: Tie SBOM components to specific STRIDE threats, vulnerability monitoring, compensating controls, support plans, and risk acceptance rationale.

7. Security Use Cases Are Too Generic

STRIDE: Varies - the point is per-state coverage.

What we see: The model says data is sent or received, but does not assess clinical states like programming, alarming, standby, diagnostics, therapy delivery, or maintenance.

How to fix it: Create per-state security use-case views and re-apply STRIDE to each clinical state where compromise could affect safety or effectiveness.

8. Residual Risk Rationale Is Thin

STRIDE: Cross-cutting (every threat needs a residual-risk decision).

What we see: Controls are listed, but the submission does not explain pre- and post-mitigation risk, exploitability, assumptions, or why residual risk is acceptable.

How to fix it: Use a consistent security risk scoring method and provide STRIDE → control → test evidence → residual-risk traceability.

9. Manufacturing and Service Workflows Are Omitted

STRIDE: S, T, E (cloned identities at provisioning, tampered firmware in service, elevation via debug ports).

What we see: Provisioning, service access, calibration tools, debug ports, maintenance laptops, and decommissioning are excluded from the model.

How to fix it: Model manufacturing, deployment, maintenance, service, and decommissioning workflows as part of total-product-lifecycle cybersecurity - tied to your SPDF documentation.

10. Testing Does Not Map Back to Threats

STRIDE: Cross-cutting (each STRIDE category should appear in your test plan at least once per trust boundary).

What we see: Penetration testing and verification reports exist, but reviewers cannot see which threat-model controls were actually tested.

How to fix it: Build a traceability matrix linking STRIDE threats → controls → security requirements → test cases → evidence → unresolved anomalies → risk decisions. See our pen test findings guide.

11. Assumptions Are Undocumented

STRIDE: Often hides D and R (assumed network protection, assumed user vigilance, assumed supplier patching).

What we see: The model depends on hospital firewalling, user behaviour, network segmentation, or supplier updates, but those assumptions are not stated or justified.

How to fix it: State assumptions explicitly and identify which risks are transferred to users, operators, healthcare facilities, suppliers, or labelling - per AAMI TIR57 / ANSI/AAMI SW96:2023.

12. Reviewer Narrative Is Missing

STRIDE: N/A - this is the connective tissue between the other 11.

What we see: The technical artifacts may be accurate, but the submission does not tell a clear FDA-facing story about secure design and safety effectiveness.

How to fix it: Add concise explanatory text that connects SPDF, architecture views, threat modeling, SBOM, testing, and risk management into one evidence story. See common FDA rejection reasons for what reviewers flag when the narrative is missing.

Gap × STRIDE Coverage Matrix

Use this to spot the gaps that leave the most STRIDE letters uncovered. Anything with three or more letters in red on your internal review is a Critical-priority fix.

#	Gap	S	T	R	I	D	E	Priority
01	Missing global system view	●	●	●	●	●	●	Critical
02	No hostile-network assumption	●	●		●			Critical
03	Safety and security risk disconnected		●			●		Critical
04	Update path under-modeled	●	●				●	High
05	Multi-patient harm ignored		●			●	●	High
06	SBOM risks not linked		●		●		●	High
07	Security use cases too generic	●	●	●	●	●	●	Medium
08	Residual risk rationale thin	●	●	●	●	●	●	Medium
09	Manufacturing and service omitted	●	●				●	Medium
10	Testing doesn't map to threats	●	●	●	●	●	●	Critical
11	Assumptions undocumented			●		●		High
12	Reviewer narrative missing	-	-	-	-	-	-	High

How Blue Goat Cyber Approaches Medical Device Threat Modeling

We treat threat modeling as the engineering spine of the cybersecurity submission - every downstream artifact (SBOM prioritization, security risk assessment, pen-test scope, postmarket monitoring) traces back to it. Here is how we run it.

• STRIDE-per-element with medical context. We enumerate threats against every trust boundary in the DFD and score them with FDA's patient-safety rubric alongside CVSS.
• Diagrams that match the device. DFDs are generated from architecture documentation, not stock templates, and updated on every design change so what reviewers see is what is deployed.
• Explicit coverage of insider, physical, and supply-chain threats. The three categories most often absent from RTA-rejected models.
• Traceability to AAMI TIR57 / ANSI/AAMI SW96:2023 hazards and IEC 81001-5-1 controls. Every threat maps to a hazard, a control, and a residual-risk decision under ISO 14971.
• Living document under design controls. Versioned in your QMS with a documented review cadence, so the postmarket team can defend and update it after clearance.
• AI/ML awareness. For devices with learning components we add data-poisoning, model-inversion, and prompt-injection threats and align them to your PCCP.

Our Medical Device Threat Modeling engagement is the standard entry point.

Frequently asked questions

Does the FDA require STRIDE specifically, or is any threat modeling method acceptable?

The February 3, 2026 final guidance does not mandate STRIDE, but it does expect a systematic threat modeling method with documented coverage. STRIDE is the most common choice because it maps cleanly to the FDA's expectations and to ANSI/AAMI SW96:2023. Attack trees, PASTA, and LINDDUN are also accepted when properly documented. Ad-hoc "we thought about threats" narratives are not.

How detailed does the threat model need to be?

Detailed enough that a reviewer can follow one specific threat from data flow diagram, through the STRIDE (or equivalent) categorization, to a mitigating control, to objective evidence that the control was tested. If any link in that chain is missing, the model is too shallow. Depth scales with connectivity and criticality, not with device class alone.

What data flow diagrams should the threat model include?

At minimum: a system context diagram, a top-level architecture diagram with trust boundaries, and DFDs for every internet-facing and network-adjacent interface. For devices with cloud back-ends, include the manufacturer's cloud infrastructure in scope. Diagrams should identify processes, data stores, data flows, and trust boundaries explicitly. Reviewers look for trust boundaries first when evaluating threat model rigor.

Do we need to model insider threats and physical attacks?

Yes for devices where the threat model realistically includes them. Physical attacks apply to devices with removable media, exposed debug ports, or field service access. Insider threats apply to devices with manufacturer-side administrative access. Excluding either category requires a documented rationale in the threat model. Silent omissions are a common gap.

How does threat modeling for AI/ML devices differ?

AI/ML threat modeling adds adversarial ML attack vectors (model evasion, model inversion, training data poisoning, membership inference) and threats to the model update path if the device supports periodic retraining. Standard STRIDE covers most of the transport and infrastructure threats; extend the categorization with an AI-specific taxonomy for the ML-specific attack surface.

Should the threat model be updated after each release?

Yes for material changes: new interfaces, new connectivity, new components with different trust profiles, changes to authentication or authorization. Minor bug fixes and cosmetic UI changes do not require a threat model refresh. The February 2026 guidance treats the threat model as a living artifact whose version history should be traceable inside the QMS.

Want a Senior Expert to Review Your Threat Model?

Book a free discovery session and get practical next steps for FDA-ready cybersecurity documentation. Our team specialises in medical device threat modeling and premarket submission support.

Schedule Discovery

We respond within 24 hours with a quote. Tell us about your device, your timeline, and your submission type. No sales pressure - just a clear, honest assessment and a fixed-price quote.