Medical Device Threat Modeling for FDA Submissions

Medical device threat modeling is a structured process for understanding how a device system could be attacked, what could be affected, and which controls are needed to protect safety and effectiveness. It helps manufacturers identify cybersecurity concerns before they become expensive design, testing, or submission problems.

FDA’s current premarket cybersecurity guidance recommends that submissions for devices with cybersecurity considerations include documentation showing how manufacturers identify threats, evaluate risks, implement controls, and verify them. The analysis should address the complete system and connect threats with requirements, controls, and testing.

For connected medical devices and SaMD, that system may include firmware, mobile applications, cloud services, update infrastructure, hospital networks, third-party components, and external interfaces.

Why Does Medical Device Threat Modeling Matter?

A cybersecurity event can affect more than confidentiality. Modified commands, unavailable functions, corrupted results, or compromised updates may create hazardous situations. Threat modeling examines those paths while the architecture can still change.

Security risk and safety risk are related but not identical. Traditional safety analysis evaluates hazards and harms, while security analysis considers adversaries, attack paths, vulnerabilities, and exploitability. The two analyses should connect when a cybersecurity event could affect clinical performance, availability, or safety. AAMI TIR57 provides one framework for connecting security risk management with the broader medical device safety process.

Starting early also improves traceability from threats to requirements, controls, testing, residual-risk decisions, and postmarket monitoring.

What Should a Medical Device Threat Model Cover?

Begin with the complete system boundary. Identify device hardware and software, users, assets, data stores, communication paths, external services, administration functions, update mechanisms, and expected use environments.

Data-flow diagrams can show how information and commands move among components. Mark trust boundaries, authentication points, wireless connections, internet-facing interfaces, and transitions between manufacturer-controlled and external systems. These areas often reveal important attack surfaces.

A Software Bill of Materials (SBOM) identifies third-party components and versions, while the threat model shows where they operate and what an attacker could reach through them. Section 524B requires an SBOM in applicable cyber-device submissions, but FDA does not prescribe one universal format. SPDX and CycloneDX are commonly used.

What Are the Five Steps of Threat Modeling?

No single workflow is mandatory. A practical five-step process for threat modeling medical devices is:

1. Define the System and Security Objectives

Describe the intended use, users, environments, architecture, assets, and boundary. Identify what must be protected, including clinical functions, commands, credentials, configuration data, software integrity, and availability.

2. Map Data Flows and Trust Boundaries

Diagram components, processes, data stores, external entities, and communication paths. Document assumptions about networks and external services. Do not treat a boundary as secure merely because another organization controls it.

3. Identify Credible Threats and Attack Paths

Use a documented method to examine what could go wrong. Examples include spoofing an authorized application, modifying therapy commands in transit, extracting credentials, installing unauthorized software, accessing sensitive data, or causing denial of service.

4. Evaluate Risk and Select Controls

Assess exploitability, access, attacker capability, affected functions, protections, and safety consequences. Translate credible threats into controls such as authentication, encryption, secure boot, logging, least privilege, and secure updates.

Document security risk acceptance criteria. When an event may cause patient harm, link the analysis to the safety risk file and explain the residual-risk decision.

5. Verify Controls and Maintain the Model

Test controls against the modeled attack paths. Vulnerability scanning, misuse-case testing, fuzzing, code analysis, and penetration testing may provide supporting evidence. QCC’s FDA 510(k) cybersecurity testing support focuses on connecting test scope and results with device architecture, identified risks, and implemented mitigations. Document findings, remediation, retesting, and the rationale for unresolved issues.

Update the model when architecture, software, interfaces, suppliers, deployment assumptions, or threat information changes. Postmarket vulnerabilities and incidents should feed back into the analysis.

Which Threat-Modeling Methodologies Are Common?

There are not three universally required methodologies. Three widely useful approaches are:

• STRIDE, which examines spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege
• Attack trees, which map alternative paths an attacker could use to reach an unwanted outcome
• Attack-lifecycle and adversary-behavior approaches, including kill chains and MITRE ATT&CK-informed analysis, which examine attack progression, tactics, and techniques

These methods can complement one another. STRIDE can provide structured coverage across a data-flow diagram, while an attack tree can explain how several actions combine into a clinically important scenario.

The Medical Device Innovation Consortium threat-modeling playbook discusses STRIDE, attack trees, ATT&CK, and kill chains. The playbook is an educational resource rather than FDA guidance or a legally enforceable requirement.

What Is the Best Tool for Threat Modeling?

There is no universally best tool. The right choice supports the methodology, architecture, review process, version control, and traceability needs.

Teams can begin with controlled diagrams and tables. Specialized platforms may help generate threats and manage mitigations. Complete coverage, qualified review, controlled records, and traceability matter more than tool sophistication.

What Does FDA Expect in a Premarket Submission?

FDA’s current cybersecurity guidance recommends documentation that identifies security objectives, risks, vulnerabilities, and countermeasures across the system. The security risk management report should provide traceability among the threat model, cybersecurity risk assessment, SBOM, and testing documentation.

Architecture views and explanatory text should help reviewers understand system boundaries, interfaces, security use cases, multi-patient effects where relevant, and updateability and patchability. Controls should map to design requirements and objective verification evidence. Penetration testing should address modeled attack paths rather than operate as an isolated end-of-development exercise.

A submission-ready threat model should tell one consistent story. The architecture, risk assessment, requirements, controls, SBOM, and testing evidence should use compatible terminology and lead reviewers to the same conclusions.

Common gaps include incomplete cloud or mobile scope, missing trust boundaries, generic threat lists, unsupported exploitability conclusions, controls without testing evidence, and inconsistent terminology across cybersecurity files.

How Quality Commercial Consultants Can Help

At Quality Commercial Consultants, we help software-enabled medical device and SaMD companies turn technical threat-modeling work into clear, FDA-ready evidence. Our FDA 510(k) cybersecurity documentation support may include threat-model reviews, architecture and traceability assessments, cybersecurity risk narratives, testing-evidence alignment, submission-readiness reviews, and responses to FDA Additional Information requests.

Contact Us Today

Contact our team to discuss your device, threat model, submission pathway, and current cybersecurity documentation. We tailor the engagement to your device architecture, development stage, and evidence already available.