By Mike Kijewski, Medcrypt CEO
On September 26, 2023, the FDA released their finalized Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions guidance document. This follows a draft guidance in 2018, and an updated draft in 2022, and supersedes the 2014 final premarket guidance.
The 2023 Final Guidance does not stray far from the 2022 draft. Many expected changes were made, but the Final Guidance does add clarity in many areas that were open to interpretation in the prior draft. Coincidentally, these clarifications address some frequent objections we at Medcrypt hear from medical device manufacturers about why the FDA’s Cybersecurity considerations may not apply to them.
Here are a few common misconceptions about the FDA’s position on cybersecurity, and the language from the Final Guidance that dispels them:
1) “My device isn’t connected to the internet, therefore these cybersecurity rules don’t apply.”
The draft guidance specified that these rules apply to Cyber Devices, then defined the types of “cyber devices” with pretty all-encompassing parameters.
“This guidance document is applicable to devices with cybersecurity considerations, including but not limited to devices that have a device software function or that contain software (including firmware) or programmable logic. The guidance is not limited to devices that are network-enabled or contain other connected capabilities.”
For example, if your device is a stand-alone Windows box that sits inside a hospital, it is held to the standards described in the guidance, despite it not having an internet connection.
More info on page 2, “Scope” section in the Final Guidance.
2) “Yes there is a way for this device to be hacked, but the probability of it happening is very low due to $reasons, so we don’t need to put a security control in place.”
Many MDMs have looked at their devices and asked “Why would someone actually want to hack this thing?”, or stated “it’s hackable, but you’d need to be within 60 feet in order to exploit the vulnerability”. These sound like reasonable justifications for deprioritizing a cybersecurity control. But the new guidance makes it very clear that MDMs can not merely rely on an estimate of probability of exploit in order to assess risk:
“Accordingly, cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling (also known as a “probabilistic manner”). Instead, security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system.“
This means that MDMs should focus on assessing the potential of a vulnerability to be exploited and putting in place controls for attacks that could happen, as opposed to relying on however unlikely they may be to happen based on past experience.
3) “The operating system / cloud environment / protocol we’re using has security built in, so we don’t need any additional security”
We frequently hear device manufacturers rely on the security that comes in a communication protocol, like Bluetooth, to satisfy their cybersecurity requirements. But the Final Guidance highlights the best practice of a Defense In Depth strategy, which may leverage layers of security above or below your transport layer:
“When common technology and communication protocols are used to enable interoperability (e.g., Bluetooth, Bluetooth Low Energy, network protocols), device manufacturers should assess whether added security controls beneath such communication are needed to ensure the safety and effectiveness of the device (e.g., added security controls beneath Bluetooth Low Energy to protect against risks if vulnerabilities in the Bluetooth Low Energy protocol or supporting technology are discovered).”
It’s not surprising to see FDA call out Bluetooth specifically, as there have been a handful of vulnerabilities in that technology that were not patchable without a hardware upgrade, which is obviously problematic for an expensive medical device that is designed to be used for many years or is implanted.
4) Finally, “We had a security issue, but we put a firewall in front of the device, so now we’re good.”
Perhaps unsurprisingly, the Premarket Guidance is highlighting the difficulty of retrofitting security controls onto an existing device, and encouraging device manufacturers to build features in from the start:
“Effective cybersecurity relies upon security being “built in” to a device, and not “bolted on” after the device is designed.“ and “… hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network …”
In summary, the updated Premarket Cybersecurity Guidance is surprising only in the degree to which it emphasizes the strategy they’ve outlined in their 2018 and 2022 drafts; design features into your medical device that allow your device to protect, detect, respond, recover from cybersecurity threats.
If you’ve read this far, and have found this helpful, I’d love to talk to you about how Medcrypt can help you understand your product security responsibilities, and develop a plan to exceed the FDA’s requirements. My co-founders and I started Medcrypt in 2016 in order to help MedTech companies build products that are secure by design. We live and breathe medical device cybersecurity, and would love to help however we can.
Register for Medcrypt’s upcoming webinar, “Unpacking FDA Guidance: Quality System Considerations and Content of Premarket Submissions” on October 12, 2023 at 11:00 AM PT/2:00 PM ET.
Join today for free. Register here.
.png)
