FDA Medical Device Threat Modeling Guide

This guide is for manufacturers, engineering teams, and quality and regulatory leads planning cybersecurity evidence for a medical device submission. It focuses on scope, document contents, and common FDA cybersecurity questions. For a method walkthrough, use the STRIDE threat modeling guide. For a starting document structure, use the FDA Medical Device Threat Model Template.

The primary source is the FDA's February 3, 2026 final premarket cybersecurity guidance, particularly Sections V.A.1, V.A.2, and V.B. These FAQs are plain-language interpretations of that source. They are not quotations from a deficiency letter or evidence of a specific client's review.

What the FDA recommends, and what Section 524B requires

Section V.A.1 recommends threat modeling to inform risk analysis, throughout the design process and across all medical device system elements. The documentation should explain system risks, mitigations, assumptions, lifecycle threats, and the rationale for the selected method.

Those recommendations are distinct from the statutory duties in Section 524B of the FD&C Act. For applicable cyber devices, the statute addresses postmarket vulnerability plans, processes and procedures, updates and patches, and an SBOM. It does not prescribe STRIDE, a diagram notation, or a universal threat-table size. The FDA's guidance contains nonbinding recommendations except where it cites specific legal requirements.

Manufacturers should determine applicability and the evidence appropriate to the device and submission pathway. A template, supplier certificate, or external consultant cannot make that determination automatically.

Start with the system, not just the device enclosure

Document intended use, essential device functions, deployment conditions, supported software versions, and who owns each system element. Include connected elements relevant to the device's safety and effectiveness. State omissions and their rationale rather than silently excluding them.

Section V.A.1 specifically discusses an adversary controlling the network and being able to alter, drop, and replay packets. Treat a hospital network's protections as an explicit dependency, not a reason to omit network threats.

For AI-enabled devices, include relevant model endpoints, model-update paths, and training or deployment access where they are part of the device system. Do not assume every AI threat applies to every product.

What should the threat model document contain?

Use a controlled document that an engineer can compare with the implemented system. The following is an evidence organization checklist, not a mandatory FDA table format.

Keep unknowns visible. A planned control is not an implemented control. An untested control does not have completed security-test evidence. A supplier assertion is not the same as evidence of how the shipped system behaves.

A practical workflow from scope to review

Use the following sequence to organize the work. The detailed STRIDE method remains in the STRIDE threat modeling guide; this sequence connects the analysis to evidence preparation rather than prescribing a tool or table size.

1. Define the configuration and assets. Record the device release, safety-relevant functions, information, credentials, update infrastructure, and relevant connected elements. Include only the programmer, app, cloud service, or other dependency actually present in the system. Explain exclusions and ownership.
2. Map elements, flows, and trust boundaries. Identify processes, data stores, external actors, interfaces, and directional flows. Record protocol, privilege, authentication, and environmental assumptions. Have engineers compare the representation with the implemented system. See Data Flow Diagrams for Medical Device Cybersecurity.
3. Identify attack scenarios using the chosen method. Blue Goat uses STRIDE per element, with numbered entry points. Record applicable threats and reasoned non-applicability, attacker prerequisites, affected assets, and potential security effects. STRIDE classifies threats; it does not supply scores or establish patient harm.
4. Analyze security risk and possible paths to harm. Record exploitability and security impact using supporting evidence. Where a scenario can reach a patient, link to the manufacturer's ISO 14971 hazard analysis and supplied harm severity. Keep unknowns unscored rather than guessing.
5. Connect controls to actual security-test evidence. Use stable threat, requirement, control, and test identifiers. Distinguish proposed mitigation from implementation, planned testing from executed results, and an open finding from a manufacturer-reviewed decision.
6. Review residual risk and maintain the model. Record the manufacturer-owned acceptance decision, remaining issues, reviewer, and revision. Reassess changed architecture, interfaces, suppliers, updates, and attack paths identified in testing. Keep the evidence tied to the configuration being submitted.

A source-grounded example of the evidence chain

Section V.A.1 of the February 3, 2026 guidance gives the assumption that an adversary can control a hospital network and alter, drop, or replay packets. Use that published assumption to examine actual device communications. Record the flow and prerequisites, analyze the security consequence, identify a relevant control, and link an executed test and manufacturer risk decision.

This is an analysis relationship, not an observed device vulnerability. It does not establish that a product implements authentication, passed a replay test, or has a particular clinical harm severity. Those conclusions require the manufacturer's engineering and safety evidence.

Connect threats to patient safety without inventing harm severity

A security consequence and a patient harm are different. Loss of data confidentiality does not automatically establish physical harm. Loss of integrity or availability may affect a clinical function, but the path and operating conditions need analysis.

Blue Goat uses STRIDE to classify threats, not to assign a risk score. Our security analysis separates exploitability and security impact. Findings with a plausible patient-safety consequence are linked to the manufacturer's ISO 14971 hazard analysis. The manufacturer supplies harm severity, owns risk acceptance criteria, and makes the acceptance decision.

These are Blue Goat's scoring conventions, not a matrix mandated by the FDA. A CVSS base score alone does not replace a medical device safety assessment. See ISO 14971 and cybersecurity risk management for the relationship between the two analyses.

Keep architecture, SBOMs, and penetration testing connected

Each document answers a different question.

• Threat model: How could the system be attacked, and how are the resulting risks addressed?
• Security architecture views: Where are the system boundaries and controls, and how do relevant security scenarios operate?
• SBOM and vulnerability assessment: Which software components are present, and what known vulnerabilities may affect them?
• Penetration test evidence: What attacks were attempted against the agreed build and interfaces, and what was observed?

Use consistent names and revisions across the documents. A practical traceability chain is system element, threat ID, control ID, security-test reference, residual risk, and manufacturer decision. If a test finds an attack path missing from the model, update the analysis rather than treating the report as a disconnected attachment.

The medical device penetration testing page explains testing scope and report deliverables. The FDA Cybersecurity Architecture Views guide covers the global system, multi-patient harm, updatability and patchability, and security use case views recommended in Section V.B.

Prepare the evidence for eSTAR and design review

Follow the applicable eSTAR 7.1 template's prompts for current-version planning, and confirm the FDA's instructions for your submission. Use readable attachments and explicit cross-references. Do not assume a fixed attachment number applies to every template revision or pathway.

Before assembling the submission, review whether the model matches the submitted device configuration, whether unresolved threats are identified, and whether references lead to the relevant risk, architecture, and security-test evidence. The eSTAR 7.1 Cybersecurity Documentation and Evidence Map covers attachment preparation. The premarket cybersecurity deliverables and eSTAR map can support that review.

Record the review and document revision. Revisit the model when architecture, interfaces, authentication, suppliers, update mechanisms, or vulnerability findings change. Section V.A.1 addresses risks through manufacturing, deployment, maintenance, updates, and decommissioning, not only the initial submission.

How Blue Goat supports manufacturers

Blue Goat can develop or review the system model, classify threats, document security risk, link controls and security-test evidence, and work with your engineers on patient-safety references. The manufacturer remains responsible for product decisions, implementation, clinical harm severity, risk acceptance, and the submission.

For standalone work, see medical device threat modeling services. For coordinated submission evidence, see the FDA Premarket Cybersecurity Package. Fees are fixed after scoping. No threat model or service engagement promises a regulatory outcome.

FAQ

Does the FDA require STRIDE for medical device threat modeling?

No. Section V.A.1 of the February 3, 2026 guidance says manufacturers may choose methodologies or combinations of methods and should provide their rationale. STRIDE is one method. Blue Goat applies it per system element, but that is our methodology, not a universal FDA requirement.

What threat modeling documentation does the FDA recommend in a premarket submission?

The FDA recommends documentation showing how the system was analyzed for potential security risks affecting safety and effectiveness. Explain system risks, mitigations, assumptions, lifecycle threats, and the selected methodology. Link the analysis to pre- and post-mitigation cybersecurity risk and the relevant architecture evidence. See Sections V.A.1 and V.B.

Is a data flow diagram enough to be a threat model?

No. A diagram describes the system. Threat modeling adds the attack analysis, assumptions, controls, and risk reasoning. A useful diagram supports that analysis through identifiable elements and trust boundaries; it does not replace it.

Can a penetration test replace the threat model?

No. Threat modeling examines potential attack paths and design controls. Penetration testing assesses an implemented system within an agreed scope. Section V.C discusses security testing separately. Use test results to challenge and update the model, and identify any threats not covered by the test scope.

Should the threat model include cloud services, mobile apps, and hospital networks?

Include the system elements and dependencies relevant to the device. Section V.A.1 recommends analysis inclusive of all medical device system elements. Describe ownership and trust boundaries for cloud services, apps, and networks. Document environmental assumptions and the reasoning for exclusions.

How should cybersecurity threats connect to ISO 14971 patient-safety analysis?

Identify whether a threat can affect a device function in a way that reaches a patient. Reference the manufacturer's hazard analysis and harm severity rather than assigning clinical severity without that evidence. Keep security impact and safety consequences distinct. Sections V.A.1 and V.A.2 discuss the relationship between cybersecurity and safety risk.

Is a CVSS score enough for the cybersecurity risk assessment?

No. A vulnerability score does not by itself explain system consequences, clinical harm, control effectiveness, or residual risk acceptance. Document the security risk method and supporting evidence. The manufacturer owns safety severity and acceptance decisions; the FDA does not prescribe Blue Goat's scoring matrices.

Is threat modeling only relevant to cyber devices under Section 524B?

No. The guidance's cybersecurity recommendations are broader than the subset of devices subject to Section 524B. Determine the device's cybersecurity risks and guidance applicability separately from whether it meets the statutory cyber device definition. See the guidance's scope and Section VII.

When should the manufacturer create and update the threat model?

Start during design while architecture and controls can still change. Section V.A.1 recommends threat modeling throughout design and consideration of lifecycle risks. Review it when system changes or vulnerability findings affect assumptions, threats, or controls. Document the trigger, analysis, and revision.

Are security architecture views the same as the threat model?

No. Section V.B discusses architecture documentation separately. Views describe system structure and security scenarios; the threat model records the attack and risk analysis. Content may be cross-referenced or reused when it covers the relevant recommendations, but diagrams alone do not replace the analysis.

Does the FDA specify a minimum number of threats or a required threat model tool?

Section V.A.1 does not prescribe a universal threat count or a particular software tool. Choose a method suited to the system and explain the rationale. Judge coverage against system elements, assumptions, lifecycle risks, controls, and risk evidence rather than an arbitrary row count.

Where does the threat model belong in eSTAR?

Use the cybersecurity prompts and attachment fields in the current eSTAR template for your pathway. Keep document names, revisions, and cross-references consistent with the risk assessment and architecture evidence. The template organizes submission content; it does not replace the underlying analysis or determine a regulatory outcome.

Sources and primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final guidance, February 3, 2026. Sections V.A.1, V.A.2, V.B, V.C, and VII.
• Cybersecurity at the FDA's Digital Health Center of Excellence. Statutory context and cybersecurity resources.
• eSTAR Program. Current submission templates and program information.
• Playbook for Threat Modeling Medical Devices, MITRE and MDIC. Educational methods and fictional examples, not a mandated FDA method.

Related threat-modeling methods

• Comparing DREAD, STRIDE, and PASTA Threat Models: method selection, separate from the evidence checklist.
• Threat Trees and Attack Trees in Medical Device Cybersecurity: diagram purpose and supporting attack analysis.
• FMEA vs Threat Modeling for Medical Devices: distinct analysis questions.