FDA Deficiency: Incomplete Threat Model

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  The provided threat model does not appear to enumerate threats against all external interfaces identified in the security architecture views. Provide a revised threat model that addresses each interface, including the service/maintenance port and the cloud telemetry channel.

• Pattern 2

  It is unclear how the threats identified were used to derive the cybersecurity controls listed in the risk assessment. Provide traceability from each threat to the corresponding mitigation and to the verification activity that demonstrates the mitigation is effective.

• Pattern 3

  The threat model does not address the post-market threat landscape, including supply-chain compromise of third-party software components and credential compromise during field service. Update the analysis to cover these scenarios.

Why this happens

• Threat modeling is performed once, early, by a single engineer, and never re-synced with the architecture as the design evolves.
• Teams use a generic STRIDE checklist instead of analyzing the specific data flows and trust boundaries in their device.
• The threat model lives in a separate document with no traceability links into the cybersecurity risk assessment or verification protocols.
• Service interfaces, debug ports, manufacturing test modes, and update channels are excluded from the analysis because the team treats them as 'not in the patient-facing product.'

How to fix it

• Rebuild the threat model directly from the security architecture views — every interface, trust boundary, and external entity in the diagrams must appear as a row in the threat table.
• Use AAMI TIR57 categories (or STRIDE-per-element) consistently, and document the rationale for any threat marked 'not applicable.'
• Add a traceability matrix: Threat ID → Control ID → Risk Control Measure → Verification Test ID. Reviewers grade traceability, not prose.
• Cover the full lifecycle — manufacturing, distribution, deployment, service, decommissioning — not just runtime patient use.
• Include third-party / SBOM-derived threats so the model aligns with the vulnerability management plan and CVE/CWE mapping.

What FDA reviewers are really checking

Reviewers do not read threat models cover-to-cover. They sample. They open the security architecture views, pick three interfaces — typically the wireless interface, a service/debug interface, and the software update channel — and then search the threat model for each one. If any of those three is missing, treated cursorily, or analyzed against a generic threat list rather than the actual data flows shown in the architecture, the deficiency is written. The same sampling approach is applied to trust boundaries: if the architecture shows three trust boundaries but the threat model only enumerates spoofing/tampering/repudiation across one of them, the model is judged incomplete regardless of its page count.

The pattern that gets cleared

Submissions that pass this gate share three traits. First, the threat model is generated from the same source-of-truth diagrams as the security architecture views, so the two artifacts cannot drift. Second, every threat carries a unique ID that flows into the risk assessment, the cybersecurity controls table, and the verification protocols — reviewers can pull on any thread and follow it end-to-end. Third, the model explicitly addresses the post-market threat landscape called out in FDA 2026, including third-party component vulnerabilities surfaced through the SBOM, credential and key compromise during service, and adversarial scenarios specific to the device's clinical use environment. A model with 40 well-traced threats almost always clears; a model with 200 generic STRIDE entries and no traceability almost always draws a deficiency.

Standards involved

• AAMI TIR57AAMI TIR57:2016 (R2023) - Principles for Medical Device Security - Risk Management
• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• ISO 14971ISO 14971:2019 - Medical Devices - Application of Risk Management to Medical Devices
• ANSI/AAMI SW96ANSI/AAMI SW96:2023 - Standard for Medical Device Security - Security Risk Management

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.