This post describes key requirements for medical device manufacturers to follow when submitting their devices to US FDA for PMA or 510K approvals.
The United States Food and Drug Administration (FDA) provides guidance on cybersecurity in medical devices, outlining both recommended activities and documentation for premarket submissions like 510(k)s and Premarket Approval Applications (PMAs). For a specific category of devices known as “cyber devices,” certain documentation is required by statute based section 524B of FD&C Act as updated on December 2022.
FDA published an updated pre-market guidance was published by FDA on June 2025. Our recent post discusses the changes in the new guidance compared to the one released in 2023.
This guidance applies to devices with cybersecurity considerations, which includes, but is not limited to, devices with software functions, or that contain software (including firmware) or programmable logic, regardless of whether they are network-enabled or have connected capabilities. It also applies to combination products where the device constituent part presents cybersecurity considerations.
Generally, the cybersecurity design and documentation in a premarket submission are expected to scale with the cybersecurity risk of the device. The recommendations aim to help manufacturers demonstrate a reasonable assurance of safety and effectiveness, which includes adequate device cybersecurity.
Here is a list of activities and documents recommended or required for 510(k) and PMA submissions:
Recommended Documentation and Activities for All Devices with Cybersecurity Risks
The following documentation elements are recommended for all premarket submissions for devices with potential cybersecurity risks, including 510(k)s and PMAs:
- Security Risk Management Report: This report should summarize risk evaluation methods, detail residual risk conclusions, describe risk mitigation activities, and provide traceability. It includes outputs from the following processes:
- Threat Model: Threat modeling systematically identifies potential threats, vulnerabilities, and attack pathways across the device’s architecture, including hardware, software, data flows, and network interfaces. The activity should define assets to protect, potential adversaries, their capabilities, and likely attack vectors, and then map these against safeguards and mitigations. This ensures that cybersecurity risks are proactively addressed throughout the device lifecycle. This should be performed throughout the design process and be inclusive of all medical device system elements.
- Cybersecurity Risk Assessment: Assessment of security risks and controls for residual risks, focusing on exploitability. This should capture risks and controls identified from the threat model. It is distinct from safety risk management.
- Software Bill of Materials (SBOM): A formal inventory of software components and dependencies, including proprietary, purchased/licensed, and open-source software, and their upstream dependencies. This should be machine-readable and include the software level of support and end-of-support dates.
- Vulnerability Assessment and Software Support: Identification and assessment of all known vulnerabilities (including those in CISA’s Known Exploited Vulnerabilities Catalog) associated with the device and its software components. This includes a safety and security risk assessment for each vulnerability and details of applicable risk controls.
- Security Assessment of Unresolved Anomalies: Evaluation of the security implications of any software anomalies discovered during development or testing, considering potential security impacts and Common Weakness Enumeration (CWE) categories.
- Traceability: Documentation showing the links between the threat model, cybersecurity risk assessment, SBOM, testing documentation, and other relevant cybersecurity risk management documentation.
- Measures and Metrics: Tracking and recording of measures such as the percentage of identified vulnerabilities updated/patched, duration from vulnerability identification to patching, and duration from patch availability to implementation in deployed devices.
- Security Architecture Views: These views provide security context and trust-boundaries of the medical device system, demonstrating how cybersecurity risks are controlled. They should include diagrams and explanatory text with sufficient detail to understand how assets function holistically. The number and extent of views depend on the identified attack surface and risk. At a minimum, the FDA recommends:
- Global System View: Describes the overall medical device system and all internal and external connections, including software update infrastructures, healthcare facility network impacts, and cloud connections.
- Multi-Patient Harm View: Addresses how the device and its system defend against or respond to attacks with the potential to harm multiple patients due to connectivity.
- Updatability and Patchability View: Describes the end-to-end process for securely and timely providing software updates and patches to the device.
- Security Use Case View(s): Covers all medical device system functionality through which a security compromise could impact device safety or effectiveness.
- Implementation of Security Controls: Documentation demonstrating that security controls (e.g., authentication, authorization, cryptography, code/data/execution integrity, confidentiality, event detection/logging, resiliency/recovery, and updatability/patchability) have been implemented and tested effectively.
- Cybersecurity Testing Documentation: This demonstrates the effectiveness of design controls beyond standard software verification and validation activities. It should include:
- Evidence of security requirements implementation and boundary analysis.
- Details and evidence of threat mitigation testing.
- Details and evidence of vulnerability testing, such as abuse/misuse cases, fuzz testing, attack surface analysis, vulnerability chaining, closed box testing, software composition analysis, and static/dynamic code analysis.
- Penetration testing reports, detailing independence and technical expertise of testers, scope, duration, methods, and results.
- Labeling: To ensure cybersecurity transparency and safe use, labeling should include relevant security information understandable to the intended user. Examples include:
- Device instructions and product specifications for recommended cybersecurity controls.
- Detailed diagrams for implementing cybersecurity controls.
- A list of network ports and other interfaces, with descriptions and direction of data flow.
- Guidance on supporting infrastructure requirements for secure operation and instructions on how to respond to vulnerabilities.
- SBOM information, continuously available to users in a machine-readable format.
- Systematic procedures for downloading version-identifiable software and firmware updates.
- Description of how the device responds to anomalous conditions (security events), including user notification and logging.
- Description of features protecting critical functionality, backup/restore procedures, and secure configuration of shipped devices.
- Information on how forensic evidence is captured.
- Information on device cybersecurity end of support and end of life.
- Cybersecurity (Vulnerability) Management Plan: A plan for identifying and communicating postmarket vulnerabilities, supporting security risk management processes. Elements should include:
- Personnel responsible.
- Sources, methods, and frequency for monitoring and identifying vulnerabilities (e.g., researchers, NIST National Vulnerability Database, third-party software manufacturers).
- Procedures to identify and address vulnerabilities in CISA’s Known Exploited Vulnerabilities Catalog.
- Periodic security testing plans.
- Timeline to develop and release patches.
- Update processes and patching capability.
- Description of the coordinated vulnerability disclosure process.
- Description of how the manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.
Required Documentation for “Cyber Devices”
For “cyber devices” – defined as devices that (1) include software validated, installed, or authorized by the sponsor as a device or in a device; (2) have the ability to connect to the internet; and (3) contain technological characteristics vulnerable to cybersecurity threats – the following information is required by section 524B of the FD&C Act for 510(k), PMA, Product Development Protocol (PDP), De Novo, or Humanitarian Device Exemption (HDE) submissions:
- Plans and Procedures (Section 524B(b)(1)):
- A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure and related procedures. This must address the items discussed in the general Cybersecurity Management Plan recommendations.
- The plan must also describe the timeline for developing and releasing updates and patches for known unacceptable vulnerabilities (on a reasonably justified regular cycle) and for critical vulnerabilities that could cause uncontrolled risks (as soon as possible out of cycle).
- Processes and Procedures to Provide Reasonable Assurance of Cybersecurity (Section 524B(b)(2)):
- Documentation demonstrating that the manufacturer has designed, developed, and maintained processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure. The documentation recommendations outlined throughout this guidance (and summarized above) are intended to help meet this obligation.
- Software Bill of Materials (SBOM) (Section 524B(b)(3)):
- An SBOM, including commercial, open-source, and off-the-shelf software components, must be provided. This SBOM should contain the information recommended in Section V.A.4.b (as described in the general recommendations above).
Documentation for Device Modifications
If a modification to a cyber device necessitates a new 510(k) or PMA submission, the section 524B requirements still apply. The information needed will vary based on whether the change impacts cybersecurity:
- Changes That May Impact Cybersecurity: For changes like alterations to authentication or encryption algorithms, new connectivity features, or changes to software update mechanisms, the full required and recommended documentation from Section VII.C of the guidance is expected.
- Changes Unlikely to Impact Cybersecurity: For changes such as material alterations, sterilization method changes, or algorithm modifications without affecting architecture/software structure/connectivity, manufacturers should provide:
- The 524B(b)(1) plan (if not previously provided) or a reference to the prior submission with a summary of any changes.
- A description of whether there are any current “critical vulnerabilities that could cause uncontrolled risks” and if any such vulnerabilities were remediated since the last authorization.
- The 524B(b)(3) SBOM.
The FDA evaluates this information as part of its determination of a device’s safety and effectiveness, considering new risks, vulnerabilities, and how the device’s design addresses them.
Source: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions