Does Your Medical Device Submission Adhere to FDA’s Cybersecurity Requirements?

FDA’s bottom line when evaluating a medical device has always been focused on two things: is it safe and is it effective? But the agency has developed a third metric — is it secure? With the full power to enforce the Consolidated Appropriations Act of 2023 (Omnibus), FDA now requires that all submissions prove that they have taken specific measures to ensure cybersecurity.

“And for good reason,” said Naomi Schwartz, Vice President of Services at Medcrypt, in a recent interview with MD+DI. “Not only can the devices themselves affect patient safety and effectiveness, but those devices can become the entry point into a broader hospital network, which can lead to much farther-reaching consequences,” she said, noting the recent malware and ransomware attacks on hospitals. 

“That's going to erode trust in healthcare companies overall, and it can be disruptive to national security,” she explained.

Schwartz strongly advises companies to start improving their cybersecurity now if they haven’t already. “FDA is really taking the gloves off,” she warned. “They are saying ‘We have the authority, we're going to use the authority, we want to see improvement.’” 

In this interview, Schwartz, who was also featured in Season 2, Episode 11 of the Let's Talk Medtech Podcast, explains the Consolidated Appropriations Act, detailing what manufacturers should be doing now to prepare, and what they can expect for future submissions.

Can you give our audience a brief overview perspective of the Consolidated Appropriations Act of 2023 (Omnibus) and the amendment to the Food, Drug, and Cosmetic Act under Section 524B?

Schwartz: What you really have is FDA setting a statutory authority for requesting [cyber] vulnerability monitoring and management, requesting a total product life cycle approach to cybersecurity, and asking for a software bill of materials in a machine-readable format that lists all of the software components in a product, whether they're in the device function or in a connected function that's not a device. All of the software components are in one bill of materials where FDA can ingest that into some kind of viewer and analyze if there are significant vulnerabilities and alert when a new vulnerability is found on high-risk devices that have that affected software. 

What kinds of changes in the approval process have you seen since the Act went into effect?

Schwartz: Between March and October, they did not refuse to accept anybody solely because of cybersecurity, but they did [issue] Refuse-to-Accept [notices] that included cybersecurity, but it wasn't solely for that purpose. And they had started issuing deficiency letters, a lot of them, and many of which contained multiple deficiencies. Numerically large findings under section 524B of the Act are cited, drawing inferences from and predicting the necessity for further risk evaluation solely based on the Guidance related to cybersecurity. 

After October 1 that Guidance has now been pulled from their website because that is now true, and they don't need to warn people about it. They've already started doing it. I believe somebody from FDA said the other day that on average there are 15 cybersecurity deficiencies in the average hold letter and there are more hold letters being issued than ever before for 510(k)s, as an example. 

Now is the time to improve. If you have a submission going into FDA anytime in the near future, go back and check against the Guidance, and use it as a checklist. Ask ‘Should I have told them about this? Is it a requirement under 524B? Is it a recommendation? Does it apply, given the risk profile of my device and its intended use environment and its intended users and its indication for use? And if those things are true, I have to have all the things or most of them, and I need to explain why the things that I say don't apply, really don't apply.’

So, then it would seem like manufacturers might not be that well prepared if FDA is saying that they are seeing more hold letters than ever before. What advice would you give to manufacturers? Are they just not ready for this or maybe they didn't think FDA would be as strict?

Schwartz: Well, there are a couple of components to it. One of them is that some [manufacturers] have said, ‘Oh we keep hearing FDA threatening that they're going to do this, but it hasn't happened before, so it's not going to happen this time.’

That's not true. When FDA has statutory authority for something, they're going to take it as far as they're supposed to. They were given statutory authority by Congress because everybody knows that the posture has not been mature enough. There is a reason that this got put into law. It is because real problems are happening with devices. 

So yes, many of the companies are not adequately mature and their cybersecurity programs are not fully implemented or not correctly implemented or [they] are making pretty common mistakes, but there's also an aspect of company culture to it of ‘well the 510(k) got cleared, so we're not going to change anything until we start getting pushback.’ Well, okay, if that's the way you want to play it, submit something today and find out within 45 days from FDA that you're going to have a laundry list of probably pretty generic deficiencies from FDA saying you didn't follow the Guidance, you're not paying attention to 524B, you missed a whole bunch of stuff. 

How do they fix it? The short answer is to use the Guidance as a checklist. The longer answer is if you are having internal conversations that sound like we all disagree or we're not willing to do it or we're not going to change, ask for outside help. Have somebody come in and do a fairly simplistic audit for you to tell you what your risk is for the timing of your next go-to market. If you want that product on market and within a reasonable timeframe, say less than 180 days, you don't want a deficiency letter full of all the generic stuff that FDA is going to issue you. If that's true, get somebody to come in and help your team convince whoever it is that needs to be convinced to improve your posture. 

Some companies have problems because they have a really diverse portfolio. They need to get a bunch of different groups to all agree about what they're going to do. Maybe they just have to get a bunch of different groups to agree within their own group on what they're going to do. There are lots of different structures within medical device manufacturers, especially big companies versus small, but the bottom line is they have to become mature, and they need to do it now. Nobody is expecting them to be perfect, but they need to have a much more clearly stated explanation for what they are doing and what they plan to do to convince FDA that their device is not only safe and effective now but is also secure.

Image Credit: TU IS via iStock/Getty Images

Do you think following the ESTAR template makes it easier for manufacturers to prove to FDA that their devices are secure? 

Schwartz: The catch with ESTAR is that it's not yet fully implemented with respect to the final Guidance, which the industry is largely aware of. Certainly, advocacy groups like AdvaMed and MDIC are aware of it, and at meetings that they are holding they are reminding everybody ESTAR does not fully implement the final Guidance yet. 

FDA is aware that this is causing concern and they're working on it, but it takes time to get these kinds of templates structurally built and it takes time to implement all of the different changes. ESTAR, as it exists right now, does not adequately frame what's needed. It asks I believe three questions for cybersecurity today, which should allow somebody to understand, ‘Hey, I should be mapping to what's in the Guidance and I should include all this stuff,’ but it doesn't have all the questions that it will soon have and when it does get fully fleshed out, it will make it a little bit more straightforward for manufacturers to realize, ‘oh, there's one document that I didn't attach that I need to have in order to get through.’ 

And so, some companies will probably be able to submit the ESTAR to complete the template but need missing pieces that get caught during a technical review and get them put on automatic hold. That will happen. But people should be following the Guidance in terms of all the documents that they still attach to the ESTAR even if the questions don't totally frame out what's in the guidance yet. They will soon. 

You’ve talked a little bit about the next steps that you would advise a manufacturer to do, such as ask for outside help and have someone come in to do an independent audit to find out vulnerabilities. Are there any other things that you would ask or advise a manufacturer to do?

I would strongly advise all manufacturers today to review the NIST special publication series that talks about cryptography methods because there are a lot of companies that are using legacy algorithms that are deprecated officially by NIST that they should not be using. If they are citing these things, they are going to be put on hold. They are going to need a redesign that may include changing the chipset that they're using that runs their crypto algorithm and engines. They need to get that stuff out of their device designs right now, today, really yesterday, but they should not submit anything to FDA that includes deprecated cryptography at all. They just should not. 

They also should not cite a CRC as their method for integrity check. That's not really what it's for. And if they do that, FDA is not only going to put them on hold for that but they're going to scrutinize other things more deeply because it is an indication of a lack of maturity. The CRC is really not intended for the purpose that some people are citing it for and it's a red flag to the review team. 

What types of services does your company, Medcrypt, provide for manufacturers in addition to these steps?

Schwartz: It depends on where you are in your life cycle. If you're still in design and figuring out what's the right design, we can help in terms of evaluating design and looking for weaknesses. We actually have some products that can be built into the system design that simplifies the cryptography and the management of all of the crypto secrets and manage the trust, which is sort of the fundamental basis of all of your cyber security for your product. 

We do FDA audits, so we will go in and look at something from a ‘is it there, is it not there?’ perspective. Sort of the pre-emptive Refuse-to-Accept review. Or we will go deeper and evaluate for adequacy beyond just ‘can I find it? Do you mention it? But is it really strong enough? Is it good enough, is FDA going to be convinced by what you're doing?’ 

We also offer people an FDA deficiency resolution service, whether it's a hold letter based on technical review of ESTAR equivalent to a Refuse-to-Accept, or a deficiency letter after interactive review, or just interactive review questions themselves, or even posing pre-submission questions to ask FDA for specific feedback. 

We help manufacturers figure out how to respond to FDA questions and how to ask FDA something that will get very specific responses that will help them make decisions. So that's sort of after you’ve first talked to FDA, we can help you figure out how to deal with any problems raised, but before you go to FDA if you're ready to talk about it, and you come to us we can help people prepare for adequacy before they ever get to FDA. That's helpful because that means that the team does not end up scrambling for redesign after submission when they're expecting to try and get to market fast and suddenly their timeline is stretching out. For engineering teams in particular that can be extremely stressful because you may have already been reallocated to a new program and now, you're getting pulled back. 

We want to try and help companies avoid the nuisance and the pressure of a hold letter by having their documentation ducks in a row before they go in. But separate from that, we also look at a company’s quality systems and help manufacturers figure out, ‘should I develop a secure product development in framework, which FDA says is a recommended best practice but not required. How will it help me if I do that? How do I build cybersecurity into my quality system so that every little piece is tightly coupled and makes sense and there's a good flow between complaint-handling processes and evaluation if it's related to cybersecurity, between a root-cause analysis and whether or not there might be a cybersecurity issue, incident response plan in the event that it turns out to be a cyber security issue.’

We have templates for documentation that can help companies figure out what policies, procedures, and best practices they need to implement and where that affects the organization. 

Looking forward to the future, what should medical device manufacturers be routinely doing now to be prepared in the event and probability that FDA becomes even stricter in their cybersecurity requirements?

Schwartz: They are likely to become stricter as they develop maturity within FDA, across the review staff in understanding what looks good and what doesn't look good with cybersecurity. They're going to fine-tune that, too, and it eventually manufacturers should be getting a little bit more specificity in their deficiencies, so they understand exactly what aspect of something FDA is calling out as inadequate, rather than just a generic statement of inadequacy. 

It might be very specific that you're using this particular crypto algorithm and it's deprecated and that's what we have a problem with. It may be broader than that, in which case, there's a bigger problem that needs to be resolved. But fundamentally, people need to review the Guidance. They need to understand the Guidance and they need to accept that the Guidance is not going away. Even if they don't have a cyber device under 524B, they're probably going to be asked to follow the Guidance. It's still a recommendation if it's not a cyber device, but it is intended to scale with risks or if you have a risky non cyber device, you still need to manage your risks and the guidance tells you how to do it. But fundamentally, follow the Guidance. 

Secondly, I strongly urge people to use standards because standards have been discussed broadly by a bunch of stakeholders who know what they're talking about, including FDA. And the standards are intended to help people to do the right thing. It's harder to describe your methodology if you're not following something commonly understood. 

Schwartz ended by saying that Medcrypt experts are here to help. “That's the whole point of our company's existence. We live and breathe and eat cybersecurity for breakfast, lunch, and dinner because we believe in the mission.”