FDA 510(k) Threat Model Report: A Step-by-Step Guide for Medical Device Manufacturers

Preparing a medical device for FDA 510(k) submission involves more than showing that its software performs as intended. When a device uses wireless communication, mobile applications, cloud services, APIs, or third-party software, manufacturers also need to understand cybersecurity risks across the complete system. A threat model report documents how the device is built, where it could be attacked, what protections are selected, and how those protections are checked. The FDA’s February 3, 2026 cybersecurity guidance recommends threat modelling throughout design and across all elements of the medical-device system. This guide explains what the report should contain and how to prepare it through four practical stages.

What is an FDA 510(k) Threat Model Report, and Why Does It Matter?

A threat model report is technical documentation that outlines the process where a manufacturer considers the medical device and the environment it is connected to for potential cybersecurity risks. It defines assets to be protected, how an attacker could attack these assets, what is the harm or disruption that can result from the attack, and what is the measure that has been chosen to mitigate the risk. It’s meant to give another technical reader a sense of why the manufacturer did this as opposed to merely a list of vulnerabilities.

Think about a device that is connected to the patient and can be used to monitor them. It could interact with a mobile application via Bluetooth Low Energy (BLE), transmit information via API, and store and display information in a cloud-based system. One of the parts can be weaker than another and therefore impact another part as well, so it’s important to think about how they connect as well as the device itself when assessing.

How should a useful Threat Model be helpful for manufacturers?

A useful threat model is helpful to manufacturers in that it:

• Identifies hardware, Software, interfaces, and External Services to be included.
• Recognizes possible attack scenarios and impacted assets.
• Evaluates possible effects on device operation and patient safety, as well as confidentiality, integrity and availability.
• Identify security measures and relate them to evidence of verification.

There is no single FDA template that is required and to be submitted as a standalone document, known as an FDA 510(k) Threat Model Report. On February 3, 2026, its final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, includes threat-modelling documentation as part of the broader cybersecurity risk management documentation for devices that have cybersecurity considerations.

That wider documentation might include a cybersecurity risk assessment, an SBOM, component support information, vulnerability assessments, and assessments of unresolved anomalies. A threat model should be linked to these records but should not be considered a cybersecurity risk management report. FDA also needs to separate its recommendations from the requirements for qualifying cyber devices as defined in Section 524B of the Federal Food, Drug, and Cosmetic Act.

What Does the FDA Expect to See in Threat Modelling Documentation?

In February 2026, FDA provided guidance that recommends risk assessment (threat modelling) throughout the device design process and across all parts of the medical-device system. The assessment should include the intended use, architecture, relevant wireless interfaces and applications, cloud services, APIs, networks, and third-party components.

Manufacturers are free to choose a method or a mixture of methods that is suitable for the device, as long as it is suitable and the reasoning is explained. The report should provide an explanation of what is going on:

• System coverage: The device, connected components, interfaces, data flows, and supporting systems.
• Methodology: Method chosen and justification of the chosen method for the product.
• Assumptions and exclusions: Conditions assumed in the analysis and reasons for excluding relevant conditions.
• Risk decisions: Threats identified, risk assessment, and actions to mitigate the risk.
• Lifecycle risks: related to the supply chain, manufacturing, deployment, interoperability, maintenance, updates and decommissioning.
• Traceability: Linkages between the threats, risk assessments, controls, and verification evidence.

The detail of the attacks varies with the device architecture and attack surface. The goal is to complete the analysis for the product being analyzed.

How to Build the report? Start With Four Questions

Treat threat modelling as four connected stages, not a form to complete at the end of development:

Understand → Identify → Control → Verify

These are practical organising questions, not questions formally issued by the FDA.

1. What Are We Working On? Understand the Complete Medical-Device System

The team should first learn about what the device does, how it works, and which components communicate with it before searching for any threats. If the evaluation is limited to the device and mobile application, but patient data is not being sent to the cloud API, the attack surface might be incomplete.

Begin by collecting information from four areas:

• Device: Description, intended use, medical functions, intended users, and operating environment.
• Components: Hardware, firmware, software, operating systems, applications, and related third-party components.
• Architecture: Interfaces, data flows, communication protocols, external connections and trust boundaries.
• Lifecycle: Deployment, software updates, maintenance, remote servicing, support and decommissioning.

Record each input’s source, version, owner, and confirmation status to separate verified facts from assumptions.

Create a system architecture diagram that depicts interactions between the components. For instance, a connected device can communicate with a mobile application, which can then share information with an API and cloud database, from which the authorised clinicians can access information via a web portal.

What does a System Architecture Diagram include other than boxes and arrows?

Show more than boxes and arrows. Include:

• Entities, processes and data stores in the system.
• Flow of data in and out.
• Protocols like BLE, Wi-Fi, USB and HTTPS.
• Trust across devices, applications, users and networks.
• Points of authentication and authorization.
• Update paths and external services.

The FDA’s February 2026 guidance recommends four security architecture views for premarket submissions:

1. Overall Device System View: Provides a view of the overall device system including all internal and external connections, networks, cloud services, and supporting infrastructure.
2. Multi-Patient Harm View: Describes the possible impact on multiple interconnected devices or patients of a compromise.
3. Updateability/Patchability View: Provides a visualization of software updates and security patches from the manufacturer to the device.
4. Security Use Case Views: Identify functions and scenarios that may be impacted by a cybersecurity compromise that may impact safety or effectiveness.

Explain using diagrams and text the views that are relevant to the device. Correlate details with device architecture and risk. If a view is not proper, record the reasons for this.

You must have the following before you get on to threat identification:

• A clearly outlined device and system scope.
• List of relevant components and interfaces.
• Architectures and data flow diagrams using trust boundaries.
• Document of assumptions, information sources, and open questions.

After the team establishes what is connected and how information flows, they can look at where an attacker might gain access and what the attacker could do.

2. What Can Go Wrong? Identify Threats Across the Device and Its Interfaces

Threat identification is looking at the system as viewed by an attacker: how an attacker might misuse an interface, interfere with a data flow, gain access to a function or disrupt a service. Scenarios should be related to the real architecture.

A technique used in the webinar is STRIDE. It classifies possible threats into six categories and enables teams to look at various types of security failure. The FDA does not require STRIDE, although if a manufacturer chooses to use it, they should document the reason for doing so.

What are the six categories of STRIDE?

The six categories can be applied to a medical-device environment as follows:

1. Spoofing: An unauthorised BLE device tries to create a connection as if it were a trusted device.
2. Tampering: The act of a person trying to alter patient readings, commands, application binaries or firmware.
3. Repudiation: There are insufficient audit records to determine the settings change or privileged action.
4. Information Disclosure: An unauthorized person makes patient telemetry or credentials/sensitive information available.
5. Denial of Service: Bad requests or too many requests cause a disruption to the communication or cause a device to become unavailable.
6. Elevation of Privilege: An unauthorized user can use a weakness in the system’s authorization to access functions that exceed their assigned authorization levels.

Just a STRIDE label is not a threat entry. Describe the asset affected, the attack path, conditions and consequences. “BLE spoofing” is a very general term and should be more specific by including the interface being targeted, the access an unauthorised device might gain, and the function or information at risk.

A threat register maintains the scenarios in order. For each entry, record:

• Threat ID (TM-001) and asset affected.
• Threat type, attack route, and conditions.
• The possible cyber security, operational, and patient safety consequences.
• Reference for risk evaluation, justification, and mitigation.
• In the development phase, the issue was dealt with.

Evaluate patient safety with regard to the intended use. Breaking the patient-monitoring communication chain could impact information that is available to the clinician and exposing stored credentials would have a different impact. Use a descriptive term for impact; don’t just use a generic term for severity or vulnerability score.

Now the threat register tells us what might occur. The next step is to demonstrate how the manufacturer will minimize or eliminate those risks.

For a visual walkthrough of identifying threats and applying STRIDE to medical devices, watch our webinar recording here:

3. What Are We Doing About It? Select and Document Security Controls

Once threats have been evaluated, the manufacturer determines which steps will be taken to deal with each pertinent threat. This links threat scenarios to security requirements and controls implemented. Do not include items on a checklist that are not explained: If the report states that the device is used for encryption, specify the data or channel that you encrypt and the threat that this control mitigates.

The Confidentiality, Integrity and Availability (CIA) principles can help organise security objectives:

• Confidentiality: Data encryption, protection of sensitive information, and storage and control of credentials.
• Integrity: Secure firmware updates, code integrity, data validation, and tamper protection.
• Availability: Resilience mechanisms and recovery procedures, and communication protection.

The FDA guidance for February 2026 also mentions control categories like authentication, authorization, cryptography, code, data, and execution integrity, confidentiality, event detection and logging, resiliency and recovery, and software updates. Practices can be organized by the NIST Cybersecurity Framework and/or NIST SP 800-53, but describe why each control is selected for the device to mitigate the risks.

The traceability matrix

A traceability matrix makes the connection visible. For example:

These are examples of identifiers and not a numbering system set by FDA. They grant a reviewer permission to transition from threat to risk, requirement, control and verification record.

For each control, you should document the threat or risk it addresses, the corresponding security requirement, how it is implemented, the affected component, its status, and the verification activity planned.

Be sure of status. A proposed control is not implemented, and an implemented control is not verified until the relevant test is completed. The last step is to see if the actions taken are having an effect and if there is any risk left.

4. Did We Do a Good Enough Job? Verify the Controls and Record the Evidence

A control may be a good design idea, but not work in reality. A device can be authenticated for BLE pairing, but still execute unauthorised commands via another interface. Verifications check if the control functions in the appropriate device configuration.

Testing should be reflective of the architecture, interfaces, threats, and the security requirements. 

Activities can consist of:

1. Penetration testing: An attempt to take advantage of any weaknesses throughout the device and attached components.
2. Security control verification: Validates authentication, authorization, encryption, and logging processes.
3. Fuzz testing: Analyzes fuzzed inputs or unexpected inputs.
4. Attack-surface analysis: Examines open interfaces and vulnerabilities.
5. Software analysis: Examines components and code by using composition and/or static or dynamic analysis.

The FDA guidance provides relevant security testing documentation in premarket submissions in February, 2026. In the case of penetration testing, make note of who is performing the test, their independence, scope, duration, methods, results, findings, and observations. If the work was done by a third party, include the original report from the third party as recommended in the guidance.

The testing evidence has to relate to the threat model. If the concern for TM-017 is unauthorised pairing, demonstrate that you have exercised the pairing and authorisation controls in that case. A vulnerability scan in general will not prove the effectiveness of the specific control.

What to verify and what to record?

Record for each verification activity:

• The danger or security aspect being tested.
• Version and configuration of the device.
• The test method and scope.
• The outcome and arguments.
• Any finding, remediation, and test result.
• Whether the control was verified or needs further action.

All risks will not be removed. Some may be left as findings or may need to be further mitigated later. Write the reason, remaining risk, possible effect on safety and effectiveness, and reason for decision. Analyze and evaluate any software anomalies that software teams haven’t resolved, including those with cybersecurity implications.

At the end of verification, make sure you have:

• Test records that are correlated with threats and controls.
• Penetration testing and other supporting reports, as appropriate.
• Evidence of remediation and retest.
• Assessment of unresolved issues and risks remaining, documented.

These four stages are now a single continuous story: an understanding of the system, identification of threats, selection of controls, and verification of results. You can then put the report together such that a reviewer can follow that account without having to go across and search through disassociated records.

How Should You Organise the Final Threat Model Report?

There is no single FDA-prescribed threat model report template. Use a structure that reflects the device and its supporting cybersecurity documentation. The following is a practical starting point:

This is an organisational recommendation, not a mandatory list of FDA headings. The complete cybersecurity risk management documentation should also address other elements recommended in the FDA guidance. Ensure the report reflects the actual device version being submitted. Changes to software, firmware, interfaces, third-party components or controls may require reviewers to revisit the threat model and related assessments.

What Should Manufacturers Check Before Including the Report in a 510(k) Submission?

A report with gaps can include all the expected sections. Pre-submission technical consistency and traceability check.

Use these checks:

1. Is the description of the device consistent with the version submitted?
2. Are the components and connections in the architecture diagrams in scope?
3. Does anyone document the methodology, assumptions, threats, and risk decisions?
4. Do security requirements and controls relate to identified threats?
5. Are there test materials, remediation, and retesting as applicable?
6. Have there been any unaddressed vulnerabilities, anomalies, and residual risks identified?
7. Does the SBOM and supporting documentation agree with the device documentation?

If a cyber device is eligible, manufacturers should also consider the statutory obligations under Section 524B of the FD&C Act. These include a full plan to track, detect and resolve postmarket cyber vulnerabilities and exploits, processes and procedures to ensure the device and associated systems are reasonably cybersecure (including relevant software updates and patches), and an SBOM of commercial, open-source, and off-the-shelf components. Not all medical devices necessarily fall under section 524B; only those that the statutory definition of a cyber device covers do.

The FDA’s Quality Management System Regulation (QMSR) is effective on February 2, 2026, bringing ISO 13485:2016 into FDA’s regulations by reference. Make sure to maintain relevant cyber security documentation within applicable quality processes. Follow current FDA electronic submission requirements and eSTAR (unless exempt) for 510(k) submissions.

The last traceability exercise can expose gaps: Choose one threat ID and trace it from the affected asset to the threat architecture, threat scenario, threat risk, threat security requirement, threat control, test evidence, residual-threat decision. To submit a record or explanation when a connection is missing, add it before you submit the record.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Conclusion

An FDA 510(k) threat model report should tell a clear, traceable story of the understanding and addressing of a medical device’s cybersecurity risks. It starts with a complete system architecture and identifies realistic threats and their potential impact; it then documents the controls that have been chosen to mitigate these risks and links these controls to verification evidence. Manufacturers should make sure that assumptions, risk decisions, unsolved issues, and residual risks are made clear and aligned with the version of the device being submitted.

While FDA does not endorse a specific threat modelling template, the guidance dated February 2016 emphasizes threat modelling during the design process and throughout the system of the device. By handling the report as a living, ongoing document of cybersecurity risk management, manufacturers have a more reliable way to document changes in the landscape, including devices, software, interfaces, and threats.

Get in touch with us for technical guidance on FDA 510(k) cybersecurity documentation.