FDA Medical Device Cybersecurity: Understanding Your Basic Regulatory Requirements
A cyber-attacker gains access to a care provider’s computer network through an e-mail phishing trap and assumes command of a file server to which a heart monitor is attached. While scanning the network for devices, the attacker takes control (e.g., power off, continuously reboot) of all heart monitors in the ICU, putting multiple patients at risk.
It defies logic why a hacker would want to intentionally harm patients, but this type of threat is definitely not science fiction. It is one example of the risks that connected devices pose to patient safety according to a recently published paper by the US Department of Health and Human Services (HHS), which oversees FDA. In October 2018, HHS entered into a Memorandum of Understanding with the US Department of Homeland Security to share information related to medical device cybersecurity threats. The agreement shows that the US government views potential cyber-attacks as a legitimate risk to public health.
For its part, FDA occasionally issues medical device cybersecurity notices to spread the word about potential serious security threats. It most recently did so in a notice related to implantable cardiac devices, programmers, and home monitors made by a major device manufacturer. In this example, FDA published a potential (not actual) security vulnerability, noting that the wireless telemetry protocol employed in some of the company’s programmer devices did not use encryption, authentication, or authorization. As FDA noted, “…these vulnerabilities, if exploited, could allow an unauthorized individual (for example, someone other than the patient’s physician) to access and potentially manipulate an implantable device, home monitor, or clinic programmer.”
Fortunately, these alarming “made for TV” scenarios seemingly have not translated into reality. In October 2018, FDA Commissioner Scott Gottlieb wrote, “The FDA isn’t aware of any reports of an unauthorized user exploiting a cybersecurity vulnerability in a medical device that is in use by a patient.” That’s probably because hackers are far more focused on breaching healthcare computer networks containing patient data, financial records, etc. – all data they can sell on the dark web or use to extort money from target organizations. Also, there is little doubt that many serious security intrusions go unreported or, worse, undiscovered.
That being said, the apparent rarity of direct medical device security breaches by hackers does not absolve you of regulatory responsibility to take precautions to prevent them. Manufacturers, hospital/clinics, and users all play a role in preventing intrusion.
Planning and managing device security requires a cross-functional focus, including quality/regulatory and design coordination. If your device connects to any sort of network, cybersecurity needs to be an important factor in your risk management process. The risks posed by security breaches are omnipresent and always evolving, so your risk analysis needs to take into account the likelihood that your device could be hacked and the severity of the harm if a vulnerability were exploited. You will need to work with your engineering and design team to make this assessment.
FDA places medical device cybersecurity risks into two buckets
In October 2018, FDA issued a revised draft guidance document intended to help manufacturers meet FDA guidelines for 510(k) or PMA submissions. (See a link to this document below.) In the document, FDA considers devices that connect to the internet, a network, or another device – and where an intrusion could result in harm to multiple patients – to be a Tier 1 (higher risk) device. Examples include devices such as pacemakers, brain stimulators, dialysis devices, infusion and insulin pumps, and connected systems that interact with these devices. Pretty much all other connected devices are considered Tier 2 (standard risk).
Yes, you are responsible for off-the-shelf (OTS) software embedded in your device
Many device manufacturers assume that OTS software incorporated into their device has been thoroughly tested for security vulnerabilities, and that the device manufacturer bears no responsibility for testing it further. Despite what an OEM supplier has done to test and validate their software, FDA still considers you responsible for 100% of your device, not 90%. This means that you must establish a cybersecurity vulnerability and management approach as part of the software validation and risk analysis plan. FDA issued a very short Q&A document on medical device OTS software technology light years ago (2005), but it is worth reviewing because the document addresses some common questions you may have.
FDA guidance and international standards related to medical device software and SaMD (software as a medical device) security
There are a variety of guidance documents related to connected devices and cybersecurity that you should be aware of. They include:
Content of Premarket Submissions for Software Contained in Medical Devices – May 2005
General recommendations for premarket submissions for devices incorporating software, including standalone software applications and hardware-based devices that incorporate software.
Content of Premarket Submissions for Management of Cybersecurity in Medical Devices – October 2018
Builds on the guidance document above but includes specific cybersecurity recommendations related to device design, labeling, and documentation that FDA recommends be included in 510(k) and PMA submissions. Pay close attention to Section VI on labeling recommendations and Section VII on design and risk management documentation.
Postmarket Management of Cybersecurity in Medical Devices – December 2016
Contains recommendations for managing postmarket cybersecurity vulnerabilities for medical devices already in use. Addresses patches and updates, plus situations where reporting to FDA might be warranted.
Here are some additional documents worth noting:
- MITRE: Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook – October 2018
- IMDRF: “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations – September 2014. The International Organization for Standardization (ISO) has also published a series of IEC/TR 80001 documents under the subtitle “Application of risk management for IT-networks incorporating medical devices.” In addition, pay special attention to the IEC/TR 80002 series of documents also published by the ISO – they provide in-depth guidance on how to apply ISO 14791 to medical device software, advice on validation of software, and a description of the life cycle of software (also see IEC 62304).
Standardized form and cybersecurity bill of materials (CBOM)
The increased focus on awareness and scrutiny of cybersecurity issues has also led to the development of a standardized form that allows manufacturers to disclose the security-related features of their medical devices. The MDS2 form, developed by the Healthcare Information and Management Systems Society (HIMSS) and the Association of Electrical Equipment and Medical Imaging Manufacturers, allows buyers to more easily assess the vulnerabilities and risks associated with a specific medical device.
Complementary to the MDS2 documents is the cybersecurity bill of materials (CBOM) floated by FDA. This is a comprehensive list of all software packages incorporated into the build of software.
Cybersecurity throughout the device life cycle and beyond
A final thing to keep in mind is the risk posed to patients and users after you stop supporting the device. What risks exist for older models once software patches are no longer offered? How will you deal with them? This needs to be part of your overall risk assessment and addressed in your postmarket surveillance plan.
While there has yet to be a published widespread attack on medical devices in the US, it does not diminish the importance of remaining vigilant and taking precautionary steps to prevent such an attack from happening. The number of medical devices connected to the internet and other networks will surely continue to grow, and with it comes the risk that hackers will engage in nefarious activities. Manufacturers must remain vigilant and follow current best practices for cybersecurity.