US FDA’s latest medical device cybersecurity guidance: Key differences from previous versions
On April 8, 2022, the US Food and Drug Administration published a new draft guidance, […]
On April 8, 2022, the US Food and Drug Administration published a new draft guidance, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” replacing the 2018 draft guidance “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.” It is important to note that this guidance does not replace the following guidance documents at this time:
- Postmarket Management of Cybersecurity in Medical Devices, 2016
- Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, 2014
- Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software, 2005
The intent is that when this draft guidance is finalized, it will replace the 2014 cybersecurity guidance. Comments are due to the FDA by July 7, 2022, and every manufacturer who has or is developing devices that contain or are software, firmware, and/or programmable logic should review this guidance in detail and consider if they have concerns that they wish to bring to the FDA’s attention. This is intended to be an overview only, and does not address all details.
The new draft cybersecurity guidance covers both quality system considerations and the content of premarket submissions (such as 510(k), de novo and premarket approval (PMA) applications), whereas both the 2014 and the 2018 versions of the guidance focused primarily upon the content of premarket submissions. This is intended to emphasize the importance of designing devices security and in a manner that cybersecurity risks can be mitigated throughout the total product lifecycle (TPLC), with a recommendation of using a secure product development framework (SPDF). The new guidance generally aligns with the International Medical Device Regulators Forum (IMDRF) 2020 guidance “Principles and Practices for Medical Device Cybersecurity.”
As with past guidance, but with further clarifications, the 2022 guidance covers software and firmware or programmable logic, including software as a medical device (SaMD), regardless of whether it is connected to a broader environment. From a high-level standpoint, the objective remains the same: to ensure that the device is, and remains, safe and effective for its intended use. This includes that many of the high-level objectives remain the same, including authenticity, integrity, availability, confidentiality, updatability, cryptography, appropriate authorization, event detection, event logging, and recovery.
How does the FDA’s 2022 cybersecurity guidance differ from previous versions?
However, there are many differences between the guidance documents as well, some of which are clarifications and some of which are changes. For simplicity, we are comparing to the currently in force 2014 guidance, as the 2018 guidance was never finalized. Most clarifications and changes fall into one or more of three broad categories:
- Total product lifecycle (TPLC) approach.
- Premarket Information Supplied: The information that the FDA expects to have available for review in a premarket submission.
- Information Transparency: The information that the FDA expects to be available to customers (labeling).
We will take a look at some of the clarifications and changes. Please note that this document is not intended to provide complete information needed to address cybersecurity, but is focused on differences.
Total Product Lifecycle (TPLC) Approach Clarifications and Changes Overview
Although TPLC is mentioned in the 2014 guidance, the detailed expectations were not clear. In the new draft, the FDA provides clarification on several topics, as well as introducing new expectations.
- The FDA clarifies that threat modeling should be used to identify security objectives, risks, vulnerabilities and countermeasures. Threat modeling should consider risks from the supply chain (including off-the-shelf software), manufacturing, deployment, interoperation, maintenance/update activities and decommissioning activities.
- Manufacturers must document all software components of a device, which may be done through a software bill of materials (SBOM). As part of configuration management, device manufacturers should have custodial control of source code through source code escrow and source code backups. If this control is not available, a plan of how the third-party software component could be updated or replaced must be established.
- Cybersecurity should continue to be considered throughout the TPLC of the device, with updates made to relevant documentation as appropriate. This should include tracking the percentage of identified vulnerabilities updated/patched (defect density); time from vulnerability identification to when it was updated/patched; time from when an update/patch is available to complete implementation in devices in the field; and averages of these measures.
- After release, cybersecurity testing should be performed at regular intervals (annually) to ensure that potential vulnerabilities are identified prior to being exploited. No mention is made as to whether such testing could justified as being partial, suggesting that the FDA expects full cybersecurity-related testing to be conducted annually.
Premarket Information Supplied Clarifications and Changes Overview
The FDA considers cybersecurity to potentially have an effect on the safety and/or effectiveness of a device, and has required information be provided in a premarket submission in order to evaluate the device, as described in the 2014 final guidance. However, the 2022 draft guidance significantly increases the amount of information that must be provided for FDA review. Table 1 provides an overview of the information that the FDA expects to be included in premarket submission according to the 2014 and the new 2022 guidance documents.
Table 1: Premarket Submission Cybersecurity Contents Expectations
| Content | 2014 Final Guidance | 2022 Draft Guidance |
|---|---|---|
| Threat modeling | Yes | |
| Software bill of materials (SBOM) including the following information per software component, in a machine readable format: | Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
| If manufacturer does not have custodial control of third-party source code, a plan of how the third-party software component could be updated or replaced. | ||
| Safety risk assessment for each known vulnerability. | Yes | |
| Security risk assessment for each known vulnerability. | Yes | |
| Risk controls to address known vulnerabilities . | Yes | |
| List of software anomalies or statement that there are none. | Yes | |
| Assessment of anomaly impact on safety and effectiveness. | Yes | |
| Assessment of anomaly impact on security using a common weakness enumeration (CWE) categorization (such as by AAMI SW91). | Yes | |
| Security risk management plan. | Yes | |
| Security risk management report including: | Yes | |
|
Yes | |
|
Yes | Yes |
|
Yes | Yes |
|
Yes | Yes |
| % identified vulnerabilities updated / patched (defect density). | Yes | |
| Time from vulnerability detection to update / patch. | Yes | |
| Time from update / patch availability to complete implementation for devices in field. | Yes | |
| Security Architecture including: | Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
| Controls for software to maintain integrity from origin to leaving control of manufacturer. | Yes | Yes |
| All security controls implemented. | Yes | |
| All security control validation. | Yes | |
| Testing showing each design input implemented. | Yes | |
| Boundary analysis and rationale for boundary assumptions. | Yes | |
| Testing showing risk control measures for threat models. | Yes | |
| Adequacy of risk controls for threat mitigation. | Yes | |
| Vulnerability testing including: | Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
| Plans to address known vulnerabilities. | Yes | Yes |
| Plans to communicate vulnerabilities including: | Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes | |
|
Yes |
Information Transparency Clarifications and Changes Overview
The FDA considers it important to provide a user with adequate labeling to appropriately use a medical device and communicate risks. The FDA has required certain labeling be present, as described in the 2014 final guidance. However, the 2022 draft guidance significantly increases the amount of information that must be provided to the user. As draft labeling is provided to the FDA during a premarket submission, the FDA will review this. Table 2 provides an overview of the information that the FDA specifically expects to be included in premarket submission according to the 2014 and the new 2022 guidance documents.
Table 2: Cybersecurity Labeling Expectations
| Content | 2014 Final Guidance | 2022 Draft Guidance |
|---|---|---|
| Recommended cybersecurity controls, such as anti-malware, firewall use, and password requirements. | Yes | Yes |
| Diagrams that allow cybersecurity controls to be implemented. | Yes | |
| List of ports and interfaces expected to receive and/or send data, along with approved destination endpoints. | Yes | |
| Infrastructure requirements, such as minimum networking requirements and supported encryption interfaces. | Yes | |
| A machine-readable SBOM, available on a continuous basis such as an online portal. | Yes | |
| Yes | ||
| Procedures for users to download software, including how users will know when software updates are available. | Yes | |
| Threats that the device may be exposed to, and how those threats may be prevented or mitigated. | Yes | |
| How the device responds when anomalous conditions are detected, including user notification and information logging. | Yes | |
| High-level description of device features that protect critical functionality, such as backup mode, disabling communications, etc. | Yes | |
| Description of backup and restore features. | Yes | |
| Method for retention and recovery of device configuration. | Yes | |
| Description of secure configuration of shipped devices. | Yes | |
| Risk trade-offs that might be made regarding hardening options, and instructions for user-configurable changes. | Yes | |
| Where appropriate, how forensic evidence is captured, including where log files are located, stored, recycled, archived, and consumed by automated analysis software. | Yes | |
| Where appropriate, technical instructions to permit secure network deployment and servicing. | Yes | |
| Instructions on how to respond upon detection of a cybersecurity vulnerability or incident. | Yes | |
| Information about device cybersecurity end of support or end of life, including that risk is likely to increase. | Yes | |
| The manufacturer’s process for communicating end of support or end of life. | Yes | |
| Information on securely decommissioning devices by sanitizing the product of sensitive, confidential, and proprietary data and software. | Yes |
Other Clarifications and Changes Overview
The FDA clarifies that security risk management is distinct from safety risk management (ISO 14971), as it focuses on exploitability. Risk controls from each assessment should be assessed to ensure that they do not inadvertently introduce or change risks to the other, in alignment with AAMI TIR57.
Manufacturers must document all software components of a device, which may be done through a software bill of materials (SBOM). As part of configuration management, device manufacturers should have custodial control of source code through source code escrow and source code backups. If this control is not available, a plan of how the third-party software component could be updated or replaced must be established.
Uncertainties regarding the latest FDA medical device cybersecurity guidance
Both the 2014 and the new medical device cybersecurity draft guidance documents indicate that the extent of the requirements necessary for a specific device depends on several factors. The new draft guidance mentions several, including the device’s intended use, interfaces, intended connections, environment of use and risk of patient harm from cybersecurity vulnerability exploitation.
However, like the 2014 guidance, this guidance does not provide clear recommendations on how to evaluate the extent of requirements necessary for different devices, meaning that a manufacturer is going to have to justify what they consider necessary on an individual device basis.
Further, as the FDA wishes to review more information in the appropriate premarket submission, additional justification will be expected from applicants in premarket submissions. This, of course, means that there are more areas that the FDA may or may not agree with, which could increase the premarket submission review time or the use of the agency’s Q-submission process in an attempt to gain alignment prior to the premarket submission. This could increase burdens, therefore, for both industry and the FDA.
Sarah Fitzgerald, RAC is Senior Consultant, Quality and Regulatory Affairs at Emergo by UL.
Related US FDA medical device regulatory resources from Emergo by UL:
- US FDA 510(k) consulting for medical device and IVD manufacturers
- Medical device design, process and software validation support
- Regulatory consulting for telehealth and mobile medical app developers
Original Article: (https://www.emergobyul.com/blog/2022/04/us-fdas-latest-medical-device-cybersecurity-guidance-key-differences-previous-versions)
