The Hackers are Coming!

By Jennifer D. Newberger –

It is not often that CDRH guidance documents get much attention outside the trade press and medical device circles.  So when The Wall Street Journal and The Washington Post both publish articles about a draft guidance document on the same day, it must mean big, important news.  Or must it?

On June 13, The Washington Post published an article titled, “FDA, facing cybersecurity threats, tightens medical-device standards.”  The Wall Street Journal gets to the point more directly with the title, “Patients Put at Risk By Computer Viruses.”  The reality seems to be that FDA has not actually tightened its medical device standards (which, of course, can’t be done through a draft guidance, not legally, anyway), and that while the potential for patient harm from viruses or malware exists, neither FDA nor industry is actually aware of such harm occurring.  Despite the WSJ title, the article itself states that FDA is not actually aware of deaths or injuries resulting from computer viruses or other cybersecurity breaches. 

So what is really going on, and what does FDA’s guidance actually address?  It is not news that many more medical devices today operate using wireless and Internet- and network-connected features.  With that comes the risk that the software running these devices will get a bug or virus that could interrupt the functionality of the device, or could intentionally be hacked.  FDA has been addressing the issue of cybersecurity for medical devices at least as far back as 2005, when it issued a guidance document titled, “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” ("OTS Guidance").  That guidance document focused largely on quality system, post-market controls the manufacturer could put in place to reduce the likelihood of a cybersecurity attack.  The draft guidance issued on June 13, “Content of Premarket Submission for Management of Cybersecurity in Medical Devices,” addresses what companies should include in their premarket submissions “to reduce the risk that device functionality is intentionally or unintentionally compromised.”  Draft Guidance, at 2.

The draft guidance focuses on three “security controls”:  confidentiality, integrity, and availability.  Confidentiality means data are accessible only to authorized individuals; integrity means the data are accurate and have not been improperly modified; and availability means that data are “accessible and usable on a timely basis in the expected manner.”  Id.  To maintain these controls, the guidance asks that manufacturers “consider cybersecurity during the design phase of the medical device, as this can result in more robust and efficient mitigation of cybersecurity risks.”  Draft Guidance, at 3.

The guidance states that manufacturers should provide the following information in a premarket submission to demonstrate the cybersecurity of the medical device:

1. Hazard analysis, mitigations, and design consideration pertaining to intentional and unintentional cybersecurity risks associated with the device;
2. A “traceability matrix” linking the actual cybersecurity controls to the cybersecurity risks considered;
3. Plan for providing validated updates and patches to operating systems or software as needed;
4. Appropriate documentation to demonstrate that the device will be provided to purchasers free of malware; and
5. Device instructions for use and product specifications related to recommended anti-virus software and/or firewall use.

The real question is, what does this mean for medical device development?  The Washington Post article brazenly states that the new “tightened standards” expressed in the draft guidance “will allow the FDA to block approval of devices if manufacturers don’t provide adequate plans for protecting them.”  This seems to go beyond what the draft guidelines say, and beyond what FDA has the statutory and regulatory authority to do.  Let’s not forget that for 510(k) devices, the question is only if the device is substantially equivalent to a predicate device.  If the proposed device meets that standard, FDA would be hard pressed to issue a not substantially equivalent letter based solely on whether the 510(k) notice addresses cybersecurity protection to FDA’s satisfaction.  (Of course, industry has seen many examples where FDA has applied tighter standards through draft guidance, and showing that a new device is as safe and effective as the predicate device is not enough.)  For PMAs, the standard is one of reasonable assurance of safety and effectiveness.  If FDA can show that the potential, unrealized cybersecurity risks prevent the device from making that showing, it could perhaps hold up the application.  However, both articles make clear that while there have been instances of viruses infecting computer device software, FDA is not aware of any injuries or deaths resulting from the viruses, nor is it aware of any evidence that hackers have deliberately targeted a hospital network or medical device “for a malicious cyberattack.” 

This doesn’t mean it couldn’t happen, and of course manufacturers should attempt to design against these potential risks as much as possible.  In discussing what manufacturers could be doing for currently marketed devices, the issue of what corrections need to be reported to FDA seems to have reared its ugly head.  The Washington Post article states that “manufacturers typically refuse to apply software patches, claiming the FDA does not allow updates to regulated devices, but FDA officials say that is not the case.”  According to the WSJ, “manufacturers argue that FDA regulations limit the changes that can be made to a device’s software.”

This concern on the part of manufacturers may stem from a draft guidance we discussed in a prior blog post.  In that draft guidance, FDA took a new position, stating that corrections that do not meet the definition of a recall, but rather are only “product enhancements,” still must be reported to FDA.  Under this flawed analysis, FDA may be able to take the position that something as simple as a software patch would need to be reported, if it believed the patch was introduced to reduce a risk to health.  This would significantly increase the regulatory burden for device manufacturers as well as deter these improvements.  This would also be in conflict with FDA’s earlier statements in the 2005 OTS Guidance, in which FDA clearly stated that neither a new 510(k) submission nor a report under Part 806 would usually be required for implementation of a software patch to address cybersecurity vulnerability.  OTS Guidance, at 4, 5.  In discussing the Part 806 reporting requirements, FDA said that reporting would not usually be required “because most software patches are installed to reduce the risk of developing a problem associated with a cybersecurity vulnerability and not to address a risk to health posed by the device. In most cases, therefore, you would not need to report a cybersecurity patch under 21 CFR Part 806 so long as you have evaluated the change and recorded the correction in your records.”  Id. at 5.  Hopefully, this is the position FDA would take today, and an improvement to cybersecurity would not been seen as an action taken to reduce a risk to health.

FDA will need to consider how to go about encouraging manufacturers to take the steps necessary to protect their currently marketed devices from cybersecurity, while at the same time not imposing additional regulatory burdens.  The same is true for new devices.  Manufacturers should consider the cybersecurity risks when designing a new product, but not all potential eventualities can be adequately considered and addressed, and FDA should not be looking for manufacturers to guarantee the absolute cybersecurity of their devices any more than they can guarantee there will be no adverse events associated with use of the device.  Given the pace of development in computer technology, the goal of preventing all future risks is not achievable.  Hopefully FDA and industry can work together to strike a balance that will enhance cybersecurity without inhibiting the ability of new devices to come to market.

(The title of this post is taken from Ki Mae Heussner, “FDA to medical-device manufacturers: batten the hatches, the hackers are coming,” GigaOM. )