Cybersecurity

Breaking news! The FDA just released new guidance on the refusal to accept (RTA) policy for cybersecurity devices.

Where can I find the new cybersecurity devices guidance?

The new guidance is titled “Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act,” and you can download a copy of the PDF directly from our website. This is the first time the FDA has created a definition for a “cyber device,” but this guidance is specific to the refusal to accept policy (RTA) rather than guidance for the format and content of pre-market notification (i.e., 510k) If you want to learn about new guidance documents as they are released, we recommend that you sign up for FDA email notifications. If you want to be notified of when our new blogs are posted, subscribe to our blog email notification list on this page.

What is a “cyber device” in the context of this cybersecurity devices guidance and submissions?

This new guidance defines “cyber device” using the following language:

1. includes software validated, installed, or authorized by the sponsor as a device or in a device;
2. has the ability to connect to the internet; and
3. contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

What does “refusal to accept” (RTA) mean?

“Refusal to accept” or (RTA) is a policy that the FDA implemented for pre-market notification submissions (i.e., 510k) in 2012. The process occurs during the first 15 calendar days of the FDA review process. The FDA assigns a preliminary reviewer to perform the RTA screening of the submission, and the person completes an RTA checklist. The FDA substitutes an RTA screening with a technical screening for FDA eSTAR templates, and this is one of the reasons why Medical Device Academy uses the FDA eSTAR templates for all 510k submissions and De Novo classification requests instead of using the older 510k format and content requirements with 20 sections.

When will the FDA begin rejecting submissions during the RTA processes?

The FDA states directly in the guidance document that they will not reject submissions for cybersecurity for the balance of FY 2023 (i.e., before October 1, 2023). The wording used by the FDA is: “The FDA generally intends not to issue “refuse to accept” (RTA) decisions for premarket submissions for cyber devices that are submitted before October 1, 2023, based solely on information required by section 524B of the FD&C Act. Instead, the FDA will work collaboratively with sponsors of such premarket submissions as part of the interactive and/or deficiency review process.” We believe the FDA will update the eSTAR template to include requirements for cybersecurity on October 1, 2023. It will not be possible to submit a 510k that does not include the cybersecurity requirements in future eSTAR templates, because the eSTAR automatically verifies the completion of each section in the template.

Will there be another cybersecurity guidance released soon?

The FDA announced last October that a new cybersecurity guidance would be replacing the 2014 final guidance for cybersecurity. A draft was released in 2018, and an updated draft was released in 2022. The final updated guidance is included in the A-list of FDA priorities for final guidance documents, but the updated final version has not been released yet. The FDA webpage for cybersecurity was updated to include this new guidance on RTA policy for cybersecurity devices. We believe this indicates that the updated final version will be released soon. When it is released, we will publish a new blog about that guidance.

The new US FDA draft cybersecurity guidance requires you to test cybersecurity, but when should you conduct software security testing?

On April 8, 2022, the FDA released a new draft cybersecurity guidance document to replace the 2018 draft that the industry does not support.

Why was the draft cybersecurity guidance created?

Due to the ubiquitous nature of software and networked devices in the medical industry, the impact of cybersecurity attacks is becoming more frequent and more severe. The WannaCry Ransomeware Attack is just one example of this global cybersecurity issue. The FDA is responding to the need for stronger cybersecurity controls by issuing a new draft cybersecurity guidance for 2022.

The first four paragraphs of the introduction explain why we need this, and WannaCry is mentioned in the second paragraph of the background section. This new guidance is only a draft, but this is the FDA’s third attempt at regulating the cybersecurity of medical devices. The first guidance was finalized in 2014. That’s the 9-page guidance we currently have in effect. The guidance mentions risk 11 times and there is no mention of testing requirements or a bill of materials (BOM). The 2018 draft guidance (24-pages) met with resistance from the industry for a lot of reasons. One of the reasons mentioned by Suzanne Schwartz in an interview is the inclusion of a cybersecurity bill of materials (CBOM). The industry felt it would be too burdensome to disclose all of the hardware elements that are related to cybersecurity. Therefore, the FDA rewrote the 2018 draft and released a new draft on April 8, 2022 (49-pages).

You might have expected the FDA to soften its requirements in the face of resistance from industry, but the new draft does not appear to be less robust. It is true that the CBOM was replaced by a software bill of materials (SBOM). However, the SBOM must be electronically readable and it must include:

• the asset(s) where the software 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; and
• any known vulnerabilities.

You can be sure that the medical device industry will view providing an SBOM as a hefty burden. After all, a machine-readable SBOM is more complex than UDI labeling requirements. An SBOM will not fit on the “Splash Screen” for anyone’s software application. Companies may provide documentation through the company website with a link in their software to that information. The format of the information could be in the “Manufacturer Disclosure Statement for Medical Device Security (MDS2).” However, MDS2 is a 349-line item Excel spreadsheet to be used as a checklist (i.e. quite a bit longer than the GUDID data elements spreadsheet), and it took the FDA eight years to complete the transition for the UDI Final Rule (i.e. 2013 – 2021).

The 2018 draft cybersecurity guidance document from the FDA required a cybersecurity bill of materials (CBOM). CBOM was defined as “a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.” Therefore, the FDA’s change from a CBOM to an SBOM eliminated the requirement to disclose the hardware components. Despite the change in disclosure requirements, manufacturers will still be expected to monitor potential hardware vulnerabilities to cybersecurity attacks. It should also be noted that the language in the PATCH Act (a new bill submitted to the House of Representatives and to the Senate for ensuring the cybersecurity of medical devices) specifically requires manufacturers “to furnish a software bill of materials as required under section 524B (relating to ensuring the cybersecurity).”

 Structure of the draft cybersecurity guidance

The 2022 draft cybersecurity guidance organizes the requirements into four major principles:

1. cybersecurity as part of device safety and the quality system regulations
2. designing for security
3. transparency
4. submission documentation

The draft cybersecurity guidance recommends the implementation of a Secure Product Development Framework (SPDF). However, there is not much detail provided in the guidance for a SPDF. In the past, the term for this type of process was referred to as a Secure Software Development Lifecycle (i.e. Secure SDLC). However, in February 2022, the NIST Computer Security Resource Center (CSRC) released version 1.1 of the Secure SDLC guidance which is now titled “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.” This guidance provides guidance on the implementation of best practices for reducing the risk of software vulnerabilities because existing standards for managing the software development lifecycle do not explicitly address software security (e.g. IEC 62304-1:2015). The SSDF recommends implementing a core set of high-level secure software development practices that can be integrated into your SDLC process. Your software development team will also require cybersecurity training.

Design for security is the second principle of the draft cybersecurity guidance

Under this new draft cybersecurity guidance, the FDA will be evaluating the cybersecurity of devices based on the ability of the device to provide and implement the following security objectives:

• Authenticity, which includes integrity;
• Authorization;
• Availability;
• Confidentiality; and
• Secure and timely updatability and patchability.

Transparency of cybersecurity information is for users

The draft cybersecurity guidance seeks to give device users more information pertaining to the device’s cybersecurity controls, potential risks, and other relevant information. This information will be in the form of an SBOM that is electronically readable. This information shall include disclosure of 1) known vulnerabilities or risks, 2) information to securely configure and update devices, and 3) communication interfaces and third-party software.

In addition to providing an SBOM, the FDA draft cybersecurity guidance includes requirements for cybersecurity labeling in section VI(A). There are 15 specific labeling requirements identified by the FDA for sharing with device users to improve the transparency of cybersecurity information. The first of these requirements is recommendations from the manufacturer for cybersecurity controls appropriate for the intended use environment (e.g., antimalware software, use of a firewall, password requirements). This first labeling requirement is identical to the 2018 draft guidance. Several of the other requirements are copied from the 2018 draft guidance, but others are new and/or reworded cybersecurity labeling requirements.

FDA Submission Documentation Requirements

The 2022 FDA draft cybersecurity guidance includes requirements for FDA submission documentation. Submission documentation must include a security risk management plan and report. The draft cybersecurity guidance explains on page 13 (numbered 9) that “performing security risk management is a distinct process from performing safety risk management as described in ISO 14971:2019.” Therefore, instead of using your safety risk management process, your software development team will need to have a different risk management process for software security. Details on the content for security risk management plans and reports can be found in AAMI TIR57:2016 – Principles for medical device security—Risk management. Appendix 2 also provides guidance for the inclusion of a) call flow diagrams, and b) information details for an architecture view.

Cybersecurity testing requirements for your FDA submission

The biggest impact of this new draft guidance may be the requirement for testing. The 2014 guidance has no testing requirement, the 2018 draft guidance mentioned testing 5 times in a few bullet points, but this new draft guidance mentions testing 43 times. The testing requirements for cybersecurity risk management verification include:

1. Security requirements
2. Threat mitigation
3. Vulnerability testing
4. Penetration testing

This guidance also includes a paragraph with multiple bullets of requirements for each of the four types of testing. This would essentially double the size and scope of the current software section for a 510k submission, and manufacturers will need to create new procedures and templates for their cybersecurity risk management process. For example, penetration testing requirements include the following elements:

• Independence and technical expertise of testers,
• Scope of testing,
• Duration of testing,
• Testing methods employed, and
• Test results, findings, and observations.

Differences between the cybersecurity guidance documents

The following table provides a high-level overview comparing the four cybersecurity guidance documents released by the FDA, including the 2016 guidance on post-market management of cybersecurity:

Vulnerability management plans

The FDA draft cybersecurity guidance document also has a requirement for manufacturers to develop a plan for identifying and communicating vulnerabilities to device users after the release of the device. The FDA requires this plan to be included in your device submission. The vulnerability management plan should include the following information (in addition to the requirements of the 2016 guidance for postmarket cybersecurity management):

• Personnel responsible;
• Sources, methods, and frequency for monitoring for and identifying vulnerabilities (e.g. researchers, NIST NVD, third-party software manufacturers, etc.);
• Periodic security testing to test identified vulnerability impact;
• Timeline to develop and release patches;
• Update processes;
• Patching capability (i.e. rate at which update can be delivered to devices);
• Description of their coordinated vulnerability disclosure process; and
• Description of how manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.

What’s the next step for the draft cybersecurity guidance?

In March the “Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act)” was introduced to the House of Representatives and the Senate. The goal of the PATCH Act is to enhance medical device security by requiring manufacturers to create a cybersecurity risk management plan for monitoring and addressing potential postmarket cybersecurity vulnerabilities. The FDA seeks comments on the draft cybersecurity guidance through July 7, 2022. Given the support of the new bill in the House of Representatives and Congress, it is likely that the FDA will get the support it needs for this new guidance. 

This article reviews the 2014 FDA guidance for premarket and post-market cybersecurity of medical devices with software and firmware—including requirements for reporting field corrections and removals.

Hospitals, home health systems, and medical devices are more connected now than ever. The automatic communication between medical devices and network systems is improving efficiency and accuracy in the world of healthcare. Medical devices are capable of more computing, analysis, reporting, and automation to improve the speed and quality of patient care. There are even devices that consist only of software (i.e. software as a medical device or SaMD). Along with technological advances, new risks and concerns are also introduced. The risk of hackers exploiting vulnerabilities in networks and software is inevitable. The FDA introduced guidance for both pre-market and post-market cybersecurity to assist manufacturers in developing effective controls to protect patients and users. Cybersecurity protection requires Identification, Protection, Detection, Response, and Recovery.

The first step is incorporating processes and procedures to improve device cybersecurity into your quality management system. You should have a specific cybersecurity plan (i.e. security risk management plan) to outline the steps necessary to ensure a safe and secure medical device. In addition, your software development team will need cybersecurity training. The only medical device guidance document specific to cybersecurity is currently AAMI TIR57:2016.

Identify Cybersecurity Risks

The key to understanding and assessing the cybersecurity risks involved with your device begin in the early stages of design development. At the start of the risk management process, you need to identify the essential safety and performance requirements of the device. You need to identify any potential cybersecurity vulnerabilities that could impact safety or performance, as well as the specific harms that could result if the vulnerability was exploited. In assessing the specific vulnerabilities, the FDA recommends using the Common Vulnerability Scoring System (CVSS). There is a CVSS calculator available online through NIST. The overall score is calculated based on different factors such as attack vector (local, adjacent network, network), access complexity (high, medium, low), authentication (multiple, single, none), the impact of confidentiality (none, partial, complete), exploitability (unproven that exploit exists, proof of concept code, functional exploit exists), remediation level (official fix, temporary fix, workaround, unavailable), collateral damage potential (low, medium, high), etc. This score is used in the hazard analysis in determining the level of risk.

Cybersecurity Protection

The process of assessing the exploitability and harms can also assist in determining mitigations that can be implemented to reduce the cybersecurity risk. During the design process, the FDA expects you to implement as many protections as practicable. Protections include:

• Limit Access to Trusted Users
  • Password protection strengthened password requirements
  • User authentication
  • Layered privileges based on user role
• Limit Access to Tampering
  • Physical locks on devices and/or communication ports
  • Automatic timed methods to terminate sessions
• Ensure Trusted Content
  • Restrict software or firmware updates to authenticated code
  • Systematic procedures for authorized users to download software and firmware only from the manufacturer
  • Ensure capability of secure data transfer, use of encryption

Cybersecurity Detection

The FDA also requires you to implement features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during regular use. You should develop and provide information to the end-user concerning appropriate actions to take upon the detection of a cybersecurity event. Methods for retention and recovery should be provided to allow recovery of device configuration by an authenticated privileged user.

If you include off-the-shelf (OTS) software in your device, you are responsible for the performance of the software as part of the device. All software changes to address cybersecurity vulnerabilities of the OTS software need to be validated. You need to maintain a formal business relationship with the OTS vendor to ensure timely notification of any information concerning quality problems or corrective actions. Sometimes you will need to involve the OTS vendor to correct cybersecurity vulnerabilities.

Post-Market Surveillance

Once you complete the hazard analysis, mitigation implementation, validations, and has deployed their device for use – your activities shift to post-market management. Several QMS tools can assist in the cybersecurity processes post-market, including complaint handling, quality audits, corrective and preventive action, ongoing risk analysis, and servicing. A critical component of every cybersecurity program is the monitoring of cybersecurity information sources to assist in the identification and detection of risk. You should maintain contact with third-party software suppliers for the identification of new vulnerabilities, updates, and patches that come available.

There are many sources that companies should follow for information relating to cybersecurity, including independent security researchers, in-house testing, software or hardware suppliers, healthcare facilities, and Information Sharing and Analysis Organizations (ISAO). Involvement in ISAOs is strongly recommended by the FDA and reduces your reporting burden if an upgrade or patch is required post-market. ISAOs share vulnerabilities and threats that impact medical devices with their members. They share and disseminate cybersecurity information and intelligence pertaining to vulnerabilities and threats spanning many technology sectors, and are seen as an integral part of your post-market cybersecurity surveillance program.

Response and Recovery

If you identify a cybersecurity vulnerability, there are remediation and reporting steps that need to occur. Remediation may involve a software update, bug fixes, patches, “defense-in-depth” strategies to remove malware, or covering an access port to reduce the vulnerability. Uncontrolled risks should be remediated as soon as possible and must be reported to the FDA according to 21 CFR 806. Certain circumstances remove the reporting requirement. The decision flowchart below can be used to determine the reporting requirements.

In addition to reporting corrections and removals, the FDA identifies specific content to be included in PMA periodic reports regarding vulnerabilities and risks. If you have a Class III device, you should review that section thoroughly to ensure annual report compliance.

If a device contains software or firmware, cybersecurity will be an important component of the risk management processes, and continual cybersecurity management will be necessary to ensure the ongoing safety and effectiveness of your device. If you need more help with cybersecurity risk management of your medical device, please schedule a free 30-minute call with Medical Device Academy by clicking on the link below.