Ensuring the Safety of Connected Medical Devices – Tips from Industry Leaders

By Cat Cole, Technical Director, Digital Medicine Society (DiMe)  & Mike Dow, Senior Manager of Product Management, Silicon Labs

On October 1, the new FDA Cybersecurity Guidance for Medical Devices took effect to aid in the goal of ensuring the safety of connected medical devices. To aid product developers who are planning for FDA submissions, Cat Cole, Technical Director, Digital Medicine Society (DiMe) and Mike Dow, Senior Manager of Product Management, Silicon Labs participated in this Q&A to share some tips and recommendations for product developers looking to navigate the new landscape of medical devices.

Question: How will the FDA’s new Cybersecurity in Medical Device Guidance affect the manufacturing process of medical devices? What will this new guidance mean for the downstream supply chain?

MD: The short answer is that companies need to move as quickly as possible to meet the requirements in 542B “Ensuring Cybersecurity of Devices.” This should be done through showing that medical device suppliers have a public facing Security Vulnerability reporting process as well as a public facing Security Advisory process. Beyond a public facing way to report vulnerabilities and publish security vulnerabilities, they must also have software and hardware development processes to prevent security vulnerabilities in the first place. This is commonly termed “Security by Design”. For hardware it means extensive threat modeling, security design reviews to cover identified threats, and security penetration testing. For software that means Secure Software Development Life-Cycle (Secure SDLC) processes to make sure software is designed and built to severely limit software vulnerabilities in the first place. These kinds of activities include things like threat analysis, security code reviews, static code analysis, and fuzz testing of interfaces.

In addition, they must have the ability to apply security patches to devices (wired or wireless) in the field on a regular basis and an ad hoc basis if needed. This usually means over the air secure updates of software. Additionally, they must also provide SBOMs for medical devices that meet the recommendations of National Telecommunications and Information Administration (NTIA). Lastly, they should plan to comply with some kind of security certifications scheme such as PSA Certified or SESIP.

CC: From a broader industry perspective, this will differentiate those manufacturers and developers ready to provide highly-secure products in a tough market. The regulatory considerations for building medical devices often require years of development, so stakeholders across the industry – from our regulatory colleagues at FDA to component manufacturers like Silicon Labs as well as our own efforts at DiMe and those of our fellow non-profits in this space like the Biohacking Village and I Am The Cavalry – need to continue to provide assistance that enables smaller companies – with innovative products but a lack of resources – to succeed. 

Question: Is this just step 1? Do you envision additional innovations and new security protocols over the next few years to combat “bad actors”? Are there ways to streamline the inclusion of these protocols, or will it put an added strain on the system?

MD: Secure identities which allow cryptographic authentication of a device combined with secure boot and tamper are incredibly effective in preventing bad actors from creating rogue devices or permanently taking them over. Temporary takeover of devices, called run-time vulnerabilities, are harder to prevent and require creating code that has ideally zero vulnerabilities that can be exploited.  A rigorous Secure Software Development Life-Cycle process is the best line of defense here. Then you can combine that with a targeted use of a Trusted Execution Environment (TEE i.e., Trust Zone) to segregate code bases that might be more prone to real-time attacks from other secure code.

CC: While the FDA is building in layers to ensure longevity rather than a prescriptive approach, there will absolutely be additional security protocols over the next few years, especially with the lack of knowledge around generative AI’s impact on cybersecurity. Bad actors are not going away and our attack surface will continue to increase as we continue to digitize the healthcare industry. If we’re not constantly reviewing and designing new protocols, we will face the same risks we’re trying to prevent today. All that is to say, invest in security early and often, because it’s a critical part of a successful go to market strategy.

Question: What is the most important advice you would give to medical device makers when considering how to make their products most secure?

CC: I think I may have gotten ahead of this question in my previous remark! I’ll add that product developers should think of security as a safety issue when they are developing medical products, because security breaches have an equally grave impact. 

MD: This is the mantra of every security professional… “Design security in from the beginning and do not try to bolt on security after the product is complete”.

Question: How do you recommend device makers make regular updates and changes to their products to adhere to cybersecurity regulations?

MD: As hackers continuously innovate their attacks, the security of a device will have to continuously evolve to address those new attacks. This is why the FDA recommendations are driving to having rigorous security processes NOT just a one time prescriptive do A, B, and C. They are trying to force a “Secure by Design” cycle of development that will evolve overtime. By also requiring a method for reporting security vulnerabilities, both internal and external, AND requiring a method for patching those vulnerabilities they are expanding the product lifecycle to include not only securely designing the product… but also forcing a constant feedback loop of finding and fixing vulnerabilities continuously. Most regulations including this FDA guidance are light on specifics on how to implement security. This will change as specific types of security hacks become broadly implemented. There will also be a lot of Should requirements that will move to Shall in the regulations as it becomes evident that being more prescriptive is required. For instance, a secure identity requires a private identity be securely stored on the product. If that private key is leaked the device identity is no longer secure. So, how secure you store that private identity key is extremely important. But, at the moment, there are no regulations that spell out a level of security for storing that private key. That will likely change and be very prescriptive as more and more identities are attacked.  So, for medical device manufacturers, they need to realize this is not a “one and done” state of affairs… “Security by Design” will need to be synonymous with “Quality”. And just like quality… security is just a part of the process of making a marketable medical product.

CC: Mike and Silicon Labs are clearly experts in this area, and they have been at the forefront of security innovation in medical devices for many years. So it’s important to work with companies that have the “Security by Design” approach, meaning device makers won’t likely need massive changes to the product themselves, but rather patch updates as new information is released. 

Question: What does this mean for physicians and end users utilizing these medical devices? How can they be best trained to adhere to protocols/what must they consider?

MD: The good news is that the FDA Cyber Guidance should equate to more secure medical devices in a couple of years. The problem is how does the consumer, either clinical or patient, know the device adheres to the guidance and is secure and at what level. This is where the FDA needs to align with the just announced Cyber Trust Mark certification scheme that has been introduced. This program is all about putting a logo on products with a QR code for details that indicates exactly what the security status of that device is in real time.

CC: Cybersecurity training of new devices should be built into required organizational training. And if we’re asking for physicians and downstream “adopters” who already have so much on their plate to take on this responsibility, we must provide them with trustworthy, secure products that don’t themselves create additional vulnerabilities through poor design. Knowing that the medical device landscape has new cybersecurity protocols will certainly make end users more trusting of potentially life-changing digital health products, and I agree with Mike that we should make it as easy as possible for them to know how secure a product actually is. 
There will be some training required for the end users to regularly update these devices, especially in the case of a patch for a security incident. This might draw more attention to the digital divide in the coming years. Manufacturers will really need to consider their end users and the need for reliable high speed internet for these wireless updates.