Contains Nonbinding Recommendations 
 
 
 
 16 
the lifecycle of a device as part of configuration management.34 This may be accomplished 
through different methods, such as source code escrow or source code backups, among others.35  
 
Manufacturers may not have control of source code due to licensing restrictions, terms of 
supplier agreements, or other challenges. While source code is not required to be provided in 
premarket submissions, 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. The device manufacturer should also provide users with whatever 
information they may need in the device labeling to allow them to manage risks associated with 
the software components, including known vulnerabilities, configuration specifications, and 
other relevant security and risk management considerations.  
 
One tool to help manage supply chain risk as well as clearly identify and track the software 
incorporated into a device is an SBOM, as described below. 
(a) 
Software Bill of Materials (SBOM) 
An SBOM can aid in the management of cybersecurity risks that exist throughout the software 
stack. A robust SBOM includes both the device manufacturer-developed components and third-
party components, including purchased/licensed software and open-source software, and the 
upstream software dependencies that are required/depended upon by proprietary, 
purchased/licensed, and open-source software.  
 
An 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, both during development when software is being chosen as a component 
and after it has been placed into the market throughout all other phases of a product’s life.36  
 
Because vulnerability management is a critical part of a device’s security risk management 
processes, an SBOM or an equivalent capability should be maintained as part of the device’s 
configuration management, be regularly updated to reflect any changes to the software in 
marketed devices, and should support documentation, such as the types detailed in 21 CFR 
820.30(j) (Design History File) and 820.181 (Device Master Record). 
 
To assist FDA’s assessment of the device risks and associated impacts on safety and 
effectiveness related to cybersecurity, FDA recommends that premarket submissions include 
SBOM documentation as outlined below. For cyber devices, an SBOM is required (see section 
524B(b)(3) of the FD&C Act and Section VII.C.3 of this guidance). SBOMs can also be an 
 
34 While some suppliers may not grant access to source code, manufacturers may consider adding to their purchasing 
controls acquisition of the source code should the purchased software reach end of support or end of life from the 
supplier earlier than the intended end of support or end of life of the medical device. 
35 Source code escrow involves depositing a copy of a relevant piece of software’s source code (and related technical 
components and documentation) with an independent third party (“escrow agent”). Source code backup involves 
storing (and updating as needed) a separate copy of the source code. 
36 For additional information, see the Department of Commerce National Telecommunications and Information 
Administration’s multi-stakeholder process for software transparency available on the following website NTIA 
Software Component Transparency.  
