Summary of FDA Cybersecurity Guidance for Medical Devices

If you’re developing a medical device under the current medical device landscape, chances are it includes a software element, is potentially connected to a mobile device, and is generating, storing, or transferring personal health data. All of these elements introduce new threats to patient safety that didn’t exist in traditional, hardware-only medical devices. As a result, the FDA has increased their oversight efforts on cybersecurity related to medical devices. Not only should a device be effective and protect a patient from physical harm, it should also protect them from digital attacks that can compromise their data or health.

The FDA has outlined their take on how to integrate cybersecurity principles in their September 2023 Cybersecurity guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions [1]. A summary of those principles and FDA’s expectations on how to address them in premarket submissions are outlined below.

‍

Cybersecurity is part of device safety and the Quality System Regulations

Quality System Regulation (QSR) in 21 CFR Part 820 requires that manufacturers must establish and follow a quality system to ensure that their products consistently meet applicable requirements and specifications. In terms of software, this means that manufacturers should complete software risk analysis and validation activities, while considering cybersecurity risks related to the software. The FDA expects manufacturers to implement development processes that account for and address these cybersecurity risks as part of QSR requirements.

One recommended approach to ensure that QSR requirements are met is by implementing a Secure Product Development Framework (SPDF). This concept, which encompasses all aspects of a product’s lifecycle, utilizes a set of processes that reduce the number and severity of vulnerabilities for the product. It follows the practice outlined in NIST’s Secure Software Development Framework [2]. The FDA stresses the benefits of implementing a SPDF throughout the guidance.

‍

Designing for Security

The FDA makes it clear that security should be built into the device design. This means that all features of a device’s software architecture should meet security objectives such as authenticity, authorization, availability, confidentiality, and secure and timely updatability & patchability.

Implementing a SPDF is further encouraged here because this model addresses security elements throughout the design and development of the device. This helps a product to meet security objectives as required in premarket submissions and sets it up for a successful submission.

‍

Transparency

The guidance stresses the importance of users having access to information regarding cybersecurity, including potential risks and appropriate controls. To encourage transparency and to communicate relevant security information, the FDA expects an additional amount of information be made available to users as part of the device labeling. The guidance goes into detail about the following information expected to be provided to users:

‍

Device instructions and specifications related to recommended cybersecurity controls appropriate for the intended use environment (anti-malware software, use of a firewall, password requirements, how to configure or update the device, etc.)
Detailed diagrams that allow recommended cybersecurity controls to be implemented.
A list of network ports and other interfaces that are expected to receive and/or send data, including a description of port functionality and whether the ports are incoming/outgoing/both, along with destination end-points.
Specific guidance to users regarding supporting infrastructure requirements so that the device can operate as intended. Where appropriate, this guidance should include technical instructions to permit secure network deployment and servicing, and instructions for users on how to respond upon detection of a cybersecurity vulnerability or incident.
An SBOM in machine readable format including all of the information previously described above. This should be made available to users on a continuous up-to-date basis.
Description of systematic procedures for users to download version-identifiable manufacturer-authorized software and firmware, include a description of how users will know when a software update is available.
Description of how the device design enables the device to respond to security events in order to maintain safety and effectiveness.
A high-level description of device features that protect critical functionality.
A description of backup and restore features and procedures to restore authenticated configurations.
A description of the methods for retention and recovery of device configuration by an authenticated authorized user.
A description of the secure configuration of shipped devices, a discussion of the risk tradeoffs that might have been made about hardening options implemented by the device manufacturer, and instructions for user-configurable changes.
Where appropriate, a description of how forensic evidence is captured.
Information regarding device cybersecurity end of support and end of life.
Information on securely decommissioning devices by sanitizing the product of sensitive, confidential, and proprietary data and software.

‍

Submission Documentation

The cybersecurity related documentation that the FDA expects for a submission is expected to scale depending on the cybersecurity risk of the device. The guidance follows the logic that a device with small cybersecurity risk will have less information that will need to be submitted to the FDA than a device with a greater cybersecurity risk. Either way, there is a lot of additional documentation that the FDA expects to see in order to enable a proper evaluation of device cybersecurity. Some of the key expectations are summarized below.

‍

Threat modeling

A process for identifying security objectives, risks, and vulnerabilities across the system, and then defining countermeasures to prevent or mitigate the effects of these threats to the system. An excellent resource for understanding and applying threat modeling principles can be found in MITRE’s Playbook For Threat Modeling Medical Devices [3]. The playbook emphasizes four very basic questions that form the basis behind performing threat modeling:

1. What are we building?

2. What can go wrong? (e.g. how could it be attacked)

3. What are we going to do about that?

4. Did we do a good enough job?

‍

Third-Party Software Components

Manufacturers are expected to document all third-party software components of a device and mitigate risks associated with these components. This can be documented through a Software Bill of Materials (SBOM). An SBOM is an “ingredient list” that includes every component that forms part of a device’s software. It allows manufacturers to assess and manage vulnerabilities that may be introduced through third party software components. At a minimum, the following information should be included for each software component:

The asset(s) where the component resides
The software component name
The software component version
The software component manufacturer
The software level of support provided through monitoring and maintenance from the software component manufacturer
The software component’s end-of-support date
Any known vulnerabilities

Security Assessment of Unresolved Anomalies

A list of known software bugs or defects should be provided to the FDA at the time of submission. For each of these known anomalies, manufacturers should conduct an assessment of its impact on device safety and effectiveness.

‍

Security Risk Management Documentation

Outputs of the security risk management process should be included as part of the premarket submission. This includes a security risk management plan and report. Note that performing security risk management activities is different from the safety risk management process described in ISO 14971:2019 [4]. Manufacturers are encouraged to refer to AAMI TIR57 [5] and the FDA’s Postmarket Cybersecurity Guidance [6] for performing risk management activities related to cybersecurity.

‍

Manufacturers should also consider that security risk management should be an ongoing process throughout the lifecycle of the device. The guidance highlights the importance of this being an ongoing activity as part of a device’s total process lifecycle (TPLC).

‍

Security Architecture Documentation

The FDA recommends that premarket submissions include documentation describing the security architecture of a device. The security architecture should define and illustrate all end-to-end connections into and/or out of the device. It should include information about interactions of external system(s) that interact with the device and detailed information for how those interactions occur and how they are secured.

‍

The amount of detail that is necessary for illustrating system architecture will vary between devices, depending on device complexity and cybersecurity risk. The guidance recommends that, at a minimum, the architecture be depicted with the following views: Global System View; Multi-Patient Harm View; Updatability/Patchability View; and Security Use Case View.

‍

The objective is to provide the FDA with enough security context and detail of device interfaces, interconnections, and interactions with external entities such that the FDA can properly evaluate the architecture as it relates to device safety and effectiveness.

‍

Cybersecurity Management Plans

FDA recommends that manufacturers establish a plan for how they will identify and communicate to users vulnerabilities that are identified after releasing the device. For cyber devices, “a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures” is required. Below are a few items that should be included in your premarket submission:

Sources, methods, and frequency for monitoring and identifying vulnerabilities
Identify and address vulnerabilities identified in CISA Known Exploited Vulnerabilities Catalog. Note that FDA has recognized ISO/IEC 30111:2013: Information Technology – Security Techniques – Vulnerability Handling Processes
Periodic security testing
Timeline to develop and release patches
Update processes
Patching capability (i.e., rate at which update can be delivered to devices)

Additionally, a vulnerability disclosure should be included (and made accessible to users). The FDA has recognized ISO/IEC 29147:2014: Information Technology – Security Techniques – Vulnerability Disclosure which may be a useful resource for manufacturers; and · Deploying mitigations that address cybersecurity risk early and prior to exploitation.

‍

Labeling

The FDA expects that relevant security information be communicated to users. Such information could include the following:

Device instructions and product specifications related to recommended cybersecurity controls appropriate for the intended use environment (e.g. anti-malware software, use of a firewall, password requirements).
Sufficiently detailed diagrams for users that allow recommended cybersecurity controls to be implemented.
A list of network ports and other interfaces that are expected to receive and/or send data. This list should include a description of port functionality and indicate whether the ports are incoming, outgoing, or both, along with approved destination end-points.
Specific guidance to users regarding supporting infrastructure requirements so that the device can operate as intended (e.g. minimum networking requirements, supported encryption interfaces). Where appropriate, such guidance should include technical instructions to permit secure network deployment and servicing, and instructions for users on how to respond upon detection of a cybersecurity vulnerability or incident.
A description of systematic procedures for users to download version-identifiable manufacturer-authorized software and firmware, including a description of how users will know when software is available.
A description of how the design enables the device to respond when anomalous conditions are detected (i.e. security events). This should include notification to the user and logging of relevant information. Security event types could be configuration changes, network anomalies, login attempts, or anomalous traffic (e.g., send requests to unknown entities).

See the Cybersecurity guidance Section VI.A for more information about what else might need to be included in your labeling.

‍

Cybersecurity Testing

Finally, the FDA expects a certain level of cybersecurity testing to be conducted in order to verify that the cybersecurity controls put in place are effective. The guidance notes that standard software verification and validation activities alone are not sufficient to demonstrate the effectiveness of cybersecurity controls. It calls out the following types of testing as a recommendation for what should be performed and included as part of a premarket submission:

Security requirements testingsome text
- Provide evidence that each design input requirement was implemented successfully; and
- Provide evidence of their boundary analysis and rationale for boundary assumptions.
Threat mitigation testingsome text
- Provide details and evidence of testing that demonstrates effective risk control measures according to the threat models provided in the system, use case, and call-flow views; and
- Ensure the adequacy of each cybersecurity risk control.
Vulnerability testing (refer to Section 9.4 of ANSI/ISA 62443-4-1 [7])some text
- Provide detail and evidence of the following testing pertaining to known vulnerabilities:some text
  - Abuse case, 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.
Penetration testingsome text
- Identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product. These test reports should include the following elements: some text
  - Independence and technical expertise of testers,
  - Scope of testing,
  - Duration of testing,
  - Testing methods employed; and
  - Test results, findings, & observations.

‍

It is good practice that cybersecurity testing be performed by parties independent from those who developed the device. Therefore, an independent third party entity may be necessary to properly execute testing. Any original third party test reports should be included in the submission as well as the manufacturers final assessment on test findings.

‍

Conclusion

Cybersecurity is a continuously evolving topic that is top of mind for the FDA. Security events can and do pose real threats to patients. Establishing regulation related to securing a device is a logical move. With this guidance document, the FDA addresses cybersecurity expectations in premarket submissions to enable the agency to evaluate the safety and effectiveness of a device in terms of cybersecurity. It is also clear from the guidance that this is no simple feat. The amount of documentation and testing required per this guidance will introduce a new level of burden for medical device manufacturers. It poses a concern within the industry of whether or not most medical device manufacturers will be willing or able to absorb this burden.

‍