Contains Nonbinding Recommendations 
 
 
 
 15 
allow for the safe and effective exchange and use of information. Additionally, cybersecurity 
controls should not be intended to prohibit a user from accessing their device data.  
 
When common technology and communication protocols are used to enable interoperability 
(e.g., Bluetooth, Bluetooth Low Energy, network protocols), device manufacturers should assess 
whether added security controls beneath such communication are needed to ensure the safety and 
effectiveness of the device (e.g., added security controls beneath Bluetooth Low Energy to 
protect against risks if vulnerabilities in the Bluetooth Low Energy protocol or supporting 
technology are discovered). 
 
In addition to the recommendations in the Interoperability Guidance, manufacturers should 
consider the appropriate cybersecurity risks and controls associated with the interoperability 
capabilities and document these considerations as recommended throughout this guidance.  
4. 
Third-Party Software Components 
As discussed in FDA’s guidance “Off-The-Shelf (OTS) Software Use in Medical Devices,” 
medical devices commonly include third-party software components,33 including off-the-shelf 
and open source software. When these components are incorporated, security risks of the 
software components should become factors of the overall medical device system risk 
management processes and documentation.  
 
As part of demonstrating compliance with design controls under 21 CFR 820.30(g), and to 
support supply chain risk management processes, all software, including those developed by the 
device manufacturer (“proprietary software”) or obtained from third parties, should be assessed 
for cybersecurity risk. Device manufacturers should document all software components of a 
device and address or otherwise mitigate risks associated with these software components.  
 
In addition, under 21 CFR 820.50, a manufacturer must put in place processes and controls to 
ensure that its suppliers conform to the manufacturer’s requirements. Such information is 
documented in the Design History File, required by 21 CFR 820.30(j), and Device Master 
Record, required by 21 CFR 820.181. This documentation demonstrates the device’s overall 
compliance with the QS regulation, as well as that the third-party components meet 
specifications established for the device. Security risk assessments that include analyses and 
considerations of cybersecurity risks that may exist in or be introduced by third-party software 
and the software supply chain may help demonstrate that manufacturers have adequately ensured 
such compliance and documented such history.  
 
Software is updated over time to provide additional features, address security concerns, and 
otherwise be maintained. These changes may introduce new considerations or risks that must be 
accounted for as part of risk management. As a result, device manufacturers should establish and 
maintain custodial control of device source code (the original “copy” of the software) throughout 
 
33 The use of “component” in this guidance is consistent with the definition in 21 CFR 820.3. 
