Preparing for the U.S Food and Drug Administration (FDA) premarket and 510(k) submissions

In June 2025, the US FDA concluded a review and iteration of its previous documents, guidelines, and recommendations, stating:

“...the rapidly evolving landscape, an increased understanding of emerging threats, and the need for capable deployment of mitigations throughout the total product lifecycle (TPLC) warrants an updated, iterative approach to device cybersecurity.”

Importantly, the newly published (June 2025) cybersecurity guidelines take a cohesive and comprehensive view of smart medical devices. Cybersecurity risks and safety considerations are not limited to solely the device itself, but all the contextual and environmental factors that could affect the device as well. Most importantly, the new guidelines aim to create an ongoing process or framework to manage risks and threats – known and unknown – throughout the product’s lifecycle.

The ultimate goal of cybersecurity, the US FDA, and other regulatory agencies is to manage cyber risk. The US FDA states that “risk management for device manufacturers is the essential systematic practice of identifying, analyzing, evaluating, controlling, and monitoring risk throughout the product lifecycle to ensure that the devices they manufacture are safe and effective.” Regardless of framework, approach, or strategy, OEMs and device manufacturers must demonstrate:

1. The systematic management of cyber risks
2. Throughout the product lifecycle
3. To ensure the safe and effective operation of the device.

Anything less will fail to satisfy the US FDA premarket requirements.

The US FDA mandates that a device “should be designed to eliminate or mitigate known vulnerabilities.” To this aim, the recommended SPDF encompasses processes to reduce the number and severity of vulnerabilities, with reasonably foreseeable weaknesses addressed in the device design. In leveraging the SPDF, the US FDA intends manufacturers to embrace and integrate a secure-by-design philosophy. A secure-by-design approach means that a device is designed to be secure from the beginning or by default, inherent within how the system itself was designed and how it interacts with its environment and/or network.

Notably, the US FDA notes that if security by design is not possible, then the manufacturer must take additional responsibility to establish compensatory controls and mechanisms to accommodate the lack of security in the product’s design.

Action: Premarket submissions should include information describing how the five security objectives are addressed and integrated into the device design. 

In addition to a secure product design, the US FDA requires manufacturers to understand and analyze their products' usage, environments, and any associated risks. At a high level, manufacturers are responsible for 1) identifying cybersecurity risks in their devices and the systems of operation and 2) implementing the appropriate controls to mitigate those risks.

To implement security controls, the FDA recommends that these procedures include design requirements and acceptance criteria for the security features built into the device, holistically addressing the cybersecurity considerations for the device and the system in which it operates.

Recommended security control categories:

• Authentication (of both information and entities)
• Authorization
• Cryptography
• Code, data, and execution integrity
• Confidentiality
• Event detection and logging
• Resiliency and recovery
• Updatability and patchability

As a result of this extensive contextual analysis, manufacturers are required to document the security architecture for their products. Within the security architecture, manufacturers should include the system-level risk considerations, such as:

• Supply chain risks: To ensure the device remains free of malware or vulnerabilities inherited from upstream dependencies such as third-party software, among other things.
• Design, production, and deployment risks: For example, to ensure security or authenticity when activated in a connected or networked environment.

The US FDA recommends that manufacturers develop and maintain security architecture view documentation as part of the design, development, and maintenance process for the medical device system. If corrective and preventive actions are identified, these views can help identify impacted functionality and solutions that address the risks. At a minimum, manufacturers should cover the following four types of views in their security architecture and include relevant documentation in their premarket submissions.

1. The global system view describes the overall medical device system, including the device itself and all internal and external connections.
2. The multi-patient harm view addresses how devices and systems defend against and/or respond to attacks that have the potential to harm multiple patients.
3. The updateability/patchability view describes the end-to-end process for providing (i.e., deploying) software updates and patches to the device and should include detailed information.
4. The security use case view(s) will scale in the number of views with the cybersecurity complexity and risk of the device. Each view should include detailed information and should be included for all medical device system functionality through which a security compromise could impact the safety or effectiveness of the device. The security use case views should cover various operational states of elements in the medical device system (e.g., power on, standby, transition states) and assess clinical functionality states of the medical device system (e.g., programming, alarming, delivering therapy, sending/receiving data, reporting diagnostic results).

For each of the security architecture views, manufacturers should analyze and include the following four sections of information:

• Identify security-relevant medical device system elements and their interfaces;
• Define security context, domains, boundaries, critical user roles, and external interfaces of the medical device system;
• Align the architecture with (a) the medical device system security objectives and requirements, (b) security design characteristics to address the identified threats; and
• Establish traceability of architecture elements to user and medical device system security requirements. Such traceability should exist throughout the cybersecurity risk management documentation.

Action: Premarket submissions should include, at a minimum, the four types of views in the security architecture, cover the four information sections for each.

The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. FDA recommends that these procedures include design requirements and acceptance criteria for the security features built into the device, holistically addressing the cybersecurity considerations for the device and the system in which it operates.

Security risk management plan

“To fully account for cybersecurity risks in medical device systems, the safety and security risks of each device should be assessed within the context of the larger system in which the device operates. In the context of cybersecurity, security risk management processes are critical because, given the evolving nature of cybersecurity threats and risks, no device is, or can be, completely secure. Security risk management should be an integrated part of a manufacturer’s entire quality system, addressed throughout the TPLC. The quality system processes entail the technical, personnel, and management practices, among others, that manufacturers use to manage potential risks to their devices and ensure that their devices are, and once on the market, remain, safe and effective, which includes security.”

The security risk management plan encompasses the ability “to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures.” There are six main areas of the security risk management plan.

Area 1: Threat modeling

Threat modeling is a process for identifying security objectives, risks, and vulnerabilities across the medical device system. Manufacturers must define countermeasures to prevent, mitigate, monitor, or respond to the effects of threats to the medical device system throughout its lifecycle.

There are three key areas of threat modeling for premarket submissions. Manufacturers should 1) identify risks and mitigations of the medical device system and inform the pre- and post-mitigation risks considered as part of the cybersecurity risk assessment; 2) state any assumptions about the medical device system or environment of use; and 3) capture cybersecurity risks introduced through the supply chain, manufacturing, deployment, interoperability with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment process.

Action: Premarket submissions should consider and include threat modeling analysis information (identifying device risks, assumptions, and external or usage risks) in the secure product design and security architecture view documentation.

Area 2: Cybersecurity risk assessment

Security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system, to capture the risks and controls identified from the threat model. The acceptance criteria for cybersecurity risks should carefully consider the TPLC of the medical device system, as it might be more challenging to mitigate cybersecurity issues for already marketed devices.

Action: Premarket submissions should consider and include the cyber risk assessment analysis in the secure product design and security architecture view documentation. Mitigation measures should be included for already marketed devices.

Area 3: Interoperability

Throughout the FDA documents, the device is only one part of the equation. To view and secure the device cohesively, manufacturers must analyze the device inherently and within its environment or usage parameters. As a device exists within a system, manufacturers should consider:

• Other medical devices and accessories,
• Other functions,
• Healthcare infrastructure, and
• General-purpose computing platforms.

Interactions among and between different systems, programs, or user access can impact and change each's risk profile.

 

Action: Premarket submissions should consider and include the appropriate cybersecurity risks and controls associated with the interoperability capabilities. Additional security architecture views (beyond the mandatory four) can be included to clearly reflect the interoperability analysis of the device.

Area 4: Third-party software components

Device manufacturers should document all software components of a device and address or otherwise mitigate risks associated with these software components. All software, including software developed by the device manufacturer (“proprietary software”) or obtained from third parties, should be assessed for cybersecurity risk to demonstrate compliance with design controls and to support supply chain risk management processes. 

For third-party software, manufacturers must put in place processes and controls to ensure that their suppliers conform to the manufacturer’s requirements. In essence, it is the manufacturers’ responsibility to ensure US FDA compliance for the components, including third-party, chosen to include in the device.

To account for software changes and risks over time, device manufacturers should establish and maintain custodial control of device source code (the original “copy” of the software) throughout the lifecycle of a device as part of configuration management. Additionally, manufacturers should include plans for how third-party software components could be updated or replaced if support ends or other software issues arise in premarket submissions.

Action: Premarket submissions should include documentation on how a manufacturer 1) retains custodial control and support of a device at the source level, 2) plans to maintain the device through alternative components should parts no longer be available or compliance, and 3) ensures the compliance of all third-party components used within the device.

The software bill of materials

A software bill of materials (SBOM) helps facilitate risk management processes by providing a mechanism to identify devices and the systems in which they operate that might be affected by vulnerabilities in the software components. An SBOM or an equivalent capability should be maintained as part of the device’s configuration management, regularly updated to reflect any changes to the software in marketed devices, and support documentation.

Action: Premarket submissions should include a software bill of materials (SBOM) and documentation detailing the process to keep the SBOM up to date and supported. 

Area 5: Security Assessment of Unresolved Anomalies

The US FDA allows for anomalies to exist for and within submitted devices. However, manufacturers must provide detailed documentation, including an evaluation and analysis of each unresolved anomaly and its safety, effectiveness, and security implications.

Action: Premarket submissions should include 1) a list of software anomalies that exist in a product at the time of submission with 2) the criteria and rationales for addressing the resulting anomalies with security impacts.

Area 6: TPLC Security Risk Management

Cybersecurity risks may continue to be identified throughout the device’s total product lifecycle (TPLC). Manufacturers should ensure they have appropriate resources to identify, assess, and mitigate cybersecurity vulnerabilities as they are identified throughout the supported device lifecycle. Over the lifecycle of the device, manufacturers should update the risk management documentation to reflect new or changes information as appropriate.

To demonstrate the effectiveness of a manufacturer’s risk management, at a minimum, the FDA recommends tracking the following metrics:

• The defect density: The percentage of identified vulnerabilities that are updated or patched
• The resolution delay: The duration from vulnerability identification to when it is updated or patched
• The management delay: The duration from when an update or patch is available to complete implementation in devices deployed in the field, to the extent known.

Action: Premarket submissions should include the risk management effectiveness metrics when available.

The US FDA recommends that the premarket submission include security testing documentation and any associated reports or assessments. Among other things, the US FDA recommends considering the following types of testing to include in the premarket submission.

• Security requirements: Evidence that each design input requirement was implemented successfully, as well as evidence of their boundary analysis and rationale for their boundary assumptions.
• Threat mitigation: Details and evidence of testing demonstrating effective risk control measures according to the threat models provided in the global system, multi-patient harm, updatability and patchability, and security use case views.
• Vulnerability Testing: Details and evidence of the following testing and analyses:
  • Abuse or misuse cases, malformed and unexpected inputs;
  • Robustness.
  • Fuzz testing.
  • Attack surface analysis;
  • Vulnerability chaining;
  • Closed box testing of known vulnerability scanning;
  • Software composition analysis of binary executable files; and
  • Static and dynamic code analysis, including testing for hardcoded, default, easily guessed, and compromised credentials.
• Penetration testing: Identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product. Premarket submissions should include penetration test reports and cover the following elements:
  • Independence and technical expertise of testers,
  • Scope of testing,
  • Duration of testing,
  • Testing methods employed, and
  • Test results, findings, and observations.