BLACKJACK3D / ISTOCK / GETTY IMAGES PLUS VIA GETTY IMAGES

FDA is cracking down on medical device cybersecurity. In response to an increase in healthcare cybersecurity threats, prevalence of connected devices, and pressure from the United States Government Accountability Office (GAO), the agency issued final guidance on medical device quality system and premarket submission requirements. In March, FDA released an update to clarify what devices must comply, as well as to give more specifics on the proposed cybersecurity plan.

To get a handle on the new requirements, we caught up with Kristina Haysmer, director of strategic business development for Accorto Regulatory Solutions; and Rafael Rubio, president at Net Medical. They discussed the urgency of the requirements, the devices impacted, and the best first steps device companies can take to secure their devices and prepare compliant cybersecurity plans.

According to a HIPAA Journal report, since 2018, the healthcare industry has seen a 239% increase in hacking-related data breaches and a 278% increase in ransomware attacks. Given most of these breaches appear to originate with payers or other sources of medical records, what’s the concern for connected medical devices?

Haysmer: It’s all part of a bigger picture. In a hospital setting, any potential vulnerability in any piece of the connected network can lead to a bigger breach of the larger system. Any connected medical device that has not taken the proper precautions to address cyber security risks can be a point of vulnerability and provide a potential entry point for an attack on the larger interconnected network it is a part of. With the widespread adoption of connected medical devices, the potential attack surface for cybercriminals has only continued to increase.

While the device itself may not be of significant concern when it comes to the data that specific device is collecting and transferring, the greater interconnected network it could be used to access should always be considered when developing the overall risk management plan for that device. If your device talks on a network, it uses software libraries that need to be held accountable for providing an attack surface for bad actors. If you use networked software in your medical device then those libraries belong in your risk management plan as a cybersecurity risk.

Rubio: If you’re thinking like an attacker, you don’t care what the target system is. You’re just trying to get an attack vector, if you will, into something that you don’t have access to. And if you get to, say, a records management system, then you’ve hit a trove of data. If you can get through the network and get to a medical device, you’re presenting actual patient risk.

So even though medical devices in general run in well-protected networks, there is a core vulnerability that could exist in the device that makes it a risk to the patient. That’s what FDA is looking at.

What are you seeing in terms of medical device cybersecurity issues?

Rubio: The attacks are becoming more sophisticated. The people responsible for securing the devices are always playing catch up against a world where the bad actors are incredibly sophisticated. The people writing the software may not see things the same way a cybersecurity analyst would, so it’s hard to bake in cybersecurity at the beginning without support.

On the regulatory side, FDA has become the first agency to really do a heavy lift in cybersecurity. They’ve left a roadmap for device manufacturers. They’re going to need experts in the field to help move that process along.

FDA finalized guidance in September 2023. More recently, FDA issued another draft guidance with updates. What should medical device companies follow?

Haysmer: Medical device manufacturers should consider both documents when developing new products and preparing regulatory applications for submission. The 2024 document should be viewed as an addition to the original document rather than a replacement, with the update providing additional information to clarify points from the 2023 guidance such as adding a Section VII on dyber Devices and giving examples to aid in overall understanding. From our perspective, the core message remains the same: proper cybersecurity is critical in reducing patient risk and must be handled inside of QSR-820 (21 CFR Part 820 – Quality System Regulation) for medical devices.

Those familiar with the SaMD regulations should find there are no surprises in this guidance; all components that can affect patient care are a part of the device and are within FDA’s authority to regulate even if they work over a network. Once you get a handle on that idea, then the requirement for a cybersecurity management plan for both premarket and postmarket commitments falls into place. Then it’s down to implementation.

The update gives a more detailed explanation of what FDA considers a cyber device. The definition goes beyond devices that connect — or could connect — to the internet. Would you explain?

Rubio: Any software component that sends data to another component now qualifies as a cyber device. That includes via the internet, Wi-Fi, and Bluetooth, but also radio transmissions. They include any situation where data leaves one device and goes to another.

I suspect one reason they wrote the definition like this was so there’s no wiggle room for device manufacturers to make the argument that their products are not, in fact, cyber devices, in an attempt to avoid the regulation.

Late last year, a representative from Medcrypt told MD+DI that FDA was seeing around 15 cybersecurity deficiencies in the average hold letter, and that there are more hold letters being issued than ever before. What changes are you seeing in the approval process now that the guidance is finalized (absent a few updates)?

Haysmer: Cybersecurity is front of mind for the agency of right now. They’re going to be putting particular focus on that part of the plan when they’re reviewing regulatory applications for market approval. Now that they’ve published the framework, they’re going to be especially adamant on reviewing these criteria and making sure companies are complying with their requests.

Premarket and post-market cybersecurity plans need to consider risk analysis and threat models for all stages of the total product lifecycle (TPLC), meet the agency’s current thinking — which is continuously evolving, all while communicating those plans in a way that can be clearly understood from the outside. It’s understandable why we are seeing so many roadblocks in the regulatory approval process. However, there are ways to reduce and even eliminate some of these challenges.

It’s going to be important for device companies to interact with the agency early in the product development process, to get a hold on their current thinking as they’re developing cybersecurity plans and risk assessments.

We push our clients to use the Q Submission Program as early in the process as possible, so we can understand FDA’s thinking and nail down that roadmap for a successful submission. That way, we’re not coming back to the table when we could have answered those questions early in the process.

How else can medical device companies prepare for these new requirements?

Haysmer: We highly recommend partnering with regulatory and cybersecurity experts early in the process and making them a part of your product development team. These experts will coordinate with your developers and FDA to address risks and vulnerabilities early on, ensuring proper documentation is gathered at every stage. As the agency’s thinking evolves, having regulatory experts who are up to date on the latest requirements will help streamline the regulatory review process and expedite your path to market.

Rubio: Have your software developers create a Software Bill of Materials. The FDA is a data-driven organization. When you have a Software Bill of Materials, you’re taking stock of what software components you have, what versions your developers have, and what you know about the vulnerabilities in those software components.

In asking for a Software Bill of Materials from your development team or from your external developers, you’re getting them ready for what they’re going to need to do from here on out. There are a lot of libraries that these programmers draw from to make new interfaces. But all those libraries have dependencies, and all those dependencies have to be checked. All of that is data, which is what FDA is really going to sink their teeth into — the actual data of what the vulnerabilities are.

As part of your plan, you also have to have a map to look at the threat model to look at what your cyber risk is from the outside and then work to make sure your plan is compatible with what you’ve done for your quality system. If you take an actual threat, and work it through the process you can get from start to finish like you could with any patient risk item that you’ve got in your risk matrix and your hazard analysis.

If you can do those things, you’re well on your way to being able to answer what FDA is going to ask. But you’re going to need help. Get an expert who has done this in the past and gotten their hands dirty and understands it because cybersecurity as a patient risk is real and it’s also very difficult.

What recommendations do you have for developers/manufacturers of legacy devices, which are considered vulnerable to cyber incidents?

Rubio: I would try to get a handle on what the current risk is now from a software library perspective. Go back to the legacy developers and see if they can produce an SBOM. Even if they can’t produce a proper SBOM, try and get as many software dependencies and version numbers as you can. Then, do the homework. Get some experts to show you critical flaws and what your options are. You might only be a few downloads and a recompile away from staying viable.

FDA, in collaboration with other agencies, appears to be acting assertively on this topic. What’s the cost of compliance vs noncompliance?

Haysmer: The biggest thing to look at is: ‘do you want to get or keep your products on the market?’ Given the current regulatory landscape, you have a very real possibility of getting a Refuse to Accept, or RTA, for an application that does not have a thorough cybersecurity plan laid out.

You’re either paying to make your products compliant or you won’t have a product to sell in the US. That cost is much larger in the grand scheme of things.

For companies that already have their products on the market, noncompliance could lead to their products no longer matching up with their predicate. In the newest guidance, they offered an example where if the cybersecurity updates of your predicate no longer match your product, your product would no longer be able to be legally marketed in the US.

Haysmer will be speaking on this topic in the session “Cost of Connectivity: Managing the Evolving Landscape of Cybersecurity Regulations” at MEDevice Boston, on Thursday, Sept. 6, at 9 a.m.

Additional Resources:

Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. FDA Final Guidance Document

Select Updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act. FDA Draft Guidance Document

Next Steps Toward Managing Legacy Medical Device Cybersecurity Risks. FDA with MITRE

Article Source: Heather R. Johnson