2026 Cybersecurity Priorities for MedTech with Jose Bohorquez

Hey, everybody, and welcome. It's me, you're going to be let in to the panelist area. If you don't want to be promoted, just decline. You might get promoted more than once, because there's a lot of people on the call today. I'm really excited that today we have, Jose and Muhammad are here from CyberMed. We'll type, to talk about cybersecurity. And, I have a number of announcements while we're getting ready about, you know, what you missed last week. IMDERF with Stephanie Grassman. Also, we did a webinar, God, was it just Wednesday? With, Claramet on,

MedTech user experience, conquering the human. It was about, how people get in the way of your medic… of your perfectly good medical devices from working. And the way that people think, and it was hilarious, and extremely informative. So, I encourage you to access that. Both are on YouTube. We have two YouTube channels I want to point out. One is MedTech Leading Voice on YouTube, and one is MedTech Leading Voice Exchange on YouTube. These Friday calls can all be found on the MedTech Leading Voice Exchange. Usually a day or two afterwards, as well as the, MedTech Leading Voice calls. So, you know, if you miss a call, you don't…

need to write to me and say, hey, can I get the link? Just go to YouTube, and you'll find everything there. Next Friday, we're gonna have, Michelle and Tiana from LeanRAQA are coming on to talk about some really interesting trends that are surfacing this year, with warning letters and the way that the FDA is responding. to, certain things, certain kinds of devices, and I think it'd be really, eye-opening in a lot of ways, from a regulatory perspective. I'm gonna drop all the links to the upcoming webinars. There are a number of interesting upcoming webinars, EUMDR, continuance, etc, and a really good PMCF, webinar on, on clinical

post-market clinical follow-up, in Europe. So, with that all said, I would like to give, you know, a couple people a moment to say hello. Paul Leonard, you want to say hello?

Leo Eisner "IEC601Guy": Who's Leonard? Leo Eisner "IEC601Guy": Yeah, goodbye. Leo Eisner "IEC601Guy": I just need to change it.

on your screen.

He feels like he's in trouble.

Leo Eisner "IEC601Guy": Mama! You did a bad thing, boy! Good day, everyone, wherever you are in the world.

Leo, do you want to put in a plug for your event in Carlsbad and tell everybody what's going on?

Feb is coming up quickly.

Leo Eisner "IEC601Guy": Yeah, February 2nd through 4th, we're talking about a lot of good stuff. Leo Eisner "IEC601Guy": 4th edition IEC60601, which I've talked about on the Friday call. Emc and how FDA makes you do essential performance the wrong way. Leo Eisner "IEC601Guy": what else? Cybersecurity. Rob Packard's joining us, so that's gonna be a treat, because he was on Leo Eisner "IEC601Guy": what, about a month or so ago? He's a really dynamic speaker, and NEMCO, they're talking from their perspective as a test house, so it's… it's a really good combination. So Rob's talking from the FDA… oh, sorry.

Leo Eisner "IEC601Guy": call my sister back in a sec. From theft day submission side and the MDR side, we're doing some workshops on the third day, EMC test plans, getting them together, doing traceability, and Leo Eisner "IEC601Guy": Cyber Sprint, and one other thing I can't think of off the top of my head. Leo Eisner "IEC601Guy": So, it'd be a really good combination. Couple people I've talked about, they said if their schedule matched up, they'd be there in a minute.

Great. And there's a special discount code, MLV15. So, use the discount code. Let's see, Francesco, I'm gonna ask you to send, the post to everyone through the chat, because I… since I'm not the host of this call, I'm in the car. afraid that I might get disconnected. I need you to copy and paste the things from the past calls and the upcoming calls from Anna. Do you have that document, or do I need to send it to you?

Send it to me, please.

And I'm gonna send it in the chat. Yeah, just make sure you mark everyone. Other than that, we're good, and… Jose, do you want to get started?

Sure. Yeah, we can get rolling. So, good to see everybody, It's been a few months since we last spoke, and, I'm here, I'm joined by one of my two partners, Mohammad Fusak, who's our Chief Security Officer. And, you know, Sean asked that maybe we give everybody kind of a… a quick recap of what's critical in cybersecurity, both in 2026, but really just more generally. So I'm going to share my screen here, My goal, my hope, we'll see how successful I am at this, is to cover some of these topics in a way that hopefully is, is intuitive and understandable, even if you don't have a background in security.

even if you don't necessarily have a background in engineering, I think a lot of the core concepts in cybersecurity are readily understood, so we'll try to cover a lot of that. You guys able to see my screen there?

Yes.

Good, we're good, we're good. All right, great. Hey, Angelina, see you on the chat. If you guys have questions as we're talking, I'm gonna try to keep an eye on the chat, to cover those questions, so feel free to be interactive, or if you've got a, you know, question and you're on the panel, feel free to just interject. Alright, so, I was thinking about, like. what are the objectives that you have as a medical device company when you're talking about cybersecurity? And I came up with four. So the first one, hopefully, is that you want to have a device that's actually secure. You know, security's reason for a lot… security's important for a lot of reasons.

It's important because security vulnerabilities can lead to safety risks. It's important because your business, your reputation, your operations could be at risk if your system is not secure. So there's kind of, like, that fundamental reason of you actually want your medical device to be secure. But of course, secondly is, you want your medical device to get cleared by FDA, because if you've got a medical device, and you want to get it to the market. more likely than not, you need FDA clearance, and there's a lot of regulations, there's a lot of rules that FDA has put in place around cybersecurity, so you want to make sure you understand and comply with those, which leads to the third, big

reason or objective, which is to be compliant. You know, it's not the same thing as to be cleared. You can get cleared today, and then tomorrow and not be compliant, because, you know, you said in your plan that you're going to do certain things, that you're going to keep track of your software bill of materials, and any no vulnerabilities, that you're going to do You know, penetration testing every 6 months, or whatever it is. And if you're not doing the things that you said you're gonna do, then you're not compliant. That won't come up during your clearance review, it'll come up during an audit down the line. So I think that's a third major objective.

And I would say a fourth one is most companies don't want their team to be overburdened by security. Security is… it's a highly technical, highly specialized field. Particularly for startups, there's a pretty good chance that you don't have somebody on your team who's got that expertise. So, whether it's CyberMed or somebody else, we definitely recommend you get somebody on your extended team that understands security so that they can help ensure that you meet all of the other three objectives. without having your team, you know, just be bogged down in those details. Sometimes we see companies that come to us and, you know, they've assigned this to a couple of engineers, and they don't have the experience, so they're spending countless hours trying to learn it and do it at the same time, making mistakes. So, you know, just making sure you've got the right overall team.

Why do we care about security from a regulatory standpoint? So, you know, FDA's cared about cybersecurity for at least a decade, but really, they raised the bar substantially in 2023. There was a… an act that was actually passed by Congress, so Congress really kicked this off with an update to the Food, Drug, and Cosmetic Act. They added the Section 524B, which you hear mentioned regularly for cybersecurity. And FDA took that and a mandate from Congress, and really pushed things even farther. So, like, let's say that 524B had 5 things they were asking for, FDA turned that into about 12 or 14 things they were asking for, and they had the, you know, the… they had the

not only the permission, but they really had the mandate from Congress to do that. They chose to expand the definition of cyberdevice to be fairly broad, which pretty much means if your medical device has software, all of this stuff applies to you, with very rare exceptions. There's maybe some small exceptions, but By and large, if your medical device has software, more than likely, FDA is going to expect those 12 to 14 documents to be submitted when you prepare your 510 submission through the eStar program. And then, you know, just kind of like a little scope note I always make to people, I won't read this for you, but it says that, you know, anything that relates to software, this applies to not just network-connected devices. So, it's something that's relevant for any medical device with software.

Okay, so I wanted to talk about some of the fundamental concepts of security, because sometimes these words get thrown around, and maybe there's not good clarity around what they mean. You hear the term vulnerability mentioned a lot, and I like this analogy of, like, a knight in armor. You know, like, the helmet will usually have a gap so that they can see, and I think that's a good analogy because clearly that's a vulnerability, right? So they're protected from arrows, but not through that area. But they don't have that area because they just like to have vulnerabilities. They have that area open because it serves a function. And that's true in medical devices and really in any system that has software, is

Sometimes, in order to create a certain function, you have to… or you're just intrinsically going to create a vulnerability. You know, if you want to be able to communicate wirelessly, that has a lot of value. that has a purpose, but it creates some vulnerabilities. So those vulnerabilities are generally tied to some type of function that you're trying to achieve. But that vulnerability can be exploited by a threat. So a threat is like a thing that can exploit a vulnerability. So in my little analogy, that would be like an arrow. Right? And then… the arrow doesn't fly by itself, the arrow is executed, or it's… that thread is executed by a human being, usually. I guess it could be a bot as well.

And we tend to refer to those as threat actors. So it's a person or a group of people, that are behind the threat. And then, ultimately, that results in some risk, right? When that threat meets that vulnerability, if there aren't proper controls in place. And there's a good chance that you're gonna create some sort of harm, whether that be, like, physical harm or other types. So if we now think about it from a medical device, let's look at an example, let's think of a vulnerability, like, you've got, let's say you've got you know, you've got a medical device that you want to communicate wirelessly with. Well, that creates a vulnerability, potentially, if you're using unencrypted wireless communications. And how could that be exploited? Well, the threat would be if a threat actor can spoof a command to alter the dose. So let's say this is some kind of,

you know, medical device that provides medication, and now you've got a threat, you've got somebody who can spoof and change the dosage, and that would be done potentially by, let's say, a malicious actor, like a… like a hacker, and then what's the risk? Well, now the patient receives the wrong dose of the medication that they need. So, you know, like an infusion pump, for example, this would be a pretty serious vulnerability. And you'd want to have some level of control against that, so that you reduce the exploitability of that threat. So that's just an example to level set. Okay. You know, I talked about risk, and risk, when it comes to cybersecurity, is a little different than our standard 14971 safety risk.

And FDA really harps on this. So, the thing that they're trying to get people to understand is that in standard ISO 14971 risk analysis, you're thinking about things probabilistically, right? What's the probability that this thing occurs? But in security, you've got an active actor who's trying to cause harm. It's not like, you know, a component randomly fails. It's like you've got an intelligent person who's trying to cause harm. So you have to think about things a little bit differently. And so, rather than probability and severity, you're thinking about exploitability and impact. And so exploitability, if we look, for example, at a common tool used in threat modeling and risk analysis called the Common Vulnerability Scoring System, CVSS,

You know, it breaks that down. There's multiple factors that you consider when you're trying to categorize or prioritize risks, and as an example, you would look at things like an attack vector. Like, how close does an attacker need to be? If you think about it, if it requires… let's say that you've got a communications protocol that's NFC, right? You literally need to put a thing right up against your device to communicate. Clearly, that's less exploitable than if you've got a device that's connected to the cloud, and somebody on the other side of the world can exploit that vulnerability. So there's a question of how close does an attacker need to be.

There's a question of, like, what's the attack complexity? Is it something that you need a nation-state type of organization to be able to exploit it, because it's, you know, it's extremely sophisticated? Or is it something that, like, your 15-year-old nephew can, you know, look at I don't know, go online, look up a YouTube video, and figure out how to exploit a vulnerability. Clearly, the more challenging it is to exploit a vulnerability, the lower that exploitability score is going to be. Third is, like, what privileges are required, right? Like, what access level is necessary? If anybody can log in and execute this, that's different than if you need admin privileges in order to be able to execute an attack.

And then fourth would be, like. is there user interaction that's required? Do you need a person to somehow participate, like, in a way, like, accidentally click on something, you know, like, phishing types of attacks you can think of in this category, where somebody actually has to do something in order for you to be able to successfully execute the attack. So, it's a different, slightly different mentality than classic risk analysis for medical devices. And then when it comes to impact, you're typically looking at confidentiality. integrity and availability. So, is data being exposed? Can something be changed in the system based on this vulnerability?

And then, can you even just bring the whole system down so that, you know, if you think of the infusion example that I gave earlier, you know, it's important for that system to be operational when the doctor thinks it's operational, so if somebody can take it offline. That's accessibility. But this is now security risk. If you look, there's no mention in this around patient harm, for example. And that's why there's an expectation that you're taking your security risks and evaluating them from a security standpoint, and then Considering which of those vulnerabilities can have an impact on safety.

And that's why there's a link between your security risk analysis and your safety risk analysis, but they're not the same thing. They're just interrelated. So there's an expectation that they're kind of feeding into each other. And here's… so I'm explaining to you, like, how a security risk can feed into a safety risk. You know, like, for example, in this case, if you've got a vulnerability that could lead to an integrity issue, like changing the dosing on an infusion pump. there's a clear safety risk associated with that, and vice versa, right? So, maybe there's a control that you put in place for safety.

that then creates a new security vulnerability. So when you implement features or controls in your system for the purposes of reducing your safety risk. you always have to analyze it to consider what impact that could have on security. So that's just a little bit on the nuances between security risk and safety risk. Yeah, and Carrie said, CIA now needs to be in your labeling. Yeah, it's a nice, easy acronym to remember. You kind of think of the CIA as dealing with this kind of stuff, and you know, it's good to understand that. Anything you want to say about that, Kerry, in terms of the labeling?

if it's not in there, your E-Star doesn't go forward, so… you gotta go back to your client in the middle of the night. I'm just saying.

Oh, yeah, you're right. People forget about labeling, that that's one of the requirements, when it comes to cybersecurity now. FDA expects you to put in a whole bunch of stuff, you know, that's just…

Everywhere, yeah. Yep.

Alright, cool. So what are the security objectives that FDA calls out to reduce risk? So they call out 5 specifically, so authenticity, which includes integrity. Which is ensuring that data is genuine and unaltered. Right, so thinking back to that infusion pump question, if the infusion pump has a mechanism to recognize that the command came from a trusted source. then it would execute that change in dosing, but if it doesn't recognize the authenticity of where that information's coming from, then it wouldn't, right? So you've got that kind of control. Authorization, so ensuring that only people who should have access to the device or to a feature actually have access.

And that they've got the right amount of access, right? You kind of want to have You want to right-size that. You don't want to give maybe everybody in the organization the means of changing the dosing for that infusion pump. Maybe there's certain people that can read a log, see what the historical dosage has been, but they can't change it, and then you've got other, you know, types of Users who actually have the ability to change the dosing, so that would be related to authorization. Availability, so having mechanisms in place to ensure that the system, you know, is robust, so that it's up and running when it needs to be. Confidentiality, so protecting information, the flow of information.

And then, kind of one that people don't think about too often, but secure updatability. This is explicitly stated by FDA as a security objective. Because new vulnerabilities can arise after your product has entered the market, and it's already fielded. Right, so if there's a new vulnerability that's discovered with a library that you're using as part of your system, what do you do? You know? you don't want to have to recall all your products because there's a new security vulnerability, right? So you want to incorporate a mechanism by which either over the air, or maybe it's, you know, it's a patch that somebody at a hospital has to go out and do. I remember talking to a guy at a conference about a year ago, and he was saying, like, half of his job, he worked at a hospital, was, like, on a weekly basis, taking a thumb drive and going around the hospital, updating

devices in the field. And obviously, there's kind of more sophisticated ways to do that now with remote updates. But that's… that's like a job, is… is making sure that systems are patched and… and up-to-date.

Jose, I have a question there. In that alone, with the thumb drives, you know, thumb drives… I have a love-hate relationship with thumb drives, but, like, you're using a thumb drive, you're going to different computers in itself to give this update, you know, you don't know if each computer is up-to-date to the… So, I would love your thoughts about this, is… I know you said remoteability, but, like, what are better alternatives than a thumb drive?

Yeah, I mean, there's a variety of alternatives, but, you know, doing remote updates, and any mechanism by which you transfer information has the possibility for vulnerabilities, right? And so you want to build your system to be robust against that. So, generally not a good idea to grab some random thumb drive and connect it to your device, but you also want to develop your device in a way where, even if somebody connected a thumb drive to it that has malicious software on it, your device is robust against that. So, you know, any mechanism of transferring data is going to have the potential to introduce threats, and so you want to design your system to be robust, but at the same time, you know, there's a concept of security, like.

in depth. Like, you have… and it's a combination of both technology and policy, right? So within an organization, it's just wise to not strictly focus on the potential, mechanisms you have in place to secure, but have proper policies in place with the people who are doing these updates, so that they're not grabbing their random thumb drive. They have dedicated thumb drives that are properly set up and everything like that. But Mohammed, I don't know if you want to add anything to that. By the way, Mohamed, your title says Jose Borquez, so there's two of us on here.

True.

But this is Muhammad Fusak, he's just one of my partners.

Yeah, I was gonna say, I mean, I mean, fundamentally, if the question is, I mean, thumb drives can be useful if you… In certain… I mean, not all medical devices are necessarily connected, so they're air-gapped, and, you know, you don't have a means of updating them except by bringing the update to them. But there are also ways of securing the thumb drives themselves, so there's actually secure drives that you can use. So there's a couple of different things you can do with… I know you said you have a love-hate relationship with thumb drives, and I hope you share your view, but they can be useful at times. Other than that, yeah, as Jose said, there's…

It's just a matter of if you're connected, then you can create secure means of performing updates remotely. I mean, the only other thing I can think of if you're not connected is having to switch out equipment and, you know, bring it in and replace it type of thing, which… that may seem odd, but there are actually medical devices that that model fits in well, like medical devices that are given to patients for a period of time and then come back, for instance. It could be updated in a central location and then put out again. So it depends a little bit on the usage. and what's available to you. I don't think there's a sort of a single answer that sort of one shoe fits all type of thing. But you can find ways. There are… there are…

In any situation, so far, we've not really struggled to find a way. There's usually a way to do it, a good way to do it, just have to think about the options you have.

Yeah, and I think bottom… it does answer it, but I think bottom line is, what policies do you have, and are those policies robust? That's… that's key, and really clarifying and having people understand that, because most of the people that are due doing this are… you know, not as close to the regulations. So, how do you explain that to them? Make sure it's clear, proper training, don't grab some USB that you buy at Target, right? It's password protected. So, there's definitely an educational curve that's needed there.

Yeah.

Sounds like another seminar for you guys. It would be good to have best practices there. Bye.

Yep. And, you know, again, it's security in depth, right? So you want to design your system so that even if somebody fails to follow a policy, you still… there's still a low chance of your product, you know, being hacked or something like that, but you want belts and suspenders in the event that somebody You know, introduces a threat that you hadn't considered. Alright, and it looks like there's a question from Siviram, if I'm saying that right?

Yeah, yeah, Jose, just, looking at the, the chat, looks like, some questions, around the connected devices, right? So even though your device may not be technically connected, but… interface, the FDA expectation is that you're going to do a proper risk management threat modeling to that, right? So, some of the questions I see are revolving around, you know, like, proactively, they expect you to Do your due diligence, security controls, as if your device were to… you know, really impact the connected ecosystem in the hospital network, for example. So, that's being, you know, really, strengthening the threat model arguments.

goes beyond the surface, right? So just…

Yeah, correct. Yeah, and I mean, you know, even, even a device that has no means of being connected to it, that doesn't mean it's completely, you know, unable to be exploited from a cybersecurity standpoint. You know, if you're pulling in libraries that are not secure, you can even have, like, ticking time bomb types of attacks, where the system doesn't have to be triggered, it's just set to start malfunctioning at some certain time. As an example, or as another example, somebody mentioned USB… we're talking about USB drives with Angelina earlier. you know, FDA's position, the reason they expanded the definition of cyberdevice, in the original, in the 524B, it really speaks to devices that connect to the internet.

And FDA said. we interpret that to mean not just devices that are actively connected to the internet, but devices that, through some mechanism, can have some connection to the internet. And a thumb drive's an example. Like, if you download something, you can obviously download something from the internet onto a thumb drive, and then connect that thumb drive to a device. And so, even though there's not a direct, real-time connection, there's sort of a path So that's… you know, you're always thinking about, like, all of these possible scenarios, and FDA is really expecting you to be very rigorous in considering what are the… all the different ways in which a vulnerability can… can be exploited in your device.

There was a question on attack surfaces, which I answered, just sort of jumping in. So, I know this presentation is pretty brief. But… and there is an entire process to go through, and, you know, Jose was outlining earlier about the vulnerabilities, and essentially, it's having… having determined that you do have vulnerabilities, it's how you assess them. But before you even get to that point, there's a process by which you even discover what vulnerabilities you have, which is Which is threat modeling, and so that's where you would assess… that's where you would be looking at your attack surfaces to determine how… how can an attacker reach you to begin with. So… so, you know, it's difficult to include everything in this short presentation. There was also a question, I think, Paul, you raised on clusters, and I… sorry, I wanted to give an answer, but it was…

Chat went too fast. the reality is that… I mean, segmentation… it's very hard to generalize, but when you're talking about clusters of, you know. potential systems that can… that can become vulnerable, how do you update them, how do you manage them? Some of that comes down to segmentation, some of that comes down to the ability to, you know, take a cluster offline and perhaps have a duplicate that you can run in place. So there are answers, but it's difficult to come up with a single general you know, answer. So, again, I hope I… yeah, we can have a discussion offline about it if you want, but…

Well, if I can jump in, my comment, or really my question, concern is, you know, when you have several devices out there, telemetry is becoming more of a thing now, right? The question is, if… you have a bad actor in one location that jumps on and gets on a device, can they go backwards, right? Yeah. In fact, and is that all… is that a protocol that you… whoever's doing cybersecurity. is addressing. I mean, is that part.

Absolutely. In fact, you must address it. There's something called an architectural view called the multi-patient harm view that FDA requires you to do, and it's exactly for that use case. It's the case of, if I have devices that are spread out, but they, for instance, all interconnect to a central location. how do I handle the case of, you know, a bad actor jumping in through one device, reaching your network, and going out and harming other patients? So, yeah, absolutely, you have to look at that. And, you know, connectivity has its benefits. Again, so connectivity is great. You can have telemetry and collect data in real time, but of course, it opens up that vulnerability of.

Oh, no doubt. comment, right? So, you know, so you must consider that as well.

And since I have the flow, can I… I just added another question? You know, there's… at some point, it's something, you know, creating a security level or capability in the cybersecurity narrative is not worth the squeeze, because, you know, the investment goes up, and the threat level comes down, because how many people are actually going to do that? Is there, like, a standard? Like, you can… if, you know, medical device startup companies, which is where I spend a lot of my time. you know, finance is always an issue, right? So when is enough first to pass FDA, you know, be secure, but then when is it really enough? Are there… if I wear the hat on my client, which is the manufacturer, the owner, the guy that… the startup CEO,

allocation of funds, like, hey, I'm good with a Honda, right? I don't need the Ferrari yet. Or is there an assessment model to figure out how much of, based on the use case, the disease state.

the patient, you know, where is it deployed, that kind of stuff. I'm just curious about the levels. I mean, the answer is sort of yes. I mean, what you're getting to is acceptability. So the answer is really, like any kind of risk assessment mechanism, that you can never bring your risks down to zero. Well, I mean, you can, but… Economically, it doesn't make sense to try to bring it down to zero. So, the question is, how do you establish an acceptable level where you say, I've brought my risks down to a level where, you know, I've invested to bring that down, and it's good enough, right? We… there are ways of doing that, yes. I mean, we do set acceptability thresholds for assessments so that we focus on the more critical issues that need to be removed, understanding that there's a cost to that, and allowing things to remain

Because the cost-benefit doesn't justify doing anything about it. And just to be clear, that can change over time, because as Jose said, this is a dynamic environment. This is the difference here, is that in cybersecurity, you have to think about that attackers don't stand still. attackers are constantly improving, so if I make an assessment today and say, okay, this vulnerability is going to be too challenging for someone, its risk is low, it's below the threshold, so it's acceptable today. Well, in 6 months' time, things might change. That vulnerability might be very, very easy to achieve now with new tools and technologies, and all of a sudden, its risk level goes up, and now it's no longer acceptable.

So, it's a very dynamic environment.

And just to add to that, I mean, we do see it, and it happens with our clients, like, we have this conversation where you say, look, we've got the risk level to an acceptable level from, let's say, you know, from a product and a safety standpoint. But there's a desire to bring that risk level even lower over time. So it's also possible to, you know, submit your product to FDA, to get it into the market, recognizing that the risk is low enough But that, for business reasons, it would be wise to get it even lower, and that's something that you can do over time. That's a reason why you have the mechanism for patching your software, for doing updates, because for business reasons, you might find that it's

wiser to submit now, get the product on the market, you're not putting patients at significant risk, and then over time, continuing to improve that. So…

Appreciate it. Thanks, Jazz.

And that's why we… And that's why the FDA asked for 4 more documents the next time you look at the… open up the cybersecurity, and they now want 3 more documents with their cybersecurity request, right?

Yeah, and that is… Description, that description of what the risk is all about, it's extremely important, because as much as we want to say that FDA wants a risk-based approach for this or for that, whenever you use the words risk-based, it really raises an alarm amongst reviewers and regulators. So, so you really have to be very detailed and comprehensive at explaining exactly what do you mean by there is a low risk, you know, attached to whatever it is that we're doing. It's not enough just to say it, but now you have to explain it.

Yeah, and by the way, that's part of why, where, you know, when we were talking a little bit earlier about, like, CVSS scoring as an example, right, this is actually a quantitative approach to estimating the risk of a specific vulnerability. And so, in your risk management plan, in your security management plan. you would establish what that criteria is for your product. Yeah, in the plan, right.

Thank you.

Right, exactly. So you're… a priori, you're saying, you know, for CVSS scores that are less than 4, you know, we're going to consider those to be acceptable and something above that. And so, you know, you set up your criteria, but then you can choose from a business standpoint to be a bit more subjective about those things, and say, okay, look, this is an acceptable risk based on our criteria. But there's good business reasons for us, over time, to continue to get those as low as reasonably possible, and such.

And one thing that you mentioned, Jose, that I think is extremely important is that that risk level that you have identified and described has a certain expiration date, so you're gonna have to find a way to do frequent risk reassessments.

Oh, great.

Because… because if you don't, you will create a certain level of uncertainty, and you're gonna be held accountable for it.

Absolutely.

I'll add one last thing, I know we're derailing, but…

The one thing that the agency will also ask is for your QMS procedures.

So, you can talk about this in any sort of response, but they will call you out and say, please provide the procedure here so that you can provide evidence of how you monitor this very robustly and accurately.

Well, and you have to call all that out in your cybersecurity management plan. I mean, even though, like, the 2023 and 2024 guidance is primarily focused on pre-market, a lot of the things they're telling you to do pre-market are with an eye towards post-market. So it's, you know, what are going to be those security metrics that you're going to track? What is your plan for evaluating your software bill of materials post-launch? to continuously understand if there's new vulnerabilities that have come up. How regularly are you going to repeat penetration testing? you know, as Muhammad was mentioning earlier, there's new techniques that come up to penetrate, you know, and attack vulnerabilities. So, you know, if you only tested it in 2022, and it's been 4 years since you've retested it, it might be that you've got some vulnerabilities you're not aware of.

because you haven't tested it with the latest and greatest threat approaches. So those are all things that you're telling FDA you're going to do post-market. So even though it's during your pre-market submission, it's with an eye toward post-market. So very dynamic. So here, let's try to see if we can make a little bit more progress. We've got, We're about halfway through the slides. I try not to overwhelm folks with slides. You know, this ties into what we're talking about. It's like, you've identified those vulnerabilities, now what? Right? You know, obviously, you're going through the process of estimating the risk and assessing, is it acceptable or not? If there's vulnerabilities that are not acceptable from a risk standpoint, then for sure you have to implement controls to bring those down to an acceptable level.

There's other vulnerabilities where maybe they're at a low enough level, but you know that there's kind of mechanisms that are low-hanging fruit against that risk, that cost-benefit, where it makes sense to implement controls there as well. And there's 8 control categories that they call out explicitly, but they tell you, and it's a true statement, that this is not meant to be exhausted. There are other things that you might implement as well. But things like, authentication, so providing identity before granting access. So authentication is… it's something that everyone here is familiar with, whether they know it or not, because,

each of you uses a password, for example, to log into various websites and all sorts of things. I was… there's something I learned a long time ago that stuck with me, it's the idea of, What do you know? what you know, what you are, what you have, right? So when we think about multi-factor authentication, for example, it's like, what do you know that would be… Who can give me an example of something you know that's used for authentication? Like a password.

sowmya krothapalli: Passport.

A password, right? So a password is something you know. What you are, what's an example of that?

Date of birth? No.

A what?

Date of birth?

Date of birth? No, no, something… Not exactly. That would be something.

Male… no. What are you talking about?

sowmya krothapalli: Facial recognition?

Yeah, exactly. Facial recognition, you know, thumbprint, something that's a biometric that is unique to you, so somebody else would have a hard time spoofing it. And then what you have. So most of you who implement multi-factor authentication, for example, what happens after you put in your password?

Leo Eisner "IEC601Guy": You can text.

As Bailey's showing, right, so what you have is your phone. So now, a hacker would have to both know your password and have access to your phone, this thing that you have. That's where multi-factor authentication comes in. You're adding multiple layers to help ensure that you are who you're saying you are, to establish the proper trust, so that the system can then give you the access that you're asking for. So, it's just like a little, mnemonic device that I've found to be useful over time, right? So, something that you know, something that you are, and something that you have. And you try to implement those as controls.

You know, so you might imagine in that, going back to that same infusion pump example, you know, maybe there's a code that the healthcare provider has to punch in, maybe there's facial recognition, maybe there's a thumbprint, you know, so maybe they have a fob that they can tap against it, maybe it's a combination of those things. So maybe… and you try to… by the way, like, we're not going to touch on this too much, but, Sean mentioned that there was a talk on human factors a couple weeks ago. Human factors and cybersecurity actually go hand in hand, because there are scenarios where you create safety risk by implementing controls

that are so onerous that they actually create safety risk, right? So if somebody has, I don't know, a defibrillator, and they have to punch in, you know, a 14-digit passcode that they can't remember, and then they can't, you know, apply defibrillation in time, you're now putting the patient at risk because of the security control. So you have to really weigh all those things against each other. So you might have scenarios where it's like. You know, you have a bypass mechanism that only allows you to do a very core function And that sort of thing. Alright, so that's authentication. Authorization is limiting.

And sorry, Jose, to that point, and in fact, as part of your documentation, FDA actually requires you to document those trade-offs. So that is actually captured, not just thought about, it's captured, too.

Yeah, no, that's right. Yeah, and SW96, which is… the primary standard around cybersecurity now, it's fairly recent, but it has some nice diagrams around that. Just that interaction between security, human factors, and safety, they each have their nuanced differences in terms of how you analyze them, and they all have an interplay. Cryptography, so the second half of this talk is, is… with a focus on cryptography and encryption. It's scrambling data, essentially, so that somebody who accesses it can't understand it. Code data and execution integrity, so ensuring that software and data haven't been tampered with, right? When you boot up a system, like, how does a system know that if you've made an update, that it's a legitimate update, that kind of thing?

Confidentiality, I think we're all pretty familiar with. Event detection and logging, you know, one of the concepts in security is non-repudiation, so the idea that somebody shouldn't be able to do something and then deny that they did it, right? So having proper logging in place, so every time somebody touched that. That infusion pump, you have a record, and you know that it is the person who was logged. Having resiliency and recovery, so mechanisms in place so that the system can withstand attacks that try to bring down the system, or if it does come down, that it can come back up quickly. And then the updatability and patchability that we've talked about. So these are kind of some of the ways, some of the fundamental ways in which you take a system and, take those vulnerabilities and reduce their exploitability, or reduce the impact that.

Jose, how about… how about external reporting? I mean, you have an event now. You probably also need to do an external reporting to FDA, or maybe a European function, which in turn also means that you may have to do an investigation, so I see what you're going with this, but obviously there are other ramifications that I think are worth mentioning, you know. Later on.

Yeah, and that all ties into your post-market responsibilities, right? So communicating with stakeholders when there are security events is one of those fundamental things. that you need to explain to the agency what your process is gonna be, and those cybersecurity metrics, which is another one of those attachments that you put in E-Star, speak to, for example. how you're… what you're going to track and how it's tracking. If you're doing a second generation product, they want to see, okay, how did you do with your first generation? How many events did you have? How long did it take you to communicate with stakeholders? What was the average time it took you to update, patch, patch and release?

those patches. So yeah, there's… there's the kind of the technical part of the controls, but then going back to what we talked about earlier, there's the policy portion of it, like, what is your procedure when you do detect something? Right. Alright, good. So, quick interruption to the program, just before we start the second half. In the second half, I'm gonna give you guys a crash course on encryption. In layman's terms, so encryption's something that tends to be very technical and mathematical, but actually the core concepts are, I think, are very accessible. But before we do that, if we're not connected on LinkedIn.

There's a QR code, or you can just look me up. Jose Borquez. If you want to talk for some reason, we partner with a lot of RAQA consultants, and of course, we help companies all the time with cybersecurity. Feel free to schedule some time with me, and then if you just want to learn about CyberMed, there's a QR code for that. We do have a cybersecurity book that we can make accessible, just drop the word. book in the chat, and we'll send it over to you. And then we put together an encryption guide for non-engineers, which I'm happy to send your way if you're curious, so feel free to do that. Sean, I don't know if there's any other announcements here before we jump into the second part of this.

No, go ahead.

We're good? Alright, cool. Alright. So, encryption. So encryption… Can be a little, intimidating. You know, cryptography is a very technical field, but the core concepts are pretty understandable. So, in encryption, what you're trying to do is you're taking something that is readable, like, it's called clear text. So, as an example, okay, here's your glucose reading, here's the patient ID, here's a timestamp. You're passing it through an algorithm. That has a key associated with it. And at the other side of that, you get ciphertext, and that's just the technical term for saying that that clear text that was readable is now scrambled.

And you want this to be very random, you don't want it to have patterns that are recognizable, right, because then you'd be able to crack it. And it's primarily rooted on this idea of a key. So, what is a key? A key's a… it's a secret piece of data, like a password, but it's a lot longer, and it's random. It's meant to be highly random. The key is used to scramble the text. By leveraging an algorithm, and there's a variety of them. And the algorithm itself is publicly known. It's published, anybody can access it, so you're not protecting your data because of the algorithm. In fact, like, one of the big no-no's in security is to try to create your own

encryption algorithms, and pretend like your system's secure because you keep it hidden, you know, or you keep it secret. That's not the way that you create security. You create it by having proper keys, using well-vetted algorithms, and then just properly securing the keys. The same thing that's used, you know, you're using a key to lock data, you're using a key to unlock the data, and it's really important to keep these keys secret. There's two categories of encryption. There's symmetric encryption and asymmetric encryption. So, symmetric, what it means is that you would use the same key to encrypt the data.

and then the same key to decrypt the data, right? And so now, let's say this glucose monitor encrypts the data with this key, sends the data, and now the app has the same key, and then they can decrypt the data. What's good about this is the algorithms are very fast and very efficient, so it's ideal for bulk transfer, but the problem is, how do you exchange that key? Right? So, you know, if I'm trying to send a message to Muhammad, and he and I, right now, we're seated about, you know. I don't know, 5 yards away from each other. I can walk up to him and I can say, hey, whenever I send you information, here's the key that we're gonna use to encrypt and decrypt. Easy peasy.

But if I want to exchange data with Paul, like, how do I securely get to him that key so that we can exchange information? I mean, if I email it to him, like, that's not a very secure way. If I call him and give it to him, right? So, you need a mechanism by which to share… this common key. And that's the big challenge that arises with symmetric encryption. And so, there's asymmetric encryption. And it's a really clever, cool approach. Where you have two types of keys. You've got a private key, and you've got a public key. So the private key, as you might expect, you keep yourself, and you don't give it to anybody else. And there's a mathematical relationship between the private key and the public key.

The public key, you can give away, right? So everybody can have the public key, but only you have the private key. And what that means is anybody with the public key can use it to encrypt a message and send it to you. But if somebody else has the public key, they can't use it to decrypt the message. Only the person with the private key can decrypt the message. So it allows this one-way secure communication between the person who encrypted it using the public key and the person with the private key. So the analogy here would be. Like, let's say a mail dropbox, where pretty much anybody can drop mail into the box, but only the person with the private key can open the mailbox to extract that message.

The downside is that it's… very expensive mathematically, right? So it requires a lot more processing, like a hundred to a thousand times more processing. So if you're trying to exchange bulk data, you don't really want to use private-public keys, because it's just very inefficient. So, the trick, right, is to have this 3-step process, where You have this, handshake. Where you use your asymmetric keys. to share with each other, agree with each other on what the public key is going to be. Right? So I mentioned earlier, the problem with symmetric keys is, like, how do you exchange that key securely? Well, you do that through asymmetric encryption. And now, once we establish a session.

Right? These are meant to be kind of short-lived keys. Once we establish this session, now we can exchange data using that symmetric key, which is a lot more, efficient. So, a lot of systems work like this, you know, web communications, TLS, HTTPS, works like this, Bluetooth works like this. So there's… it's a very commonly used mechanism. But I don't know, Mohamed, anything you want to add related to the topic?

Well, I just want to clarify the way it was stated. So, you're using, you're exchanging public keys for the purpose of then deriving a session key. that is symmetric. So you're using asymmetric encryption… asymmetric keys To create a symmetric key that is private to both of you. So, the idea here is that, again, you're trying to solve the problem of how do we both get the same symmetric food?

No, wait, brother.

to be efficient, right? And there's a… so there's an al… there are algorithms for this, for essentially utilizing public keys to derive Oh, on each side, derive the same symmetric key that you can then use. for data.

Great. So, our goal with this really was to say, look, let's take… and we're gonna try to make a series out of this. of taking, like, things that can seem very complicated and maybe hard to understand, and try to communicate them in ways that are more accessible. I don't know how well we did in this case. Hopefully, this stuff makes sense. I'm happy to answer any questions that you might have. And I think we've got about 10 minutes, so really happy to have conversation and share anything else. That might be of use to you. By the way, I just noticed my buddy from college, Jorge Tamayo, is on the line. What's up, brother?

It's good to see you, man.

So, quick question about encryption. I understand that it takes up space, and that a lot of devices are trying to be smaller and fit in the least amount of space possible. Can you talk about the space required for, like, you know, getting things inside little devices?

Yeah. That's a great question. I'll say maybe a quick thing about it, and then get Mohamed on here, who's really an expert in this area. But, yes, and it's one of the reasons why You don't want to try to bolt on security at the end. Because, as an example, the choices you make up front, even about the microcontroller that you choose to use in your system, will have implications. There are microcontrollers, just as an example. That have accelerators, that have crypto engines inside of them, that are specifically hardware built for efficient implementation of encryption, decryption, you know, and cryptography in general.

If you ended up selecting a microcontroller that doesn't include that, and down the line, find that you need it, you're kind of screwed, right? Like, you've put in a lot of work into building out your system with one microcontroller, and now, you know, maybe you've got circuit boards that you've already manufactured and everything like that, and you go back. So you want to find the proper techniques early so that you can implement proper security and have the hardware to support it. But, Mohammed, what else? Could you add?

Yeah, no, I mean, you hit the key thing, which is you've got to have a sort of security-first posture, right at the beginning of a project to understand what your needs are, to select the right technologies to enable you to do that. So, a good example of that, Sean, so, I mean, you bring up a good point in terms of So, you know, space, but the reality is that almost all Even small modeling processors today are very, very capable of performing symmetric encryption and decryption. that's actually pretty standard now. So that, that is usually not an overhead. But asymmetric is where the challenge becomes. So.

Deciding on your device architecture in terms of, like, where do you need to do, what type of encryption you need to do. matters a lot, right? So… there are techniques you can do to plan that out and avoid running into the problem of, I'm out of space to do, you know, asymmetric encryption or decryption if you don't, you know, if you need it. So it's not as big a problem today with good symmetric encryption and decryption, or I should say symmetric cryptography, but it can be a problem if you don't plan ahead.

I meant no. You know, standards are changing, which particular standards apply to, this area of cryptography, and where are we going to be 5 years from now? Wouldn't it be smart for medical device manufacturers to be looking ahead 5 years and saying, what are the expectations going to be in 3 to 5 years, rather than what are they, in 2026? And plan.

Yeah, so…

their systems from the beginning, and to avoid… I mean, what I'm trying to get to is avoiding the oops. Oops, we didn't see that coming. Oops, we didn't see that coming. Oops.

So… And there's a blind… people are currently blindsided… I mean, there is a big oops coming, so… and that is… that is… and it's constantly being revised. NIST expects that by 2030, now at the latest, it could even be earlier. you're going to be in the quantum realm, and quite a few… actually, very important. What we described in that last slide, that ability to be able to take a public key and convert an out of a public key exchange, produce a private key pair that you can use for symmetric encryption. the current algorithms that are available all break with quantum, so it's, like, 4 years from now. So…

I'm actually not quite sure how the world is going to handle this, because most of the techno… most of what we have today, Zoom included, all our websites, web technologies, are all reliant on algorithms that probably have another 4 years to go before they're… start to become pretty much unusable. How quickly that will happen, I'm not sure how fast it will roll out, but… But it's… it's… something has to change very quickly. Now, medical devices have long lifespyes, and so you're designing devices today that absolutely will exist in 4 or 5 years' time. So if you're not prepared, we're already doing that. We're already making recommendations on… on making choices today

With any new devices that should take into account what's going to happen with, you know, quantum computing in the three years. And you have to have quantum resilient algorithms for now. Cause if you don't… if you're not planning for it now. Four years is gonna come by real quick. So that's probably the big… that's probably the big gotcha right now.

And there are algorithms already that… There are. …that, yeah, NIST would tell you that you shouldn't implement at all. And by the way, FDA is looking at that, right? So if you're using outdated algorithms that are already, have a very short horizon before they become ineffective. they're actually going to push back against that. So you need to be implementing those mechanisms now. You know, as Mohamed.

Or have it in your plan, have it in your plan.

Right, right, right. Because there are… and there are, you know, more resilient algorithms that exist, and more that are coming online, And you want to have mechanisms by which to update your systems to incorporate some of these new mechanisms. But there's others that have already been shown to be deficient. So, you want to be sure that you're using things that are going to give you enough runway, and that you've got a mechanism for updating your systems.

Yeah, the good news is AES, which is the most common symmetric, is still safe, and you just need to probably go up from 128 to 256, which is what most people are doing now. But you, you know, so AES is safe, but, RSA and EC and exchanges are starting to become really problematic, so… so you need to start… as I said, you don't necessarily today have to launch a device that's quantum resilient, but you need to have it in your plan to know how are you going to become resilient, you know, probably within the next 3 to 4 years.

Yeah, one quick thought there is, Pretty much, going through an inventory is the starting point. You look, your crypto assets, they call it. And so, really knowing where your keys are stored, you know, whether it's use cases, you know, code signing, or encryption, where you're storing, that goes a long way to set up the road plan, Mohammad, that you just said, right?

Yep. Yeah, I mean, FDA has not asked for a crypto bomb, you know, in terms of, you know, CBOM yet. It's not in the standard. We're starting to do it, because I think, to your point, having an organized way to know, what keys are you using? Where are you using them, how are you using them, how are you distributing them? Just have that all in one place so you understand, you know, what your exposure is, is a good… is certainly a good start. That's probably a prerequisite To start there, and then plan out. As I said, some things can stay the way they are, they're fine, and other things will have to be replaced.

And I haven't… we haven't had any pushback yet, as I've seen, where they're insisting that you must be quantum resilient. Now, it's not something that they've forced on anyone, but I think it goes a long way to tell them that you're aware of it, and that you have a plan to get there.

At the very least. And I think… I would say…

you should have a plan, at the very… people should be aware of it. Start it with the awareness, you know, and then go from there.

Bye.

And I think we're gonna… I honestly think we're gonna be surprised. I think that the expected deadlines… the expected dates are gonna be sooner than we think. Technology's moving faster and faster, so I have a feeling that it's gonna happen sooner than people maybe expect it to happen. So, that… Just my sense… my sense of it.

I would say, you know, one thing that we try to do on this call is try to give people something that they can take on with them. Besides the things that have already been offered, I would say, if I were to finish this call, and I were a regulatory person or something working with a medical device company, I would Say, this part about, quantum, whatever, you know, I don't get it, I don't understand it. I would say ask, you know, your favorite chat GPT This is my device, this is… I want to know what my exposure is, I want to know what my vulnerability is, and I want to help start my company creating a plan, help me understand the strengths, weaknesses, opportunities, and threats regarding quantum computing. And just start the conversation within your company, and get people thinking about the fact that this will come sooner than you expect.

And could hand people their lunch. There you go. Ending on an up-down.

Comments. Always, always be learning, for sure.

I want to thank you, gentlemen, for your time and your knowledge. It's always fascinating to learn from people who really know what they're talking about, and I appreciate everybody that contributed today. And, everybody that showed up, we had huge turnout. I saw over 140 people on the call at one point. So that's fantastic. I, encourage you to reach out to the speakers today, reach out to each other, get connected. You know, this thing works better when we do it together.

Yeah. Thank you all for being here, for your attention, and yeah, as Sean said, please reach out. Love to connect with as many of you as possible. So… See ya, everybody. Take care.

Thank you.

weekend.

Bye.

Leo Eisner "IEC601Guy": Thank you.

Good travel, Sean.

paint.