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

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 ↔ 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 & service omitted | ● | ● | | | | ● | Medium | | 10 | Testing doesn't map to threats | ● | ● | ● | ● | ● | ● | Critical | | 11 | Assumptions undocumented | | | ● | | ● | | High | | 12 | Reviewer narrative missing | - | - | - | - | - | - | High |

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.