Regulation Learning Center

An SPDF is a set of processes that help reduce the number and severity of vulnerabilities in products. It encompasses all aspects of a product’s lifecycle, including development, release, support, and decommission. It can be integrated with existing processes for product and software development, risk management, and the quality system at large.

Using an SPDF is one approach to help ensure that the QS regulation is met.

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. FDA recommends that security risk management processes, as detailed in the QS regulation, be established or incorporated into those that already exist, and should address the manufacturer’s design, manufacturing, and distribution processes, as well as updates across the TPLC.
FDA recommends that device manufacturers conduct both a safety risk assessment and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety risks.

A process for identifying security objectives, risks, and vulnerabilities across the system, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system throughout its lifecycle.

FDA recommends that premarket submissions include threat modeling documentation to demonstrate how the medical device system has been analyzed to identify potential security risks that could impact safety and effectiveness.

As a part of security risk management, security risks and controls should be assessed for residual risks as part of a cybersecurity risk assessment. Effective security risk assessments address the fact that cybersecurity-related failures can occur either intentionally or unintentionally.
FDA recommends that manufacturers assess identified risks according to the level of risk posed from the device and the system in which it operates.

As part of a medical device system, a device may have cybersecurity considerations from interoperable functionality, including but not limited to interfaces with:

• Other medical devices and accessories;
  
  
• ‘Other functions’ as identified in the FDA’s guidance “Multiple Function Device Products: Policy and Considerations;”
  
  
• Interoperability with healthcare infrastructure (e.g., network, Electronic Medical Records, medical imaging systems); and
  
  
• General purpose computing platform

All software, including that developed by the manufacturer (“proprietary software”) and from 3rd parties should be assessed for cybersecurity risk and that risk should be addressed or otherwise mitigate risks associated with these software components.
Manufacturers must put in place processes and controls to ensure that their suppliers conform to the manufacturer’s requirements

Submit a software bill of materials, including commercial, open-source, and off-the-shelf software components, including:

1. The asset(s) where the software component resides;
2. The software component name;
3. The software component version;
4. The software component manufacturer;
5. The software level of support provided through monitoring and maintenance from the software component manufacturer;
6. The software component’s end-of-support date; and
7. Any known vulnerabilities

Manufacturers must identify, assess, and mitigate cybersecurity vulnerabilities as they are identified throughout the supported device lifecycle.
Manufacturers should update their security risk management documentation as new information becomes available, such as when new threats, vulnerabilities, assets, or adverse impacts are discovered during development and after the device is released.
The security risk management report should:

• summarize the risk evaluation methods and processes, detail the security risk assessment, and detail the risk mitigation activities
  
  
• provide traceability between the security risks, controls and the testing reports.

Cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectivenessSecurity testing documentation and any associated reports or assessments should be submitted in the premarket submission.

A system that appropriately accounts for authenticity will evaluate and ensure authenticity for:

1. information at rest (stored);
   
   
2. information in transit (transmitted);
   
   
3. entity authentication of communication endpoints, whether those endpoints consist of software or hardware;
   
   
4. software binaries;
   
   
5. integrity of the execution state of currently running software; and
   
   
6. any other appropriate parts of the system where a manufacturer’s threat model and/or risk analyses reveal the need for it

1. Authenticate firmware and software. Verify authentication tags (e.g., signatures, message authentication codes (MACs)) of software/firmware content, version numbers, and other metadata. The version numbers intended to be installed should themselves be signed or have MACs. Devices should be electronically and visibly identifiable (e.g., Unique device identifier (UDI), model number, serial number)
   
   
2. Allow installation of cryptographically authenticated firmware and software updates, and do not allow installation where such cryptographic authentication either is absent or fails.
   
   
3. Ensure that the authenticity of software, firmware, and configuration are validated prior to execution e.g., “allow-listing” based on digital signatures;
   
   
4. Disable or otherwise restrict unauthorized access to all test and debug ports (e.g., JTAG, UART) prior to delivering products
   
   
5. Employ tamper evident seals on device enclosures and their sensitive communication ports to help verify physical integrity
   
   
6. Hardware-based security solutions should be considered and employed when possible

1. Verify the integrity of all incoming data, ensuring that it is not modified in transit or at rest.
   
   
2. Validate that all data originating from external sources is well-formed and compliant with the expected protocol or specification.
   
   
3. Protect the integrity of data necessary to ensure the safety and effectiveness of the device

1. Use industry-accepted best practices to maintain and verify integrity of code while it is being executed on the device.
   
   
2. Carefully design and review all code that handles the parsing of external data using automated (e.g., static and dynamic analyses) and manual (i.e., code review) methods.