FDA Cybersecurity Documentation Requirements for Medical Device Submissions

Submitting a connected medical device to the FDA involves more than attaching a few cybersecurity reports to your application. You need to show how your team identified security risks, tested the device, applied controls, and planned to manage vulnerabilities after release.

This level of evidence matters because weaknesses in connected devices can lead to serious consequences. An academic review of FDA safety communications found that 94% of the reported medical device cybersecurity vulnerabilities were classified as high severity. These weaknesses could allow remote access, code execution, or disruption of device functions.

Given the potential impact, manufacturers need to understand what the FDA actually expects. FDA cybersecurity documentation is not a fixed package of 14 or 20 separate files. Section 524B defines binding requirements for qualifying cyber devices, while FDA guidance explains the evidence needed to support those requirements.

This article will help you prepare that evidence, connect related records, and present them clearly for FDA review.

Key Takeaways

• Not every connected product falls under Section 524B. The law applies only when all three parts of the FDA cyber device definition are met.
• For a covered device, manufacturers need to account for software components and show how vulnerabilities, disclosures, patches, and updates will be managed after release.
• FDA is more concerned with the quality of the evidence than the number of separate files included in the submission.
• Penetration testing is valuable when it confirms real attack paths and verifies fixes. It still forms only one part of a wider process that includes secure development, risk management, and lifecycle planning.

What FDA Requires Under Section 524B

Section 524B creates binding FDA cybersecurity requirements for qualifying cyber devices. FDA guidance provides nonbinding recommendations, while voluntary standards can support the evidence submitted.

Manufacturers must provide a postmarket vulnerability plan, cybersecurity processes, update and patch procedures, and an SBOM covering commercial, open source, and off-the-shelf software.

The FDA reviews the complete evidence package to determine reasonable assurance of cybersecurity. One report, certificate, or standard alone is not enough. Cybersecurity must also connect with design controls, risk management, supplier controls, software validation, CAPA, and postmarket activities.

Does the Product Qualify as an FDA Cyber Device?

A medical device qualifies as a cyber device only when it meets all three conditions defined under Section 524B.

1. The Product Includes Software

The device must contain software that the sponsor has validated, installed, or authorized. This includes embedded software, firmware, and software that supports the device’s operation.

2. The Product Can Connect to the Internet

The connection does not need to be continuous or direct. It can occur through Wi Fi, Bluetooth, Ethernet, cellular networks, cloud APIs, mobile applications, hospital gateways, USB ports, removable media, or service interfaces.

3. The Technology Could Be Vulnerable to Cybersecurity Threats

The product must contain technological characteristics that could expose the device or its related systems to cybersecurity threats.

Your applicability assessment should identify product and software versions, connectivity paths, supporting systems, deployment assumptions, and the reason for including or excluding the device.

Examples can include cloud-hosted SaMD, mobile-connected wearables, imaging workstations, devices linked through hospital gateways, and products with USB service interfaces.

Which Medical Device Submissions Need Cybersecurity Information?

Section 524B applies across several premarket pathways when the product meets the definition of a cyber device. The amount of supporting evidence will vary based on the device architecture, connectivity, software complexity, clinical function, potential harm, submission type, and scope of any proposed modification.

When using eSTAR, manufacturers must provide accurate cybersecurity responses and attach files that directly support each answer. Clear file names and cross-references help reviewers locate the evidence. Inaccurate answers or irrelevant attachments can place the submission on a Technical Screening hold.

FDA Cybersecurity Documentation Checklist

The FDA does not require a fixed number of cybersecurity documents; submissions should instead provide sufficient linked evidence covering the device, its risks, controls, and verification methods. Use this checklist as a guide rather than a mandatory document list.

1. Cyber Device Applicability and Cybersecurity Overview

Begin with a concise overview that defines what the submission covers. Include:

1. The cyber device determination and the reasoning behind it
2. The relevant premarket submission pathway
3. Product models, variants, and configurations within scope
4. Software, firmware, mobile application, and cloud service versions
5. The systems, interfaces, and functions included in the cybersecurity review
6. Key attack surfaces, such as wireless connections, service ports, APIs, and external platforms
7. FDA guidance and recognized standards used during development and testing
8. A summary of the main security controls and any residual risks that remain after risk controls

This overview should help the reviewer understand the product boundaries before reviewing the detailed architecture, threat modeling, testing, and risk management evidence.

2. Security Architecture

The Security Architecture describes how the physical device, its software, cloud-based backend, and networking components interoperate and interact. This provides the FDA review team with an overview of your entire digital ecosystem.

It outlines how information flows within the system, what user types exist, and where encryption is employed. Security architecture also defines trust boundaries across all connections, including mobile applications, hospital gateways, and electronic health record integration. It demonstrates that your solution is designed with patient privacy and security in mind.

3. Threat Modeling Report

This report checks your devices’ setup to show how an attacker can access the system, modify the data, or disrupt functions. It checks the entry points, potential abuse cases, and clinical environments to connect security risks with patient safety. A clear threat modeling report gives FDA reviewers proof that you caught and handled all the weaknesses clearly.

• The key characteristics include:
• Maps all the entry points of a possible attack
• Assesses real-world threats
• Analyzes the impact
• Secures hospital pathways 
• Documents residual risks

4. Software Bill of Materials (SBOM)

An SBOM contains a comprehensive list of all third-party, commercial, and open-source software components used in the construction of your medical device. The SBOM provides information to FDA reviewers on all the software components that have been used. It includes their versions, suppliers, and dependency relationships.

The SBOM satisfies the Section 524B provisions by ensuring that there is full transparency regarding your software codebase. An accurate and machine-readable Software Bill of Materials (SBOM) will help your company identify any security vulnerabilities in the software.

5. Software Level of Support & End of Support

The Software Level of Support and End-of-Support Report outlines the current level of support for the software components of a particular medical device. It states the software version that is currently supported, EOS, and unsupported software.

It usually includes:

• Software or component name and version
• Vendor and support status
• Release and end-of-support dates
• Unsupported or obsolete software
• Availability of security updates and patches
• Upgrades and replacement
• Potential security and compliance risks

6. Penetration Testing Report

Penetration Testing Report is evidence that security testing has been done on your device, website portals, mobile applications, and cloud endpoints. The report ensures FDA reviewers know that you have conducted actual tests on your system using real attack vectors.

The report contains information related to your test methodology, the software and tools used, and the vulnerabilities discovered during the process. Reproduction steps and severity levels of each vulnerability are clearly described in the report.

7. Retesting Report

The Retesting report contains follow-up tests to the initial penetration testing, confirming that all vulnerabilities identified have been addressed.  It proves that you not only identified security issues, but also addressed them and fixed them with secondary testing.

This links each vulnerability to its patch and shows the updated severity scores and retest evidence. It also confirms that the fix worked without introducing new security issues.

This provides regulators with clear evidence that the system is secure and ready for deployment. 

8. Security Assessment of Unresolved Anomalies

Security Assessment of Unresolved Anomalies looks for any previously identified bugs, glitches, or unpatched elements in your system before you launch. It demonstrates that you have found all anomalies and analyzed their possible security implications. Determined that they are not exploitable to cause harm to patients or compromise data.

It highlights the root cause, the severity rating, and the compensating controls for each remaining issue and explains why it’s safe to leave it unresolved for this release. This provides clear evidence to regulators that your team is actively working to improve your quality. 

9. Cybersecurity Risk Assessment

Cybersecurity Risk Assessment links cyber threats to patient safety and clinical activities. It illustrates to FDA evaluators that cyber attack scenarios, including data manipulation and disruptions in operations, have been identified. Also shows that carefully analyzed in relation to their effects on patients before the launch of the product.

• Identifies how cybersecurity threats can result in patient harm
• Determines the probability and potential effect of each threat
• Correlates existing security controls to threat scenarios
• Assesses residual risk to validate that residual risks are acceptable

10. Safety & Security Risk Assessment of Vulnerabilities

The Safety & Security Risk Assessment of Vulnerabilities analyzes known weaknesses in your system, like outdated libraries, unpatched code, or exposed ports, and determines if they can be exploited and impact patient safety or performance. It translates these technical risks directly into clinical impact and prioritizes fixes according to the level of real-world risk.

This document will show FDA reviewers that you considered each of the security gaps and assessed them against patient risk. It provides information on the measures taken to address problems that can’t be addressed immediately. This confirms that any outstanding problems are at an acceptable level of risk and won’t impact device safety. 

11. Cybersecurity Control

The Cybersecurity Control document lists the technical, operational, and physical controls that have been incorporated into your device to help protect it from cyber threats. It explains how your design proactively secures, protects, and safeguards information, and how it ensures continuous safe operation in clinical environments.

This document makes it easier for FDA reviewers to see how each safeguard corresponds to a known security standard such as NIST or ISO/IEC standards. It shows that security controls are not just tacked on at the end of the system, but are integrated throughout the system. 

12. Cybersecurity Risk Management Report

The Cybersecurity Risk Management Report is the complete report you’ll present to FDA. It collates threat models, vulnerability tests, and security controls into a single document to demonstrate the safety of your device for clinical use.

This report is proof that all digital threats have been brought down to a level that is acceptable, and that your device is safe. It also helps you describe your long-term strategy for dealing with new vulnerabilities and providing secure updates after launch. 

13. Cybersecurity Labeling

The Cybersecurity Labeling provides essential security instructions and transparency for the end users of your device. It provides information on the system requirements, residual risks, and operational safeguards to healthcare, IT administrators, and patients to enable secure deployment and maintenance.

This documentation clearly demonstrates FDA review and that you implemented safe operational practices throughout the product’s lifecycle.  Also implemented through policies for software updates, network configuration requirements, and emergency response procedures.

• Provides information on IT and users 
• Describes how software patches and security fixes are provided
• Ensures health systems understand necessary local safeguards

14. Cybersecurity Metrics

This document defines the key metrics used to monitor and assess your device’s security. It provides FDA reviewers with concrete data such as defect density, patch response times, and vulnerability containment rates. This proves your security controls are actively measured rather than documented.

This document sets these clear parameters to show a data-driven approach for ensuring device integrity during development and postmarket deployment. It provides the regulators with clear proof that you systematically monitor code quality, track update adoption, and respond rapidly to emerging threats.

15. Cybersecurity Risk Management Plan

The Cybersecurity Risk Management Plan is a document that details the strategy you will use to manage cybersecurity risks during your device’s lifecycle. It gives FDA reviewers the roadmap for security’s inclusion throughout the design and deployment process.

This document clarifies the roles, risk acceptability, and test procedures, thereby giving regulators a clear idea that security is part of the system. It helps your team follow the same risk management and patching procedures with consistent practices during the product lifecycle. 

Avoid FDA 510(k) Submission Delays

Avoid costly FDA 510(k) delays by identifying SBOM compliance gaps before submission.

Book an FDA Gap Assessment →

How the Cybersecurity Evidence Should Trace Together

Before filing, compare every document against the exact product build proposed for release. Component versions, system boundaries, test environments, and supported configurations should remain consistent throughout the submission.

Pay close attention to unresolved findings. Their treatment should match the final risk decision, user instructions, and postmarket monitoring plan. Update and recovery claims should also reflect the functions verified during testing.

Any mismatch can make the evidence difficult to follow and lead to additional FDA questions.

Cybersecurity Documentation for Device Modifications

A device change can require updated FDA cybersecurity documentation when it affects:

• Software or firmware
• Connectivity, interfaces, or data flows
• Authentication or cryptographic controls
• Cloud services or mobile applications
• Third-party components
• Update mechanisms or logging
• Security controls or the deployment environment

Revise only the evidence affected by the modification. Depending on the change, this could include the architecture, threat model, risk report, SBOM, vulnerability assessment, testing records, labeling, or postmarket plan.

When the change is not expected to affect cybersecurity, document:

• Why the attack surface and security architecture remain unchanged
• Why the previous evidence is still valid
• Whether component versions or known vulnerabilities changed
• Which earlier submission records support the conclusion

A statement of “no cybersecurity impact” needs a documented assessment behind it.

Common Documentation Problems That Can Delay FDA Review

• Generic Threat Models: A threat model should reflect the actual device, connected systems, and deployment environment. A standard template with no product-specific detail gives reviewers little useful evidence.

• Inconsistent Product Versions: Architecture diagrams, SBOMs, test reports, and labeling must refer to the same build. Version mismatches can create uncertainty about what was assessed.

• Weak Risk Traceability: Cybersecurity risks should connect to patient or clinical harm. Test findings must also trace to controls, remediation, and residual risk decisions.

• Incomplete SBOM Reviews: An SBOM alone is not enough. Known vulnerabilities need an applicability assessment, disposition, and clear treatment plan.

• Unsupported Components: Components that are no longer supported need compensating controls, monitoring, and a lifecycle plan.

• Late Penetration Testing: Testing completed near submission leaves little time for remediation and retesting. It can also expose gaps that should have been addressed earlier.

• Unproven Update Capabilities: Patch plans should be supported by secure update, rollback, and recovery testing. Written claims without test evidence are weak.

• Unclear Environmental Assumptions: Do not rely on hospital firewalls or network segmentation without defining the minimum security conditions required for safe deployment.

• Testing Used as a Substitute: External penetration testing does not replace secure development, threat modeling, or cybersecurity risk management.

• Cybersecurity Outside the QMS: Cybersecurity records should be integrated into design and quality processes. Adding them after development can create gaps in traceability and control.

How Qualysec Can Support FDA Cybersecurity Testing

Qualysec supports the technical testing needed for medical device submission preparation. Its team can assess connected devices, embedded software, mobile apps, web portals, APIs, cloud infrastructure, external networks, and IoT communication paths.

The assessment combines manual testing with automated tools to:

• Confirm vulnerabilities instead of relying only on scanner output
• Test authentication, authorization, business logic, and chained attack paths
• Reduce false positives
• Provide clear reproduction steps
• Recommend practical remediation
• Retest fixes before submission

The resulting evidence can support penetration test reports, threat model validation, control verification, vulnerability disposition, remediation records, and residual risk decisions.

Penetration testing does not replace the SPDF, SBOM, risk management file, labeling, or lifecycle plans. It strengthens the technical evidence within the wider submission package.

Conclusion

Submission readiness depends on clear, consistent, and traceable cybersecurity evidence. The number of files matters less than whether each record supports the same product version, risk decisions, controls, test results, and residual risk conclusions, including a clear cybersecurity deficiency response where applicable.

Cybersecurity documentation should begin during architecture and development, not shortly before filing. Early preparation gives manufacturers enough time to resolve gaps, complete retesting, and confirm that the final submission reflects the device intended for market release.

Contact Qualysec before the final submission stage so your team has enough time to fix issues and complete retesting. You can request a scoped assessment, consultation, quotation, or sample report based on your device and submission pathway.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQs

1. What cybersecurity documents are required in an FDA medical device submission?

There is no universal FDA checklist with a fixed number of files. Manufacturers should submit device-specific evidence covering the security architecture, risk analysis, controls, testing, SBOM, labeling, and postmarket planning. The exact package depends on the product design, risk profile, and submission type.

2. Which FDA submissions are subject to Section 524B?

Section 524B applies to qualifying cyber devices submitted through 510(k), PMA, De Novo, HDE, or Product Development Protocol pathways. It can also apply to relevant supplements or modifications when the change requires a new premarket submission and affects the device’s cybersecurity evidence.

3. What qualifies as a cyber device under FDA law?

A product qualifies as a cyber device when it contains sponsor-authorized software, can connect to the internet, and includes technology that could be exposed to cybersecurity threats. The connection can be direct, indirect, or intermittent through services, gateways, mobile apps, or other supporting systems.

4. Is an SBOM required for every medical device?

No. The statutory SBOM requirement applies to devices that meet the Section 524B definition of a cyber device and enter an applicable premarket pathway. Other products can still need component information when it is necessary to explain software risks, dependencies, or vulnerability management.

5. Does the SBOM need to include open source software?

Yes. For covered cyber devices, the SBOM must account for commercial, open source, and off-the-shelf software included in the product. Manufacturers should identify versions clearly and evaluate known vulnerabilities so the component record matches the tested build and related risk decisions.

6. Does IEC 81001 5 1 compliance satisfy FDA requirements?

No. IEC 81001 5 1 can support evidence that cybersecurity activities were built into the product lifecycle, but it does not replace device-specific documentation. FDA still expects appropriate risk analysis, architecture, SBOM details, verification results, labeling, and postmarket plans for the submitted product.

7. Can missing cybersecurity attachments delay an eSTAR submission?

Yes. An eSTAR can be placed on technical screening hold when cybersecurity responses are inaccurate or the supporting attachments are missing or irrelevant. Clear answers, suitable file names, and direct cross-references help FDA reviewers locate the required evidence and reduce avoidable screening delays.