FDA cybersecurity deficiency letter: Threat model incomplete

Your team has worked months preparing your medical device submission. A lot of thought and hours have been put into this. Your engineering team has completed the cybersecurity testing, the documentation is ready, and everything looks good to go.

Then, oh no, comes an unexpected setback. FDA wants more information about your threat model. Just what you needed, right? Frustration. Confusion. Financial concerns if you can't launch on time.

First off, it's important you really understand the FDA cybersecurity deficiency letter. It identifies gaps or concerns in the cybersecurity information submitted for a medical device. Very likely, FDA is questioning how well you have identified potential threats across the entire device system.

But don't let your anxiety get the best of you. This is fixable.

Be aware that an incomplete threat model doesn't automatically mean your device is insecure. Among the possible reasons for the letter include you haven't provided enough evidence to show FDA how you:

• Identified threats
• Evaluated risks
• Addressed potential vulnerabilities

So, let's roll up our sleeves and get to the bottom of this. In this article we'll look at why FDA flags incomplete threat models, what reviewers expect to see, and how to correct the deficiencies without creating more problems for your submission.

What does an FDA threat model deficiency look like?

A medical device manufacturer might spend months preparing an FDA submission, only to receive a request for additional information about its cybersecurity documentation. One common problem? The threat model doesn't tell the whole story.

An FDA threat model deficiency generally means the agency needs more information to determine whether the manufacturer has adequately identified and addressed cybersecurity threats that could affect the device's safety or effectiveness.

For example, a manufacturer might submit a threat model that covers the device's software but leaves out its cloud connections, mobile application, or hospital network interfaces. Another might identify potential attacks without explaining how those threats were evaluated or what security controls address them.

These gaps matter because FDA needs to understand how cybersecurity risks were identified, assessed, and managed. A list of threats isn't necessarily enough. Reviewers also need supporting documentation that connects those threats to the device's architecture, security controls, and risk management activities.

The good news is that an incomplete threat model doesn't automatically mean a manufacturer must start over. The appropriate response depends on what's missing and whether the existing analysis can be expanded to address the deficiency.

Common wording patterns in a deficiency request

An FDA cybersecurity deficiency letter or additional information request may identify missing information without prescribing exactly how the manufacturer should fix it.

The wording varies by device and submission. However, requests involving incomplete threat models often focus on several recurring problems:

• Missing system components: The threat model doesn't adequately address connected applications, cloud services, external interfaces, or other components of the medical device system.
• Unclear trust boundaries: The documentation doesn't show where data moves between systems or where different levels of access and control exist.
• Incomplete threat identification: Certain interfaces, data flows, or reasonably foreseeable attack scenarios haven't been evaluated.
• Weak traceability: The manufacturer identifies threats but doesn't clearly connect them to cybersecurity risks, security controls, or verification activities.
• Insufficient supporting evidence: The submission doesn't provide enough detail for reviewers to understand the threat modeling method or determine whether the analysis is sufficiently comprehensive.

Consider a connected infusion pump that communicates with a hospital network and a cloud-based management platform. Its manufacturer submits a threat model covering unauthorized access to the pump itself. But the model says little about compromised cloud credentials or attacks involving communications between the pump and its management platform.

FDA could request additional information about those missing attack paths and the measures used to address them.

The important distinction is that a deficiency request doesn't necessarily mean the device is insecure. It means the information submitted hasn't adequately demonstrated that the relevant cybersecurity threats were considered and addressed.

For manufacturers, the first task is to identify precisely what the reviewer is asking for. Sometimes the answer requires additional analysis. Other times, the analysis already exists, but the submission doesn't clearly document it.

Either way, the response needs to close the identified gap with specific, traceable evidence rather than a general assurance that the device is secure.

Why medical device threat modeling falls short

Nobody sets out to submit an incomplete threat model to FDA. Yet it happens, even when manufacturers have spent considerable time identifying cybersecurity risks.

Sometimes the problem is an overlooked connection. Other times, the manufacturer has done the analysis but hasn't documented it well enough for an FDA reviewer to follow.

The FDA premarket cybersecurity guidance emphasizes the importance of evaluating threats across the medical device system, including its interfaces and the environments in which it operates. That can be a challenge for manufacturers whose devices connect to hospital networks, mobile applications, cloud platforms, and third-party services.

Most incomplete threat models share a few common problems.

The threat model doesn't cover the entire system

One of the easiest mistakes is concentrating on the medical device itself while overlooking everything connected to it.

Consider a patient monitoring device that sends readings to a cloud platform. The manufacturer may thoroughly evaluate the device's firmware, authentication controls, and wireless connections. But what about the cloud service receiving the data? Or the mobile application a clinician uses to review the results?

Those components can introduce cybersecurity threats of their own.

FDA expects manufacturers to consider the medical device system as a whole. That includes relevant external connections, software components, and interfaces, even when another company operates part of the infrastructure.

This doesn't mean manufacturers are responsible for securing every hospital network or third-party platform. They do, however, need to understand how those connections could affect their device's safety and effectiveness.

A threat model that stops at the device's physical boundaries may miss some of its most important cybersecurity risks.

Trust boundaries and data flows aren't clear

Here's another problem that can lead to an FDA threat model deficiency: The manufacturer identifies the system's components but doesn't adequately explain how they communicate.

A diagram might show a medical device connected to a hospital network and a cloud server. That's a start. But it doesn't necessarily tell reviewers what information moves between those systems, which components can access it, or where security controls are needed.

That's where data flows and trust boundaries are relevant.

Data flows show how information travels through the system. Trust boundaries identify points where information or commands cross between areas with different security assumptions or levels of control.

For example, a device may receive software updates from a remote server. The threat model should consider what happens if an attacker compromises that connection or attempts to deliver an unauthorized update.

Could the attacker change the device's behavior? Could the device accept malicious software? What prevents that from happening?

Without clearly documented data flows and trust boundaries, those questions become harder to answer.

The result is a threat model that may look complete on paper but leaves important attack paths unexplored.

Threats aren't connected to mitigations

Identifying a cybersecurity threat is only half the job. Manufacturers also need to show what they've done about it.

Suppose a threat model identifies unauthorized access as a potential problem. The manufacturer explains that an attacker could gain access to a connected medical device and change its operating settings.

That's useful information. But an FDA reviewer will also want to understand how the manufacturer addresses that threat.

Does the device require authentication? Are users assigned different access privileges? Are changes to critical settings restricted or logged?

More importantly, where is the evidence that those protections were implemented and evaluated?

This is where medical device threat modeling needs to connect with the manufacturer's broader cybersecurity risk management activities.

A useful threat model allows reviewers to follow the path from an identified threat to its associated risk, the security measures selected to address it, and the evidence supporting those measures.

When those connections are missing, reviewers may have difficulty determining whether a threat has been adequately addressed.

And simply stating that a security control exists isn't the same as demonstrating that it works.

Manufacturers should be able to point to the relevant design documentation, risk assessment, and verification or testing evidence.

The threat model doesn't reflect the current design

Medical devices rarely remain unchanged throughout development.

Engineers modify software. New components are added. Cloud services change. Sometimes a manufacturer introduces a new interface late in development because customers need additional functionality.

Each change can affect the device's cybersecurity risk profile.

The trouble starts when the threat model doesn't keep up.

Imagine a manufacturer that completes its initial threat model before adding a Bluetooth connection to its device. The engineering team evaluates the new feature and implements security controls, but nobody updates the original threat model.

Now the FDA submission contains a system architecture showing Bluetooth connectivity, while the threat model makes no mention of it.

That's the kind of inconsistency that can raise questions during premarket reviews.

Threat modeling shouldn't be treated as a one-time exercise that gets checked off early in development. It needs to evolve alongside the device.

When manufacturers add new interfaces, modify software, or change external dependencies, they should determine whether those changes introduce new threats or affect existing security controls.

The same applies when penetration testing or other security evaluations uncover attack paths the original analysis missed.

Keeping the threat model current also makes responding to an FDA cybersecurity deficiency letter much easier. Instead of reconstructing months of engineering decisions, the manufacturer can work from documentation that already reflects the device being submitted for review.

What the FDA premarket cybersecurity guidance expects

FDA doesn't expect manufacturers to predict every possible cyberattack. But it does expect them to take a thorough look at where threats could originate and how those threats might affect their medical devices.

The February 2026 FDA premarket cybersecurity guidance recommends conducting threat modeling throughout the design process. That means looking beyond the device itself to consider connected systems, external interfaces, and potential vulnerabilities across the entire operating environment.

Just as important, manufacturers need to document their findings so FDA reviewers can understand how they reached their conclusions.

Threat modeling is more than an architecture diagram

An architecture diagram shows how the different parts of a medical device system fit together. A threat model takes that information further by asking what could go wrong.

For example, a diagram might show a patient monitor sending information to a cloud server. The threat model examines whether someone could intercept that information, change it, or disrupt the connection.

Both documents serve a purpose, but one can't replace the other.

FDA expects a connection to cybersecurity risk management

Identifying threats is part of the job. Manufacturers also need to show how those threats were evaluated and addressed.

That means connecting identified threats to cybersecurity risks, documenting appropriate security controls, and evaluating the risks before and after mitigation.

FDA doesn't require manufacturers to use STRIDE or any other specific modeling methodology. What's important is choosing an appropriate approach and documenting the results.

The bottom line? FDA reviewers need to see more than a list of potential threats. They need enough evidence to understand how the manufacturer identified, evaluated, and addressed cybersecurity risks.

How to fix an incomplete threat model

Getting a deficiency request from FDA isn't exactly welcome news. But it doesn't necessarily mean starting your cybersecurity documentation from scratch.

The first priority is understanding what's missing. From there, you can focus on correcting the gaps and giving FDA the evidence it needs to evaluate your submission.

Here's how to approach the process.

Step 1: Review the deficiency request carefully

Before making changes, read FDA's comments closely. Is the reviewer concerned about missing system components? Unidentified threats? Security controls that aren't adequately explained?

Each issue calls for a different response.

Break the request into individual concerns and identify the documents affected. This helps prevent unnecessary revisions while making sure nothing gets overlooked.

Step 2: Revisit the device's architecture

Next, take another look at how your device actually works.

Does your documentation include every relevant connection, interface, and external system? What about cloud services, third-party software, and hospital networks?

Pay particular attention to data flows and trust boundaries. These show where information travels and where different levels of access or control meet.

If the architecture has changed since the threat model was created, update the diagrams before moving forward.

Step 3: Identify the missing threats

Now it's time to examine what could go wrong in the areas FDA questioned.

For example, could someone gain unauthorized access through a cloud connection? Could an attacker alter patient data or interrupt a critical device function?

A structured method such as STRIDE can help identify threats systematically.

Document each relevant threat, where it could occur, and the assumptions behind your analysis. Don't limit the review to vulnerabilities you've already discovered.

Step 4: Connect threats to security controls

Finding a threat is one thing. Showing how you've addressed it is another.

For each identified threat, explain which security controls reduce the risk. These might include authentication, encryption, access restrictions, or software integrity checks.

Make those connections easy to follow. FDA reviewers shouldn't have to search through multiple documents to figure out which control addresses which threat.

Step 5: Update the cybersecurity risk assessment

Changes to the threat model may also affect your cybersecurity risk assessment.

Review the newly identified threats, their exploitability, and the potential consequences if an attack succeeds. Document the risks before and after mitigation, using your established risk assessment method.

If a cybersecurity risk could lead to patient harm, make sure it's appropriately connected to the device's safety risk assessment.

The goal is consistency. Your threat model and risk assessment should tell the same story.

Step 6: Prepare the revised documentation

Finally, assemble the updated materials into a clear response.

Include the revised threat model, supporting diagrams, updated risk assessments, and any additional evidence needed to address FDA's concerns.

Explain what changed and where reviewers can find the supporting information. A simple response table that matches each deficiency to the revised documentation can make this easier.

Remember, the objective isn't to overwhelm FDA with paperwork. It's to demonstrate that you've addressed the specific gaps identified in the review.

What documentation should accompany the response?

You've identified the gaps and updated your threat model. Now comes the next challenge: showing FDA exactly what you've done to address its concerns.

The key is providing a clear, organized set of documents that answers the reviewer's questions. Depending on the deficiency, that may involve more than submitting a revised threat model.

The revised threat model

Start with an updated threat model that addresses the specific issues FDA identified. It should explain the methodology used, the system components evaluated, the threats identified, and the assumptions behind your analysis.

Be sure to document how those threats are addressed. If you've added previously overlooked components or interfaces, make those changes easy to identify.

Updated diagrams and supporting documentation

Your diagrams should reflect how the device actually operates, including relevant external connections, data flows, and trust boundaries.

For example, if FDA questioned whether your threat model adequately covered cloud connectivity, an updated diagram should show how data moves between the device, the network, and the cloud environment.

Supporting documentation should also explain any security controls that aren't immediately clear from the diagrams.

Traceability between threats, risks, and controls

FDA reviewers need to understand how the pieces fit together.

One practical approach is to create a table connecting each identified threat to its associated cybersecurity risk, mitigation, and supporting verification evidence.

This makes it easier to follow the manufacturer's reasoning and see how identified threats have been addressed.

FDA doesn't require this exact table format, but clear traceability can help demonstrate that the cybersecurity analysis is complete and consistent.

A response explaining what changed

Don't leave FDA reviewers guessing about what's different.

Include a written response that addresses each deficiency individually. Explain what was missing, what you changed, and where the updated information appears in the submission.

Refer to specific documents, sections, or tables whenever possible.

The goal is simple: Give FDA a clear path from the original concern to the evidence showing how you've addressed it.

How to avoid another FDA cybersecurity deficiency letter

Nobody wants to go through the same FDA review problem twice. The best way to avoid another FDA cybersecurity deficiency letter is to make threat modeling part of your regular development process, not something you scramble to finish before submitting your device.

Start early. Your threat model should evolve alongside the device, especially when you introduce new software, external connections, or cloud services.

It's also worth bringing cybersecurity specialists into design reviews. They may spot threats that engineers focused on device functionality haven't considered.

And don't overlook documentation. Keep a clear record of identified threats, associated risks, security controls, and verification results. That way, you won't have to reconstruct your reasoning months later.

Finally, review the entire threat modeling package before submission. Make sure the diagrams, risk assessments, and supporting documents agree with one another.

The idea is to catch missing information before FDA does. A little extra attention during development can save considerable time and frustration during regulatory review.

How CyberMed helps manufacturers address threat model deficiencies

You can address a threat model deficiency by making threat modeling part of the regular development process rather than treating it as a last-minute submission requirement.

Start early and update the threat model as the device evolves. New software components, external connections, cloud services, wireless interfaces, and changes to the intended use can introduce new attack paths or alter existing risks.

Manufacturers should also involve cybersecurity specialists in design reviews and risk assessments. Cross-functional review can reveal threats that engineers focused primarily on device functionality may not identify.

Documentation is equally important. Maintain a clear record of identified threats, associated risks, security controls, assumptions, and verification results. Each threat should be traceable to the relevant risk assessment, mitigation, and testing evidence.

When FDA issues an additional information request, cybersecurity documentation may need more than a few minor revisions. Manufacturers should address the underlying gaps rather than simply adding text to the submission. That may mean updating the threat model, revising the risk assessment, strengthening security controls, or providing additional testing evidence.

Before submission, review the complete threat modeling package for consistency. Diagrams, attack paths, risk assessments, security requirements, test results, and supporting documents should describe the same device and threat environment.

The goal is to identify and correct missing or inconsistent information before FDA reviewers do. A disciplined, continuously updated threat modeling process can reduce review delays and demonstrate that cybersecurity risks have been systematically evaluated and addressed.

Sources

1. U.S. Food and Drug Administration. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. February 2026. https://www.fda.gov/media/119933/download
2. U.S. Food and Drug Administration. Types of Communication During the Review of Medical Device Submissions. April 2014. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/types-communication-during-review-medical-device-submissions
3. U.S. Food and Drug Administration. Developing and Responding to Deficiencies in Accordance with the Least Burdensome Provisions. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/developing-and-responding-deficiencies-accordance-least-burdensome-provisions
4. U.S. Food and Drug Administration. 510(k) Submission Process. https://www.fda.gov/medical-devices/premarket-notification-510k/510k-submission-process
5. U.S. Food and Drug Administration. Cybersecurity. https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity