GET THE FREE NATIONAL CYBER SECURITY APP FOR YOUR PHONE AND TABLET
New Food and Drug Administration draft guidance aims to alleviate a common topic of confusion in the healthcare sector: whether medical device makers need to submit for FDA review the modifications manufacturers make that affect cybersecurity in existing products.
In an Aug. 5 statement, the FDA says two new draft guidance documents contain updated recommendations on when manufacturers should submit new 510(k) forms for device modifications, including wireless changes that could impact cybersecurity, and also software changes that aim to improve device cybersecurity.
The FDA drafts aim to help manufacturers determine when they are required to notify the agency about modifications made to certain medical devices already on the market, including changes to software in devices.
“These draft recommendations are intended to help manufacturers determine when a change is significant enough to warrant FDA review, including major changes or modifications to the intended use that could significantly impact safety and effectiveness,” says Jeffrey Shuren, M.D., director of the FDA’s Center for Devices and Radiological Health in the statement. “Medical device technology evolves quickly, and not all changes made to marketed devices alter their safety profile or require our review.”
When finalized, the two guidance documents will provide improved clarity, regarding minor changes that do not require FDA review, and help ensure that the FDA receives appropriate submissions for modifications that do require premarket review by the agency.
An FDA spokeswoman says the non-binding draft guidance will be open for public comment for 90 days, or until Nov. 7. No tentative date has been set yet for when FDA could issue final guidance, she says. By non-binding, the draft guidance recommendations are not mandates: FDA will evaluate the public feedback before finalizing the documents.
Changes Related to Cybersecurity
In its guidance to help manufacturers determine whether to notify the agency of software device changes, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, FDA writes, “in many cases, a change made solely to strengthen cybersecurity is not likely to require a new [FDA review submission]. Cybersecurity updates are considered a subset of software changes that are implemented to strengthen the security of a system, protect information, and reduce disruption in service.”
FDA says it “expects manufacturers to ensure that such changes do not impact the performance of the device by performing necessary analysis, verification and/or validation.” If a manufacturer becomes aware of “any incidental or unintended impacts” of the change on other aspects of the software or device, the manufacturer should continue assessing remaining questions contained in the FDA guidance.
However, FDA’s second draft guidance, Deciding When to Submit a 510(k) for a Change to an Existing Device, advises that certain modifications to medical devices that impact wireless communication could indeed necessitate that manufacturers submit a FDA 510(5) review request.
“Changes to device communication between device components or between the modified device and other products, particularly from wired to wireless, may change a device’s risk profile by introducing or modifying risks regarding data transmission or cybersecurity,” FDA writes.
For instance, FDA says, “changes to employ wireless communication in devices where it was previously not used are likely to significantly affect safety or effectiveness and likely require a new 510(k). This is particularly true when wireless communication is used to control device operations.”
Medical device cybersecurity expert Kevin Fu, CEO of VirtaLabs, and director of University of Michigan’s Archimedes Research Center for Medical Device Security, says the FDA’s guidance related to wireless modifications “codifies” what he’s been advising FDA, manufacturers, and healthcare providers for years: “Wireless cybersecurity risks are different from wired and require different hazard analysis and compensating controls.”
Fu adds, “Wireless can help protect the sterile field in an operating room, but wireless also introduces new risks for cybersecurity because perimeter defenses are even less effective for wireless.” The draft guidance “signals that manufacturers are responsible for the safety and effectiveness of cybersecurity risks, no matter the transmission medium. It used to be that a manufacturer could slap on a crappy USB wireless dongle on their radiology products without thoughtful hazard analysis of the risks. That age is over.”
Some security experts say the new draft guidance will potentially help reduce confusion among some manufacturers, and in some cases eliminate excuses by other device makers about how to address cybersecurity issues with their products.
Although the FDA draft guidance is not a change of policy regarding cybersecurity – but rather mainly clarification – some manufacturers resisted making changes to their products to address cybersecurity because of their belief that such modifications required FDA approval, notes Mac McMillan, CEO of security consulting firm CynergisTek.
“I’m glad to see this come out in their official guidance,” McMillan says. “FDA has always had this position that security changes that don’t adversely affect the performance of the device don’t require recertification. This just hopefully spells it out for those that are still confused, or for those vendors who hide behind the FDA’s process when consumers ask for security updates,” he says.
“Interestingly enough, every CISO I know in healthcare already knows this. Hopefully though, having official guidance from the FDA – as opposed to just a position letter – will help them get vendors to respond better,” McMillan adds.
Still, the draft guidance – if finalized – won’t address all issues surrounding medical device cybersecurity, especially with older legacy products, McMillan notes.
The guidance material “should definitely help new devices as manufacturers anticipate this need in new designs, [but] it will be hit or miss in legacy systems. Some of these are not architected to support updates. They need to go.”