Mitigation of Cybersecurity Risks in Medical Device Software: FDA Discussion & Insights for OEMs, Remanufacturers, and Servicers

I. OVERVIEW

The U.S. Food & Drug Administration (“FDA”) has increased its focus on mitigating cybersecurity risks in medical device software. On June 24, 2021, the FDA issued two documents that are important not only for entities that service or remanufacture medical devices (“servicers” and “remanufacturers,” respectively), but also original equipment manufacturers (“OEMs”) of such devices.

1. Draft guidance that distinguishes between “remanufacturing” and “servicing” a medical device. (See FDA, “Remanufacturing of Medical Devices – Draft Guidance for Industry and Food and Drug Administration Staff,” (June 24, 2021) (hereinafter “Draft Remanufacturing Guidance”)).
2. A discussion paper on the challenges and opportunities in addressing cybersecurity issues while servicing medical devices. (See FDA, “Strengthening Cybersecurity Practices Associated with Servicing of Medical Devices: Challenges and Opportunities,” (June 24, 2021) (hereinafter “Cybersecurity Discussion Paper”)).

The public comment period for both the Draft Remanufacturing Guidance and Cybersecurity Discussion Paper closes September 22, 2021.

Taken together, the documents underscore the criticality for OEMs to design medical device software such that to the extent possible, cybersecurity threats are mitigated upfront, and to collaborate with all stakeholders, including health care establishments, healthcare providers, and independent service organizations to identify and address cybersecurity vulnerabilities through the device lifecycle. Moreover, the FDA’s guidance reflects that changes to software are more likely to be considered “remanufacturing” rather than merely “servicing,” and are thus subject to additional requirements. 

In addition to its recent draft guidance and discussion paper, the FDA has also appointed Dr. Kevin Fu as the agency’s first acting director of medical device cybersecurity. Dr. Fu has stated that he anticipates the FDA will issue an updated draft version of the premarket cybersecurity guidance for OEMs to take into consideration while designing software for medical devices. (See Nancy Crotti, “New FDA Medtech Cybersecurity Chief Expects Guidance to Debut this Year,” (Feb. 19, 2021), (hereinafter “Crotti”); see also “Kevin Fu fills new leadership position at FDA’s Center for Devices and Radiological Health, overseeing medical device security”). The existing final version of the guidance was finalized in October 2014, and the FDA issued subsequent draft guidance on the same topic in October 2018. 

This insight (1) highlights the key takeaways from the Draft Remanufacturing Guidance and Cybersecurity Discussion Paper, and (2) discusses what to expect from FDA’s forthcoming updated premarket cybersecurity guidance.

II. KEY TAKEAWAYS FOR THE MEDICAL DEVICE INDUSTRY

While a detailed discussion of the FDA’s publications is provided below, the top-line recommendations for OEMs, in light of the FDA’s guidance, include the following:

• Incorporate procedures that would make the software both trustworthy and resilient. Trustworthiness may require the use of authentication and encryption technology. Resilience may require fall back to a safe mode in the case of a cyberattack that infiltrates the system.
• Consider making your software design and update practices transparent. Transparency may require timely notification of a newly discovered attack and timely security updates.
• Include in the design and implementation of the software a specification of cybersecurity features and validation of those features, and a Cybersecurity Bill of Materials (“CBOM”), preferably cross-linked to a vulnerability database (e.g., the National Vulnerability Database (NVD)). The specification may be based on threat modeling and security risk assessments.
• Regularly employ static and/or dynamic vulnerability testing of the software.

If you are an entity providing a maintenance service for a medical device that includes software, it is worth considering, in light of FDA’s Cybersecurity Discussion Paper, the following:

• Report any known or suspected incidents of cyberattacks to the OEMs and/or remanufacturers as soon as possible.
• Update software in a secure manner.

III. THE DRAFT REMANUFACTURING GUIDANCE: SERVICING VS. REMANUFACTURING 

The FDA’s Draft Remanufacturing Guidance draws clear distinctions between the act of “remanufacturing” and the act of “servicing” a medical device. One key takeaway is that changes to software generally are likelier to be considered remanufacturing compared to changes to hardware, which are likelier to be considered merely servicing. For software engineers, this classification is important, as “remanufacturers” are subject to different — and higher — default burdens regarding building security into devices. The Draft Remanufacturing Guidance provides the following specifics regarding this distinction: 

• The FDA describes remanufacturing as “the processing, conditioning, renovating, repackaging, restoring, or any other act done to a finished device that significantly changes the finished device’s performance or safety specifications, or intended use.” (Draft Remanufacturing Guidance at 3 (emphasis added)).
• Servicing, on the other hand, means the repair and/or preventive or routine maintenance of one or more parts in a finished device, after distribution, for purposes of returning it to the safety and performance specifications established by the OEM and to meet its original intended use.” (Id. (emphasis added)). 

The FDA provides a flow chart to aid in the classification of an entity as a remanufacturer or as a servicing entity, when that entity makes non-software changes to a medical device. (See Id. at 8, 9, and 11 (Figure 1); see also Id. at 3 (describing that the actions performed by an entity, and not the entities self-designation, guide the classification)). The FDA stresses that the flow chart “and its accompanying text should not be applied to changes involving software.” (Id. at 15; see also Id. at 8).

Many software changes, the agency explains, would likely be considered remanufacturing — not servicing — due to the “impact on a product’s software architecture, software requirements specifications, unresolved anomalies, and other key characteristics.” (Id. at 15-16). The FDA notes, however, that activities like assessments for viruses, malware, and other cybersecurity issues, or installing cybersecurity updates, would not be considered remanufacturing, because “they generally do not significantly change the performance or safety specifications of the device.” (Id. at 16). Service providers should document their rationale for why their work is not remanufacturing, consistent with the Draft Remanufacturing Guidance. Servicers should also understand that the FDA encourages servicers to work with OEMs (see Cybersecurity Discussion Paper).

Cybersecurity threats can emerge from time-to-time and, as such, protection against cybersecurity should be provided over the total product life-cycle of a medical device, or “TPLC.” (See Cybersecurity Discussion Paper at 1). The FDA guidance contemplates that when a new cybersecurity threat emerges, the OEM of the vulnerable device would provide cybersecurity updates in compliance with applicable FDA regulations, where the service entity would apply those updates. (See Draft Remanufacturing Guidance at 16).

IV. MITIGATING CYBERSECURITY RISK IN MEDICAL DEVICES

A. Mitigating Cybersecurity Risk while Servicing Medical Devices

The Cybersecurity Discussion Paper describes four cybersecurity priority issues for medical devices: 

1. Establish privileged access. In other words, “limit access only to privileged device users” who are authorized service entities. (Cybersecurity Discussion Paper at 3). Recognizing the need to access the components and software of a medical device in order to service the device, the FDA contemplates a balance between limiting the access to preserve security while granting limited access to authorized servicing entities in order to perform servicing-related functions. (See Id. at 3-4).
2. Identify cybersecurity vulnerabilities and incidents. (Id. at 4). The FDA recognizes that “[c]ybersecurity is a shared responsibility among stakeholders, including OEMs, healthcare establishments, healthcare providers, and independent service organizations (ISOs),” (id. at 2) and further recognizes that “[s]ervicing entities are well positioned to help identify cybersecurity vulnerabilities and exploits early, sometimes even before the OEM becomes aware.” (Id. at 4). The FDA also states that sharing post-market data among various entities can improve vulnerability detection, and can accelerate implantation of corrective measures. (See Id.).
3. Prevent and mitigate detected vulnerabilities, where the OEM would provide “authorized cybersecurity updates and upgrades” after performing “verification and validation of design changes where appropriate, including software changes to address cybersecurity vulnerabilities.” (See Id.).
4. Issue warnings about the inability to update software. FDA recognizes that over the life of a medical device, it may not be possible to update the device’s software to prevent cyberattacks, though the device may otherwise function as intended and may be useful. (See Id. at 4-5). In such cases, the FDA expects the device users, such as healthcare providers, to be warned of an impending end-of-line support. (See Id. at 5).

In short, in order to enhance cybersecurity of medical devices, the FDA contemplates that OEMs would provide software updates in response to detected vulnerabilities, whereas servicing entities would install these updates. The FDA also contemplates that prior to dissemination, the updates would be verified and validated using conventional software engineering practices in the design and development of medical software. (See FDA, “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices,” 3-4, 11-13 (2005), (describing the required contents of the “Software Requirements Specification (SRS)” document and software verification and validation)).

B. Premarket Cybersecurity Guidance: Mitigating Cybersecurity Risk When Designing Medical Devices

The FDA does not specifically identify how an OEM can address cybersecurity risks during the design phase of the software. Rather, according to Dr. Fu, the agency expects to issue “premarket cybersecurity guidance” later this year that covers this topic. (See Crotti).

Dr. Fu had previously written that hacking of medical devices is not the only cybersecurity risk, and that “the unavailability of patient care and the lack of health data integrity” are also significant concerns. (Kevin Fu and James Blum, “Inside Risks: Controlling for cybersecurity risks of medical device software,” 56 Communications of the ACM 21, 22 (2013), (hereinafter “Inside Risks”)). As a way to address these concerns, Inside Risks noted certain recommendations from the 2013 FDA guidance, such as advising OEMs to provide a specification of the cybersecurity risks considered, a specification of the controls provided, and validation of the controls via a traceability matrix. (Id. at 23 (citations omitted)). These recommendations are expected in the forthcoming guidance.

Referring to FDA’s 2018 Medical Device Safety Action Plan, Dr. Fu also noted in the Crotti article that manufacturers may be expected to take certain measures such as: “[c]omprehensive threat modeling,” “[s]oftware bills of materials (SBOMs),” “[s]ecurity risk assessments,” use of “security controls such as intrusion detection” and “encryption/authentication algorithms,” and [s]ecure software and firmware updates.” (Crotti; see The FDA, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, Draft Guidance for Industry and Food and Drug Administration Staff,” (“2018 Guidance”) at 21-22 (discussing threat models), 11 and 22 (discussing security risk assessment), 23 (discussing cybersecurity controls), and 12, 15, and 23 (discussing encryption) (2018)). In addition, Dr. Fu emphasized that in the forthcoming guidance, focus would remain on “the three [cybersecurity] cornerstones of trustworthiness, transparency and resilience,” that were described in a 2019 FDA public workshop on premarket submissions for managing cybersecurity in medical devices. (Id.; see also FDA, “Public Workshop – Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” (January 29-30, 2019)).

Vulnerability scanning, i.e., analyzing software to detect vulnerabilities therein, may also be recommended in the forthcoming guidance. Specifically, the approach that the FDA recommends in the February 2021 guidance regarding servicing of medical devices is based on the conventional requirements-specification-verification model that requires a priori knowledge of cybersecurity risks. (See Robyn R. Lutz, Software Engineering for Safety: A Roadmap, 2000 ICSE ’00: Proceedings of the Int’l. Conf. on Software Eng’g 213, 215, 217 (2000); Paul Ammann & Jeff Offutt, Introduction to Software Testing Ch.10 (Cambridge University Press, 2d ed.) (2017) (describing software life cycle in the context of software testing); see also Paul C. Jorgensen, Software Testing – A Craftsman’s Approach 2-4 (CRC Press, 4th ed. 2014) (describing the conventional waterfall model of software life cycle); Hans van Vliet, Software Engineering: Principles and Practice 48 (2007) (same)). 

Cybersecurity or vulnerability risks can, however, be too numerous to be specified and verified. For example, the MITRE organization lists 418 known weaknesses in software. (See https://cwe.mitre.org/data/definitions/699.html). Meanwhile, the Open Web Application Security Project® (OWASP) lists 60 different types of software vulnerabilities. (See https://owasp.org/www-community/vulnerabilities/). It can therefore be difficult, if not impossible, to contemplate and specify all such vulnerabilities beforehand, and to provide verified controls to address such vulnerabilities. This problem can become more complex as new kinds of threats and vulnerabilities are discovered. The reactive approach of providing an update after a vulnerability is detected may thus not be effective. (See Inside Risks at 23 (stating that “[s]ecurity is difficult to bolt on after the fact, and is most effective when designed in”)).

To improve on prior FDA guidance, FDA may also issue updated guidance setting forth expectations for an OEM to perform code scanning using automated tools. This guidance would join the October 2018 premarket draft guidance that mentions “vulnerability scanning” and “static and dynamic code analysis.” (2018 Guidance at 23). The OWASP lists several tools for this purpose. One kind of tool, known as Static Application Security Testing (SAST) tools, analyzes the source code of the software and/or its compiled binary/executable version, and can find security flaws. (See https://owasp.org/www-community/Source_Code_Analysis_Tools). Another kind of tool, known as “Dynamic Application Security Testing (DAST)” tools, relies on executing the software in a test environment for detecting vulnerabilities in the software. (See https://owasp.org/www-community/Vulnerability_Scanning_Tools). These tools typically do not require advance knowledge of a particular cybersecurity threat. Also, these tools generally rely on commercially available databases of known threats and weaknesses. Since these databases may be updated frequently, performing cybersecurity analysis during the initial design phase — just before deployment of the software — can provide protection against the latest known threats and weaknesses. Going forward, performing periodic reviews over the life cycle of the medical device, e.g., during servicing, can also help detect and provide protection against newly emerged threats.

The public comment period for both the Draft Remanufacturing Guidance Cybersecurity Discussion Paper closes September 22, 2021.

Bram Schumer was a contributing author to this insights post.