Apr 22, 2022

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:

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:

  1. Total product lifecycle (TPLC) approach.
  2. Premarket Information Supplied: The information that the FDA expects to have available for review in a premarket submission.
  3. 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

  • Where assets reside

 

Yes

  • Name

 

Yes

  • Version

 

Yes

  • Manufacturer

 

Yes

  • Level of monitoring / maintenance support from manufacturer

 

Yes

  • End-of-support date

 

Yes

  • Known vulnerabilities

 

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

  • Evaluation methods and processes

 

Yes

  • Risk assessment

Yes

Yes

  • Risk mitigation activities

Yes

Yes

  • Traceability between risks, controls, and testing

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

  • Global System View

 

Yes

  • Multi-Patient Harm View

 

Yes

  • Updateability / Patchability View

 

Yes

  • Security Use Case View

 

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

  • Robustness

 

Yes

  • Fuzz testing

 

Yes

  • Attack surface analysis

 

Yes

  • Vulnerability chaining

 

Yes

  • Closed box testing of known vulnerability scanning

 

Yes

  • Composition analysis of binary executable files

 

Yes

  • Static code analysis

 

Yes

  • Dynamic code analysis

 

Yes

  • Penetration testing

 

Yes

  • Assessment of findings

 

Yes

Plans to address known vulnerabilities.

Yes

Yes

Plans to communicate vulnerabilities including:

 

Yes

  • Personnel responsible

 

Yes

  • Sources, methods, and frequency of monitoring

 

Yes

  • Periodic security testing

 

Yes

  • Timeline to develop and release patches

 

Yes

  • Update processes

 

Yes

  • Patching capability

 

Yes

  • Vulnerability disclosure process

 

Yes

  • Communication plan of updates to customers

 

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

 

 

Author

  • Sarah Fitzgerald

Related