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

In this episode of the Med Device Cyber Podcast, host Christian Espinosa and co-host Trevor Slattery are joined by Monica Montanez from NAMSA (North American Scientific Associates) to discuss the evolving landscape of medical device cybersecurity. The conversation centers on the significant changes manufacturers face following the updated FDA regulations effective September 2023. Monica introduces NAMSA as a Contract Research Organization (CRO) that provides comprehensive consulting services for medical device manufacturers, covering everything from regulatory and quality assurance to pre-clinical studies, biocompatibility testing, and product commercialization strategies. She notes that while NAMSA serves a range of clients from startups to large multinational corporations, many startups in the Software as a Medical Device (SaMD) and AI/ML space are particularly impacted by the new cybersecurity mandates. The core of the discussion revolves around the transition of FDA cybersecurity guidelines from recommendations to enforceable laws. Monica explains that prior to the Food and Drug Omnibus Reform Act of 2022 (FDORA), the FDA could only suggest cybersecurity measures. Now, the agency has the legal authority to reject submissions—a "Refuse to Accept" (RTA) action—if cybersecurity is not adequately addressed. This shift has caught many manufacturers off-guard, as they are now required to provide extensive documentation, including security risk management reports, threat models, and vulnerability assessments, which were not strictly enforced before. The hosts and guest explore the ambiguity in FDA guidance, which often uses the term "recommend" for what are now de facto requirements. This vague language has created confusion, especially for new and small-scale manufacturers who may not have dedicated cybersecurity expertise. A key point of contention is the broad definition of a "cyber device." The panel clarifies that this term applies not just to devices with direct internet connectivity like Wi-Fi or Ethernet, but to any device that has the *ability* to connect to a network. This includes devices with USB ports, Bluetooth (even Bluetooth Low Energy), and RFID capabilities. Trevor Slattery highlights a common pitfall where manufacturers disable a feature like Bluetooth but fail to prove it is securely disabled, leaving the hardware present and vulnerable. Such oversights, often discovered during testing, are a frequent cause of submission delays. The podcast emphasizes that cybersecurity must be integrated into the entire product development lifecycle, similar to sterility and biocompatibility, rather than being treated as a final checklist item before submission. The discussion concludes that manufacturers must proactively adopt a secure software development framework to meet these stringent new standards and avoid costly regulatory setbacks.

Host: Hi, welcome back to the Med Device Cyber podcast. Today we're going to talk we're going to be talking with Namsa about medical device cyber security, specifically Sam D, AI ML and some of the challenges with cyber security that a lot of manufacturers are facing since the changes in September of 2023. Host: Today we have with us Monica Montanez from Namsa and we also have our co-host Trevor. Uh how's everyone doing this morning? Trevor: Not too bad. Monica: Great. Host: All right, we've got Trevor's in uh Sedona, Arizona. I'm in Tempe and Monica is in Colorado. Host: See you want to start us off a little bit Monica with a little quick overview of Namsa and kind of what how you feel cyber security's evolved since uh your time in the industry. Monica: Namsa represents North American scientific associates and uh we are a CRO um company that uh also offers consulting services for regulatory and quality including pre clinical animal studies for example, any kind of process, sterlization, uh biocompatibility testing. Uh we we offer a whole ray of different opportunities to support your your product development process. Host: Okay, and are most of your clients um like startups or larger or you know mid-sized manufacturers would you say. Monica: I'd say most of our clients are are mid-sized. We do offer, 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. Host: Yeah, we've noticed a big trend with AI enabled software as a medical device 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 if AI is a topic or on stamped on something, everybody seems interested for my experience. Monica: True, true. Yeah, um, you know, reimbursement is also a challenge for for software as a medical device. So we offer reimbursement services too as well. one of the things that they really should consider and we talk a lot about. Host: So that's the uh kind of helping them with the overall product uh commercialization and roadmap as well. Monica: commercialization of the product itself. You want to make sure you can sell it. Host: For sure, I think a lot of people kind of skip that part just assuming that's going to work out, but there's the 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. Host: Cool. And you've you've got a background in regulatory affairs and quite a few other areas specific to MedTech. Uh from your experience, how has in your experience in the industry, how has cyber security evolved? Or has it developed? Monica: No, it's it's certainly evolved. Um, you know, prior to 2023, cyber security was basically governed by uh FDA guidance documents that FDA couldn't basically could uh recommend certain areas related to cyber security. Uh sponsors, manufacturers were not required to design cyber security requirements within their product development process. Monica: So a lot of the cyber security requirements were mostly uh IFU driven, you know, instructions for use, what you can can't do, um, password protection, authentication, the basic um kind of uh cyber security requirements were were just offered at that time and then when there were so many issues with cyber security taking place um with with uh devices over the a period of time in the early 2000s, um it it became an issue with Congress. Congress finally passed a bill legislation which is called the Fedora, which is called Fedora and it made a change to uh the Food and Drug and Cosmetic Act and actually made cyber security a part of the legislation. It's now where FDA can carry the big stick. FDA can basically say you have to comply with cyber security. Host: Yeah, Trevor what is your interpretation of that because I know you're super familiar with the guidance um and the FDA the FDA from my experience is they they make a lot of recommendations but they don't sound mandatory, but then the recommendation is actually mandate, it seems like it's very vague and and frustrating for manufacturers. What do what's your take on this Trevor? Are you 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, if we can dig in in that a little bit. Trevor: 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? Trevor: 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 said and say, you know, this is insufficient, you did not cover cyber security, 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 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. Trevor: 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 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 it to the FDA. The FDA kicked them back for not addressing cyber security. 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 a it's 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. Host: Yeah, I I um 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. Um and I'm not sure the the rationale for that, but like you were saying Monica is actually uh 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 or refused refused to accept, you know, even a submission because it doesn't have cyber security as part of it. So it's like a little bit of um conflicting information there. Monica: Well, I 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. Monica: 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. Monica: So, what's the definition of a cyber device. You need to look at the FDA guidance document. 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 term as a cyber device. It has the ability to connect to the internet. So that's what FDA is is implying here. Host: So I know Trevor and I've had this internal debate a little bit uh and we have actually have a client we're doing some testing on. They have a device, I believe it's an implantable. Um I'm not exactly I don't remember, but it it had Bluetooth enabled, Bluetooth low energy. They disabled it. So we're testing to make sure is stay disabled. but it's got a lot of software in the device. But according to the and we've seen this conflict 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 uh 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. Monica: 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 cyber security 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's going with their evaluation. Even if your device doesn't seem to have that capability or turned off those capabilities, could it be a person any any other method someone else could turn on your device for whatever reason. Trevor: Yeah, and with the device that Christian was giving an example of, it has the hardware to connect to the internet technically. It has Bluetooth interface on the device, it has the chips in the products 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 three, 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. And but in general, yeah, connecting to the network can be done in so many more ways than I think people are aware of. Trevor: 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, you know, 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 were able to essentially compromise a device and introduce dangerous situations through manipulated RFID chips. Trevor: 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 websites a little bit ambiguous and leave some OEMs up to a bit of confusion. Monica: Right. I I I can see your point especially with startups and people who are not familiar with with a definition of what FDA's regulations require. Uh so it is a kind of a catch 22 for them. Host: So I know Trevor you you tend to lean on I think it's probably a more conservative approach. any class two or class three device that has software. We would consider something we need cyber security testing done. Because otherwise if you technically don't classify it as a cyber device, you may not even do a software build of materials. So you don't may not even know what software makes up your device. Is that fair? Trevor: Yeah, 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 gap 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 is usually not going to branch into class two or class three. That can run software on the inside, but it's going to be very very low risk. There are likely no interfaces with it. Trevor: 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 two or class three 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. Host: Well, we've also seen clients that have practically sworn to us that Bluetooth is disabled and RFD is disabled and we test their device, the device they're trying to get approved and those things are actually turned on. So, I 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. Trevor: And we see that at a honestly unbelievable rate, a very, very high percentage of devices have unintended interfaces and we reach out to the OEM. Unintended interfaces? Is that the new term for that? I'm coining it, you know. Get a trade mark on it. We'll reach out to the OEM and we say, you know, we're 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. Trevor: But it's it's very, very common and you know, cyber security 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 cyber security aware. In most in most cases in our experience. And so what we wanted to see is considerations like this brought up a bit more early. Trevor: 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, it 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, it's still 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. Host: Monica from your experience do you think the cyber security like I mean it's well established you need sterility, biocompatibility, all these sort of things done and do you feel like people are caught off guard that they also need cyber security done now or? Like what is a, what is the challenge because we people wait to come to us until like 60 to day, 60 days before submission? They never considered a cyber security till they're RA said, hey EStar is asking about the cyber security stuff. What if you'd done about it? They're like, I don't know, nothing. So Monica: Since the cyber security law went into the the regulations in 2023, most definitely. Everyone is cut off guard related to cyber security. They're so used to not having to design cyber security into their product. And to your point, Trevor, they're having issues understanding with the guidance document means in in guiding them and understanding cyber security. For example, you know, now you have to have a security risk management report, a threat model, which in the past you, you had a threat model. We always started with a threat model. Um, vulnerability and assets. Uh, cyber security risk assessments. You need to have third-party component level support in support and vulnerability assessments, uh 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, cyber security controls. It's it's connected more closely to your software development life cycle with your architectural views and cyber security testing and labeling. So it's quite a a number of elements of of deliverable that are required now for cyber security compared to what it was before in previous submissions you had one question related to cyber security, 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 a lot of my clients are very caught off guard. Trevor: Yeah, the even it doesn't seem like a lot saying, we have nine questions and 12 attachments, but often times when we're preparing cyber security documentation for a 510k, it can branch up to 500 pages plus of documentation. There's a lot that goes into it. Trevor: When we're looking at the cyber security controls, it can cyber security controls are covering a few key areas, authentication, authorization, cryptography, um, then detection and logging, integrity, there are a couple of 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, you know, usually, you think of that as 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 care 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 cyber security guidance, I think it should be called the cyber security mandate, but that's another conversation is a little bit vague as far as what's actually enforced and they say cyber security 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? How much is enough in that regard? Monica: That's a good question actually, we were talking about a class three medical device, implantable, that's a high risk device. Um if if that device wherever uh tampered with from a cyber security perspective, it could most likely impact the patient, right? Patient death is the worst case scenario. Um, I think cyber security is strongly attached to your uh decision-making process related to your software. As FDA also released a new update to software uh functions, software functions, software development, what's required in your pre-market 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 cyber security risks. So all three of those elements should be considered when you're developing, designing and developing a device that has cyber security and software. Monica: 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 cyber security. Host: We touched on a couple things. Like one of them is the what the FDA refers to as a secure product development framework or the SDF or basically secure software development. Host: And from my experience, which is like 30 years in cyber security, I I feel like the needle has not moved very much with teaching software developers how to do secure software development. I know what the FDA requires it, but we still and I know it's just required 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 the software development company. but I'm like, I don't 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 if I see a few companies now are starting to follow. I think it's ISO what is it? 6230? 62304, yeah. It just seems like a few companies now are starting to like follow that, but there's still not that many. Monica: There that standards 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. Um, what did change and with a lot of these software development or V&V companies may not have understood clearly is FDA changed the guidance document. The guidance document for software development and the requirements for pre-market software functions was actually introduced I think in 2022. Don't correct me if I'm wrong, but that that particular guidance document changed on how you're supposed to develop your software and test it. Monica: 62304 is a process for for just design control, for designing your process for 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 um, 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. Host: So Trevor, um, what what is your experience with uh IC 62304 and and companies like out of a sample of, you know, how all of our clients and the software development teams they use, how many of those would you say actually follow 62304? Trevor: It's definitely in the lower percentages there. I think we like single digits? Are we talking about or what are we talking about? Trevor: I would say double digits, but between 10 and 20%. It's a pretty thin number. Um a lot of what we see for a contract developer, like anRE is uh 13485 compliance. so that's quality system within medical devices. So they're preparing the software documentation but not necessarily the cyber security 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 common place practice. Trevor: Having said that, I think that cyber security controls and cyber security documentation are evidence of good software and should not be treated as something separate. But cyber security in general is just a newer industry and it's I think growing into maturity but not there yet. So, developers,REs, manufacturers are all still getting caught up and I think that we're getting there, you know, hopefully within five or 10 years, it'll cyber security 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 and sent it to the FDA and they said we're good to go. Uh and now obviously that's not the case. And so having artifacts prepared from something like 62304 or 81,001-5-1. It's the standards are not new, but the enforcement around the standards is new. Host: Awesome. I think we're coming up on time here. We are coming on time. So, I like to ask for any um last words of wisdom. I'll ask you first, Trevor. Need departing words? Trevor: 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. Host: Awesome. What about you Monica and you last uh words of wisdom for us? Monica: Well, I I think a manufacturers and developers need to follow the law, which is now the law is cyber security with FDA. Um, the guidance document help you understand the law. And I think I always tell my clients to take a look at that guidance document and 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's looking for. I I get a lot of uh feedback from FDA through clients trying to navigate this cyber security environment that we live in today and the feedback that I receive from pre-submissions and actual submissions is very informative and 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. Host: Awesome. Well thanks so much. And thanks for uh 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.