Cybersecurity is one of the most common reasons FDA premarket submissions get held up. Not because manufacturers skip it, but because submitted documentation doesn’t adequately address the FDA’s expectations.
The cybersecurity documentation FDA reviewers need isn’t just proof that you thought about security—it should be structured, traceable evidence that demonstrates how you have incorporated security into your device systematically, from architecture design through testing and into the post-market phase.
Gaps happen not because companies ignore cybersecurity, but because they don’t know exactly what the FDA needs to see, or how to present it.
Here are the four areas where we see submissions fall short most often, and what you can do to resolve each one.
Gap #1: Threat Models That Aren’t Grounded in Your Device’s Reality
Threat Models and downstream Security Risk Assessments should not be considered checkboxes to be completed. They are living documents that map specific security risks to your specific device, demonstrate how you evaluated each risk, and link your implemented risk mitigations back to those findings.
A generic threat model that lists categories of cybersecurity risks (spoofing, tampering, denial of service) without demonstrating how your team evaluated those threats in the context of your device’s actual architecture, intended use, and patient population doesn’t make the cut.
The cybersecurity documentation that FDA reviewers need goes beyond a list of generic threats. FDA premarket cybersecurity guidance makes clear that threat modeling should be grounded in the device’s real-world deployment environment.
That means thinking through questions like:
- Where will this device live—in a hospital network, a home environment, a clinical lab?
- Who connects to it, and with what level of trust?
- What’s the worst-case patient impact if a specific vulnerability is exploited?
- Are there network-dependent features that could fail if connectivity is lost?
Those questions should shape both your threat model and your design decisions, and two things in particular are worth calling out:
1. Design for the Deployment Environment, Not Just the Device
Healthcare delivery organizations are increasingly vocal about a frustration many device makers don’t anticipate: their devices can become liabilities when hospitals can’t control how they behave on a network. If your device has network-dependent features, your threat model and risk assessment should address what happens when connectivity is lost, not just what happens when it’s compromised.
2. Cybersecurity Accountability Can’t Live With One Team
If your threat model is created by a single engineer on the software team, your threats will reflect software vulnerabilities and miss the bigger picture. Security risk decisions touch regulatory strategy, quality, IT architecture, and legal. The FDA is looking for a risk-based culture that supports cross-functional security risk identification.
Suggested Strategies for Resolving Gap #1
Use a recognized threat modeling methodology (STRIDE, PASTA, or similar), document your assumptions about the deployment environment explicitly, and ensure that your threat assessment is developed with input from across your organization. Additionally, your downstream security risk assessment should trace every identified threat to a control or an accepted residual risk with justification.
Gap #2: Architecture Views That Leave FDA Reviewers Guessing
Your device’s security architecture documentation needs to clearly show FDA reviewers what your device is, how it communicates, and where your security controls live, so they don’t have to ask.
This is one of the most underestimated parts of an FDA cybersecurity submission. This work helps set the tone for the FDA submission and demonstrates the strength and rigor of the cybersecurity approach and deliverables. Companies often provide a general system diagram and assume it speaks for itself, but it usually doesn’t.
FDA wants to see a set of architecture views that comprehensively answer the following questions:
- What are the hardware and software components of this device?
- What are the interfaces—network, wired, wireless, external service connections?
- Where does data flow, and what does it contain?
- Which components are trusted, and how is trust established?
- How is the system’s software updated in the field?
- Where are security controls implemented, and which specific controls address which threats?
- How does the system “fit” within the overall use environment, and what are the trust boundaries?
- How might a user or malicious actor interact with the system?
Architecture documentation also has an organizational dimension that’s easy to overlook. The choices reflected in your architecture—what data the device stores, what it transmits, how it authenticates—are made by engineers, but they have regulatory, legal, usability, and patient safety implications that require cross-functional sign-off. If your security architecture was designed in isolation by a single team or person, it may not reflect all of those considerations, and reviewers can tell.
Suggested Strategies for Resolving Gap #2
Plan for multiple architecture views early in development (even during feasibility, before you’re working on design inputs), not as a documentation afterthought. The FDA’s premarket cybersecurity guidance defines four views that manufacturers should address at a minimum:
- Global System View: A high-level picture of your entire system (device, cloud, apps, networks, external connections) that shows system boundaries, major components, and interfaces, giving reviewers a clear sense of the overall attack surface.
- Multi-Patient Harm View: A focused look at scenarios where a cybersecurity failure could affect more than one patient, highlighting shared resources, centralized services, or systemic failure modes that go beyond a single-device incident.
- Updatability/Patchability View: Documentation of how your device can be updated, patched, or remediated in the field, including update channels, authentication, and integrity protection, which speaks directly to the FDA’s expectations for post-market vulnerability management.
- Security Use Case View(s): Scenario-based views that walk through real-world interactions (login, data transfer, remote access), showing data flows, communication paths, protocols, and how security controls are applied throughout.
These views matter beyond checking a box. Reviewers use them to assess the overall strength and rigor of your cybersecurity approach. Strong views signal a mature development process, while weak or vague ones tend to invite deeper scrutiny across your entire submission.
Gap #3: Security Testing That Stops at Verification
Verification testing confirms that your security controls are implemented correctly. It does not confirm that your device is actually resistant to attack. A testing strategy that demonstrates both security control efficacy as well as overall system security is necessary for an FDA premarket cybersecurity submission, and bypassing the latter is a common mistake.
The FDA expects to see security testing that actively attempts to identify and exploit vulnerabilities—not just testing that confirms your stated controls are present. This typically includes penetration testing facilitated by qualified, independent testers.
A few things manufacturers frequently get wrong:
- Testing Scope Is Too Narrow: Penetration testing is sometimes scoped to just the device itself, without including the interfaces, cloud components, or mobile applications that are part of the actual system. The FDA’s view of your “device” includes everything that needs to be secure for the device to be safe. Additionally, the scope of testing performed should reflect FDA’s expectations for vulnerability testing, including but not limited to abuse or misuse cases that evaluate your system’s robustness against malformed or unexpected inputs.
- Testing Happens Too Late: Security testing scheduled for the tail end of development doesn’t leave room for meaningful remediation. Issues found during verification or penetration testing can require architectural changes, which, at a late stage of device development, are expensive and potentially timeline-threatening. Integrating security testing earlier, in parallel with software and hardware development, can mitigate the need for late-stage design changes that derail development budgets and timelines.
- Results Aren’t Tied Back to the Risk Assessment: Even well-executed security testing creates a submission gap if the findings aren’t fed back into your Security Risk Assessment and evaluated in accordance with your defined criteria for risk acceptability. Every identified vulnerability should either be remediated (with evidence) or accepted as residual risk (with explicit justification). Reviewers will follow that thread.
Suggested Strategies for Resolving Gap #3
Engage a qualified third party for penetration testing early enough in your development process that findings can inform your design. Additionally, make sure your testing results are formally documented and reconciled with your risk assessment so reviewers can trace the complete thread from threat to control to validation.
Gap #4: No Plan for Post-Market Cybersecurity Management
Clearing the FDA is not the finish line for cybersecurity. Section 524B compliance requires manufacturers to have a documented plan for how they’ll monitor, identify, and respond to vulnerabilities after their device is on the market. Submissions that treat this as an afterthought signal to reviewers that the development team hasn’t thought through the full device lifecycle.
A strong post-market cybersecurity plan addresses:
- How you’ll monitor for new vulnerabilities across your device and its components
- How quickly you’ll triage and remediate identified issues
- How you’ll handle coordinated vulnerability disclosure
- How you’ll communicate with healthcare customers about security updates
The Software Bill of Materials (SBOM) is what makes this plan actionable. A complete inventory of every commercial, open-source, and off-the-shelf software component your device relies on isn’t just a submission requirement—it’s the tool that allows you, regulators, and healthcare customers to quickly assess exposure when new vulnerabilities are disclosed. Without a functional SBOM, post-market vulnerability management is essentially guesswork.
This is also where the manufacturer-HDO relationship gets strained. Many healthcare delivery organizations have flagged the same issue: bundling security patches with paid upgrades makes it financially difficult for hospitals to stay secure. Proactively addressing how you’ll handle post-market security updates (and committing to transparent vulnerability disclosure) builds the kind of trust that matters for long-term market access.
Suggested Strategies for Resolving Gap #4
Develop your post-market vulnerability management plan before submission, not after. Make sure your SBOM is complete, in a standard machine-readable format, and maintained as the device evolves—not generated once at submission time and forgotten. Additionally, you should consider how your plans to deploy security patches or updates impact your relationship with HDOs. Not only should you consider how the frequency of patches impacts system downtime at an HDO, but it is also critical to ensure HDOs don’t face roadblocks to ensuring system security.
FDA Premarket Cybersecurity Gaps Are Regulatory Gaps
Every one of these gaps is ultimately a regulatory clearance and approval issue. An incomplete FDA cybersecurity submission doesn’t just slow down your review—it signals to the FDA that your development process may not be mature enough to support the claims you’re making about device safety and security.
The companies that get through premarket cybersecurity review efficiently are the ones that planned for it. They integrated cybersecurity thinking into architecture decisions early, built documentation alongside the device rather than after it, and connected their security work to their broader regulatory strategy from the start.
Close Cybersecurity Gaps Before They Close Your Submission
CMD MedTech has been working in medical device cybersecurity since before formal FDA guidance existed. Our team includes one of the authors of TIR 57, the first technical information report on medical device cybersecurity, and we’ve navigated both pre-market submissions and post-market compliance for a wide range of device types.
We bring the same regulatory intelligence that shapes our 510(k) clearance and PMA work to cybersecurity submissions—helping you close gaps before they delay your path to market.
Contact CMD MedTech to discuss your cybersecurity submission needs and learn how we can help you prepare documentation that meets FDA expectations the first time.