12 Critical Threat Modeling Gaps in Medical Device Submissions

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

Create a full medical device system diagram with assets, interfaces, trust boundaries, data flows, user roles, and environment-of-use assumptions.

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

Document hostile network assumptions and map controls for authenticity, authorization, confidentiality, availability, and replay protection.

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

Trace each credible threat to clinical function, safety impact, risk controls, residual risk, and safety-risk-management outputs — per ISO 14971.

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

Build an updateability and patchability view covering servers, delivery paths, device validation, rollback, logging, and lifecycle support.

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

Add multi-patient harm scenarios for shared infrastructure, cloud outages, fleet commands, common credentials, and simultaneous compromise.

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

Tie SBOM components to threat scenarios, vulnerability monitoring, compensating controls, support plans, and risk acceptance rationale.

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

Create security use-case views for the device functions where compromise could affect safety or effectiveness.

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

Use a consistent security risk scoring method and provide traceability from threat to control, testing evidence, and residual risk conclusion.

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

Model manufacturing, deployment, maintenance, service, and decommissioning workflows as part of total product lifecycle cybersecurity — tied to your SPDF documentation.

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

Create a traceability matrix linking threats, controls, security requirements, test evidence, unresolved anomalies, and risk decisions. See our pen test findings guide.

The model depends on hospital firewalling, user behavior, network segmentation, or supplier updates, but those assumptions are not stated or justified.

State assumptions explicitly and identify which risks are transferred to users, operators, healthcare facilities, suppliers, or labeling — per AAMI TIR57.

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

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.