FDA Cybersecurity Gets Real with Monica Montañez of NAMSA | Ep. 30

Hi, welcome back to the Med Device Cyber Podcast. Today we're going to be talking with NAMSA about medical device cybersecurity, specifically SAMD, AI, ML, and some of the challenges with cybersecurity that a lot of manufacturers are facing since the changes in September of 2023. Today we have with us Monica Montinez from NAMSA, and we also have our co-host, Trevor. Not too bad. Great. Alright, we've got Trevor's in Sedona, Arizona, and Monica is in Colorado. So, you want to start us off a little bit, Monica, with a quick overview of NAMSA and how you feel cybersecurity evolved since your time in the industry? NAMSA represents North American Scientific Associates, and we are a CRO company that also offers consulting services for regulatory and quality, including preclinical animal studies, for example, any kind of process sterilization, biocompatibility testing. We offer a whole array of different opportunities to support your product development process. Okay. And are most of your clients like startups or larger or midsize manufacturers, would you say? I'd say most of our clients are midsize. We do have several large companies that we work with, multinational companies that we offer our services to. And then when it relates to Software as a Medical Device, for example, SAMD devices, there's a lot of startups in those in that area. Yeah, we've noticed a big trend with AI-enabled softwares in medical devices, or a lot of people say it's AI-enabled. I think to get funding from investors when there's really no AI in it, but they kind of make it look like there's AI to get funding because today if AI is a topic or stamped on something, everybody seems interested from my experience. True. True. Yeah. Reimbursement is also a challenge for Software as a Medical Device, so we offer reimbursement services as well. One of the things that they really should consider and we talk a lot about. So that's kind of helping them with the overall product commercialization and roadmap as well as commercialization of the product itself. You want to make sure you can sell it, for sure. I think a lot of people kind of skip that part, just assuming that's going to work out. But there are challenges, like you said, if you can't get a reimbursement, you may not be able to sell it because nobody will want to bring that device into their HDO. Cool. And you've got a background in regulatory affairs and quite a few other areas specific to MedTech. From your experience in the industry, how has cybersecurity evolved or has it devolved? No, it's certainly evolved. Prior to 2023, cybersecurity was basically governed by FDA guidance documents that FDA could recommend certain areas related to cybersecurity. Sponsors, manufacturers were not required to design cybersecurity requirements within their product development process. So a lot of the cybersecurity requirements were mostly if driven, you know, instructions for use, what you can and can't do, password protection, authentication. The basic kind of cybersecurity requirements were just offered at that time. And then when there were so many issues with cybersecurity taking place with devices over a period of time in the early 2000s, it became an issue with Congress. Congress finally passed a bill, legislation, which is called the Fedora, and it made a change to the Food and Drug and Cosmetic Act, and actually made cybersecurity a part of the legislation. It's now where FDA can carry the big stick. FDA can basically say you have to comply with cybersecurity. Yeah. Trevor, what is your interpretation of that? Because I know you're super familiar with the guidance. And from my experiences, the FDA, they make a lot of recommendations, but they don't sound mandatory, but then the recommendations are actually mandates. It seems like it's very vague and frustrating for manufacturers. What's your take on this, Trevor? And I'm not super familiar with Fedora, actually, so that might be something. I don't know how familiar you are as well, Trevor, but we can dig into that a little bit. It's something I hear all the time from manufacturers is, oh, well, it's recommended that we do our threat modeling, but is it required? And reading the FDA guidance everywhere, it says, we recommend you do threat modeling. We recommend you do penetration testing. We recommend you do requirements testing. And if you submit your 510k or your PMA or whatever submission without it, the FDA is going to come back and say, you know, this is insufficient. You did not cover cybersecurity. You did not do threat modeling. You did not do your penetration testing. You did not meet the requirements. So it's one of the many, many areas where it's worded in a little bit of a vague way that I feel like manufacturers who are new to the space are going to get a little bit caught up on. So a lot of startups will have issues with that. Once a company's been putting out several devices, they're used to the guidance, they're going to know what to expect. But as far as a newer company, this might be a little bit of a shock to them. Even down to the definition of a cyber device on the FDA's website seems very inconsistent with what they actually enforce as a cyber device. One of the requirements is it says it has to connect to the internet. And we work with so many devices that do not connect to the internet that, you know, the companies come to us for deficiency response because they didn't think they were a cyber device. They submitted to the FDA. The FDA kicked them back for not addressing cybersecurity. So it's a little bit more of a do as I do, not as I say kind of thing, which is kind of the inverse of the ordinary. But yeah, it's something that I feel like manufacturers are going to get more and more used to, but for now, it's still in a little bit of a new, unknown state. Yeah. I don't know. I think it's a little bit frustrating. Like you said, things are recommended, but they're actually required and it's very ambiguous. And I'm not sure the rationale for that, but like you were saying, Monica, it's actually law that people do certain things, but then the FDA guidance is not written as it's like mandated. But yet they have things like an RTA refusal, or refuse to accept, you know, even a submission because it doesn't have cybersecurity as part of it. So it's like a little bit of conflicting information there. Well, I do want to add something here because I'm looking at the definition, and the definition of a cyber device means that it's software, number one. It includes software that's validated, installed, or authorized by a sponsor as a device or in a device. And Trevor, to your point, FDA does say it has the ability to connect to the Internet. Now, that's kind of a gray area, right? But that's a key. That's a key term, internet connectivity. So what's the definition of a cyber device? You need to look at the FDA guidance document. And I point this out to a lot of my clients. This includes software that has firmware or programmable logic. It also includes software that has the ability to connect. Even hardware has the ability to connect to the internet through Wi-Fi, through cellular, through a network server, could be even a cloud service provider. If you have Bluetooth, Bluetooth Low Energy, and if you have radio frequency communications, inductive communications, and if you have USB or an Ethernet or a serial port, that's still termed as a cyber device. It has the ability to connect to the internet. So that's what FDA is implying here. So, I know Trevor and I have had this internal debate a little bit. And we actually have a client we're doing some testing on. They have a device. I believe it's an implantable. I'm not exactly, I don't remember, but it had Bluetooth enabled, Bluetooth Low Energy. They disabled it, so we're testing it to make sure it stayed disabled, but it's got a lot of software in the device. But according to the, and we've seen this conflicting on the FDA website, it says these, this or this or this. The definition you just read is this and this and this. So all three conditions need to exist. And from my perspective with this device, even though it has software, if we can prove there's no interfaces that are enabled, no connectivity to anything, then technically it would not fall under the definition if we're using the and this and this. Yeah. And I didn't actually mention the last item, which was contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. So, I mean, all three of those areas within that definition makes up the definition of a cyber device. So that's where FDA is going with their evaluation. Even if your device doesn't seem to have that capability, or you've turned off those capabilities, could it be a person, any other method, someone else could turn on your device for whatever reason? Yeah. And with the device that Christian was giving an example of, it has the hardware to connect to the internet. Technically, it has a Bluetooth interface on the device. It has the chips in the product so that it can have that functionality. And so even if it's disabled, there is still a level of risk. What if there's a problem at the manufacturing level? What if they ship some devices out with Bluetooth enabled? And what if it's unsecured? For a device like an implantable, those are typically going to be Class 3, very high-risk products. And if something goes wrong in that regard, it can potentially mean the loss of a patient's life. So, I understand where the FDA is coming from and it's still certainly a bit of an ambiguous definition. And I feel like, you know, Christian and I go back and forth on it all the time. We go back and forth on it all the time with our different clients and, you know, even on the internal team. But in general, yeah, connecting to the network can be done in so many more ways than I think people are aware of when they see internet connectivity. A lot of manufacturers say, "Well, I don't have Wi-Fi or Ethernet, so I'm good." But, you know, you brought up a great point, USB that can connect to the internet. You can connect to the internet over Bluetooth. We've even seen considerations around RFID tags on a device because there is a way and we found some pretty nasty problems against RFID tags on devices where they don't, the device doesn't have any other form of connectivity, but we're able to essentially compromise a device and introduce dangerous situations through manipulated RFID chips. So, the FDA is, I don't think that they're wrong at all in casting a wide net for defining what a cyber device is. I feel like just the definition that's posted on the website's a little bit ambiguous and leave some OEMs up to a bit of confusion. Right. I can see your point, especially with startups and people who are not familiar with the definition or what FDA's regulations require. So it is a kind of a catch-22 for them. So I know Trevor, you tend to lean on, I think it's probably a more conservative approach. Any Class 2 or Class 3 device that has software, we would consider something we need cybersecurity testing done. Because otherwise, if you technically don't classify it as a cyber device, you may not even do a Software Bill of Materials. You may not even know what software makes up your device. Is that fair to say? And I think that a conservative approach is a very safe way to go when it comes to a regulatory submission. But if we're looking at a device, you know, it's essentially just an air-gapped machine. There's nothing going on with it. There's no way to interface with anything, probably not doing too much as a product. And so you'll see like a thermometer that is usually not going to branch into Class 2 or Class 3. That can run software on the inside, but it's going to be very, very low risk. There are likely no interfaces with it. When we're moving into, you know, a moderate to high-risk product, it's just very unlikely that there isn't some way to interact with it. Even if we're talking about an implantable device, usually those have some form of connectivity, whether that's RFID, that's Bluetooth, NFC. Otherwise, you're going to have to essentially redo an operation to interact with the product. And so when we're seeing a software-enabled Class 2 or Class 3 device, it's very unlikely that it is not going to be a cyber device. Even if the hardware is disabled, the hardware is still present. And we see that a lot, you know, with that example we were just talking about. This is a high-risk device with technically no interfaces, but it does have the capability for interfaces. And so that's when the definition gets a little bit blurred there. Well, we've also seen clients that have practically sworn to us that Bluetooth is disabled and RFID is disabled. Then we test their device, the device they're trying to get approved, and those things are actually turned on. So, I think like from a hardware perspective, if those things are built into the hardware, I think it's extremely important to do what we call negative testing to validate that they're actually disabled and disabled properly, because some people have disabled them but not in a secure manner either. And we see that at an honestly unbelievable rate and a very, very high percentage of devices have unintended interfaces. We reach out to the OEM and we say, you know, we were testing your device and we saw that Wi-Fi is enabled. Did you mean to do that? And we get, oh no, we forgot to turn it off on that one. That's, you know, that's our bad. We go, okay, well, you got to make sure it's turned off on all of them, too, not just this one. But it's very, very common. And, you know, cybersecurity is not necessarily at the front of everyone's mind when they're going through this process, which is not a great thing, but developers aren't innately cybersecurity aware in most cases in our experience. And so what we wanted to see is considerations like this brought up a bit more early. If you're taking an off-the-shelf piece of equipment, like if a manufacturer is deploying something on a phone, this phone obviously it can connect to Wi-Fi, it can connect to Bluetooth, it has a little RFID scanner in the back, has a USB port. And a lot of that, let's say they're only using the USB port, everything else will just fall on the back burner. Nobody's going to consider what's going on with that. Well, what if someone compromises the phone over Wi-Fi, even though you're not using Wi-Fi for the intended function of your product, that's still a way to damage the product. And so, you know, the same can apply for an off-the-shelf computer, which is very common in medical devices. And it's just something that needs to be a little bit more at the front of mind and addressed a little bit more often. And then I feel like we're not going to run into all these issues with unintended interfaces on products. Monica, from your experience, do you think cybersecurity, like I mean, it's well-established you need sterility, biocompatibility, all these sorts of things done. Do you feel like people are caught off guard that they also need cybersecurity done now, or like what is the challenge? Because people wait to come to us until like 60 days before submission. They never considered cybersecurity till their RA said, hey, EAR is asking about this cybersecurity stuff. What have you done about it? They're like, I don't know, nothing. So, since the cybersecurity law went into the regulations in 2023, most definitely everyone's caught off guard related to cybersecurity. They're so used to not having to design cybersecurity into their product. And to your point, Trevor, they're having issues understanding what the guidance document means in guiding them and understanding cybersecurity. For example, you know, now you've got to have a security risk management report, a threat model, which in the past you had a threat model. We always started with a threat model. Vulnerability and assets, cybersecurity risk assessment. You need to have third-party component level support and vulnerability assessments. Security assessment of unresolved software anomalies, that's another new one. And then, of course, now you have to have total product life cycle measures and metrics available in your submission. Cybersecurity controls, it's connected more closely to your Software Development Life Cycle with your architectural views and cybersecurity testing and labeling. So it's quite a number of elements of deliverables that are required now for cybersecurity compared to what it was before. In previous submissions, you had one question related to cybersecurity, maybe two attachments, and now you have nine questions and 12 attachments that's required in your FDA submission. So, yeah, there's a lot that's changed and a lot of my clients are very caught off guard. Yeah, even it doesn't seem like a lot saying we have nine questions and 12 attachments, but oftentimes when we're preparing cybersecurity documentation for a 510k, it can branch up to 500 pages plus of documentation. There's a lot that goes into it. When we're looking at the cybersecurity controls, cybersecurity controls are covering a few key areas: authentication, authorization, cryptography, event detection and logging, integrity. There are a couple more, but I think there are eight in total. And each one of those you need to go into detail on every single aspect of the device. And so authentication, usually you think of that as, you know, signing into your email, username and password. But how do different parts of the device authenticate to each other? How do you ensure that that cloud server hasn't been tampered with and the device is going to an intended destination? All of this stuff has to be controlled and documented and it gets very lengthy very, very quickly. And so a lot of manufacturers, I think they'll even see, you know, oh, we have nine questions, and they'll essentially just prepare a little one-page tear-out for everything and then the FDA says, not good enough. Come back when you have more. And they say, well, more what? How do we get this more? And, you know, the cybersecurity guidance, I think it should be called the cybersecurity mandate, but that's another conversation, is a little bit vague as far as what's actually enforced. And they say cybersecurity should scale with the complexity of your device. And what does that mean if you're not if you're not interacting with hundreds of devices and so you don't understand the varying complexity, how do you know where you fall is enough in that regard? That's a good question. Actually, we're talking about a Class 3 medical device implantable. That's a high-risk device. If that device were ever tampered with from a cybersecurity perspective, it could most likely impact the patient, right? Patient death is the worst case scenario. I think cybersecurity is strongly attached to your decision-making process related to your software. FDA also released a new update to software functions, software development, what's required in your premarket submission for software. And now the level of documentation coincides with the risk of your device, and the risk of your device also coincides with the cybersecurity risks. So all three of those elements should be considered when you're developing, designing, and developing a device that has cybersecurity and software. The other key element that's really, really important is, as I mentioned before, your security risk management process, your cyber risk assessment, and your risk assessment with your software functions according to ISO 14971. All of those play into how much information you need to provide to FDA for cybersecurity. We touched on a couple things. Like one of them is what the FDA refers to as a Secure Product Development Framework or the SPDF, or basically secure software development. And from my experience, which is like 30 years in cybersecurity, I feel like the needle has not moved very much with teaching software developers how to do secure software development. And I know the FDA requires it, but we still, and I know it's just required in September 2023, but we still see even contract software development organizations that do not even come close to secure software development. And they're being contracted for their expertise by a MedTech innovator. And it's always surprising to me because sometimes they want to partner with us, the software development company, but I'm like, I'm not sure I really want to partner if I am not sure that you developed secure software. I know there's some standards that I see a few companies are starting to follow. I think it's ISO, what is it? 62304. It seems like a few companies now are starting to like follow that but there's still not that many. That standard's been around for quite a long time and it did require a risk assessment for security. You know that's one of the requirements in software development under IEC 62304. What did change and what a lot of these software development or VNV companies may not have understood clearly is FDA changed the guidance document. The guidance document for software development and the requirements for premarket software functions was actually introduced I think in 2022. Don't correct me if I'm wrong, but that particular guidance document changed on how you're supposed to develop your software and test it. It is a process that your company would need to implement to complement your design control process. 62304 has been around for quite some time. Since 2015, I think was the last time it was updated, maybe an amendment to it. But what companies who are in the software development area of expertise really needs to understand the FDA guidance document, content of premarket submissions for device software functions. So it's not just following 62304. You also have to understand that's a baseline, but then you have to look at the content for the premarket submission as well and do both. Yeah, you have to look at that particular guidance document for your submission if you plan to submit software information about your device and it contains software to FDA in a premarket submission. This is a must. 62304 is a process for design control for designing your software. It doesn't necessarily identify all the deliverables that are needed in your submission to FDA. It just tells you what you need to have in place when that FDA inspector comes to your facility and you claim if you claim compliance to that to that standard, then they're going to expect that you're going to have all of those elements within that standard implemented within your software development process at your company. So Trevor, what is your experience with IEC 62304? And companies like, out of a sample of, you know, all of our clients and the software development teams they use, how many of those would you say actually follow 62304? It's definitely in the lower percentages there. I think single digits, should we talk about, or what are we talking about? I would say double digits, but between 10 and 20%. It's a pretty thin number. A lot of what we see for a contract developer like an NRE is 13485 compliance. And so that's quality system within medical devices. So they're preparing the software documentation but not necessarily the cybersecurity artifacts. And I think part of the reason for that is that software documentation has been a standardized process really since the '90s. It's nothing new and a lot of manufacturers and developers are very used to it. So preparing good software documentation is a commonplace practice. Having said that, I think that cybersecurity controls and cybersecurity documentation are evidence of good software and should not be treated as something separate. But cybersecurity in general is just a newer industry and it's, I think, growing into maturity but not there yet. So developers, NREs, manufacturers are all still getting caught up and I think that we're getting there. You know, hopefully within 5 or 10 years, cybersecurity will start to be as mature as software. But for right now, I still think it's a bit too new. I mean, you know, we talk about what was required before 2023 and a lot of manufacturers say, "Yeah, I just filled out this little checklist on a spreadsheet, sent it to the FDA, and they said we're good to go." And now obviously that's not the case. And so having artifacts prepared from something like 62304 or 81,001-5-1, the standards are not new, but the enforcement around the standards is new. Awesome. Well, I think we're coming up on time here. We are coming up on time. So, I'd like to ask for any last words of wisdom. I'll ask you first, Trevor. Any departing words? I think don't listen exactly verbatim to the FDA's guidance. It's not it's not a recommendation. It's a requirement. You have to do it. And a cyber device can have a broader definition than you think. If there's some possibility of connecting to the internet, it's going to fit that definition. And what the FDA recommends that you do, you have to do, otherwise they're going to recommend a little more strongly that you do it. Awesome. What about you, Monica? Any last words of wisdom for us? Well, I think manufacturers and developers need to follow the law, which is now the law is cybersecurity with FDA. The guidance document helps you understand the law. And I think I always tell my clients to take a look at that guidance document and follow the guidance document to the letter if you can. And if you don't understand what it means, that's what I'm here for, for you to reach out and educate you on the understanding of what FDA is looking for. I get a lot of feedback from FDA through clients trying to navigate this cybersecurity environment that we live in today. And the feedback that I receive from presubmissions and actual submissions is very informative and it really helps me guide the client in understanding what those deliverables are and how to understand how you can navigate what kind of testing you need to have and what kind of how you can establish your rationale for certain types of testing or requirements that are not needed based on what your device offers. Awesome. Well, thanks so much and thanks for being a guest on the Med Device Cyber Podcast, Monica. We appreciate your time and thanks everyone for tuning in. We hope to see you on the next episode.