Early Design Decisions that Shape Medical Device Success with Chris Danek, CEO of Bessel | Ep. 63

Most medical device programs do not fail because of testing. They fail because of decisions made long before testing ever begins. Architecture choices, software dependencies, and hardware constraints quietly shape whether a product can scale, pass regulatory review, or reach patients at all. Cybersecurity now sits at the center of those decisions. It is no longer a downstream activity or a compliance checkbox. It directly influences patient safety, system integrity, and the ability to operate within modern healthcare environments. This discussion with Chris Danek, CEO of Bessel, Christian and Trevor examines how early-stage design choices create long-term consequences. Seemingly minor decisions such as selecting a software component or microcontroller can introduce risks that surface during FDA review or force costly redesigns late in development. Regulatory expectations have evolved alongside these risks. Demonstrating cyber security requires more than testing. It demands traceability, lifecycle integration, and alignment between requirements, architecture, and verification. For teams building medical devices today, success depends on discipline at the earliest stages. Strong products are not only innovative. They are intentionally designed to withstand scrutiny, scale effectively, and operate securely in real-world environments. Episode Breakdown: 00:01 Introduction and guest background 02:54 Building for breakthrough impact 05:16 Commercialization planning timeline shift 07:22 Understanding customer requirements deeply 12:30 First-generation device connectivity challenges 18:45 Reverse engineering target markets 24:20 Healthcare delivery organization procurement 30:15 Reimbursement pathway planning 36:40 Clinical workflow integration requirements 42:50 Cybersecurity as a customer requirement 48:03 Working with regulatory stakeholders 50:55 Final departing thoughts The Med Device Cyber Podcast is brought to you by Blue Goat Cyber, cybersecurity experts providing essential security solutions for the medical device industry. Learn more by visiting https://bluegoatcyber.com. If you're interested in our services or partnering with us, schedule a Discovery Session: https://go.bluegoatcyber.com/meetings/blue-goat-cyber/discovery-session Christian Espinosa is the CEO and founder of Blue Goat Cyber. Trevor Slattery is the Chief Operating Officer at Blue Goat Cyber. Christian Espinosa on LinkedIn: https://www.linkedin.com/in/christianespinosa/ Trevor Slattery on LinkedIn: https://www.linkedin.com/in/trevor-slattery-34852b1a9 Blue Goat Cyber on LinkedIn: https://www.linkedin.com/company/blue-goat-cyber/ Blue Goat Cyber on Instagram: https://www.instagram.com/bluegoatcyber/ Blue Goat Cyber on Facebook: https://www.facebook.com/bluegoatcyber/ Blue Goat Cyber on YouTube: https://www.youtube.com/@BlueGoatCyber/?sub_confirmation=1

Startup company sometimes can run past a milestone in a funding capacity. The runway of their company that could be make or break for the company itself. They like to say, oh, cyber security is just about data protection with medical device. But the primary driver is patient safety because if you think about it and you can hack into a surgical robot that's performing surgery on somebody's spine, you can paralyze that that person. There's this misconception that software developers understand cyber security. They will all tell you they are experts in cyber security, but the reality is from my experience, I would say 1 out of 100 actually know about cyber security. Christian, before you go forward on that, I'm just going to say, well that's provocative and maybe to some people, not me, but to some people that's inflammatory. I think there's a good reason why many software engineers therefore then feel that they they have some level of expertise. We'll start testing three months out from submissions when the first time someone's touched their code and we come back with 3500 vulnerabilities on day one. And we say, well, you know, this is this is a conversation we need to have. Yeah, I can save you like $500,000 in cost overruns and delays and everything else from a 10-minute conversation, right? Christian: Back to another episode of the Med device Cyber podcast. Today we're talking about how to build medical devices for impact. And we have Chris Danek here a guest of ours, from Bessel and we've also got our co-host Trevor as usual. And then myself. I'm coming from the beautiful Tempe, Arizona where it's like 85 degrees out today. I think Trevor is coming from the foggy San Francisco where he assisted a movie to, for I don't know why, but you know, he likes to the fog and the cold and rain. And then where are you coming from, Chris? You're also in California, right? Chris: I'm in San Carlos, California, really, you could think Silicon Valley. it's between the San Francisco Airport and Palo Alto, and I would say that we're our weather is typically pretty nice. Christian: Yeah, even though you're close to San Francisco, the weather is nicer there, isn't it? Chris: Yes, that's for sure. Christian: Why didn't you move to that area, Trevor? Why San Francisco? Why why not Santa Clara or anywhere like closer to Silicon Valley? Trevor: Well, Santa Clara, I don't like San Jose. Something about it. It just feels like this expanse, and San Francisco's nice because everything is in 49 square miles, and so it's so easy to get from anywhere to anywhere. Chris: Yeah, and I I'm down with Christian. I think that the niners come from the the gold rush. But I didn't I didn't make that connection before to Denver Airport is is a larger area than than San Francisco. It's pretty interesting, Trevor. Chris: Hey, Christian, thanks for inviting me on this podcast. I've been watching what Blue Goat's been doing for the past few years, and I think you're filling a real gap in an understanding, awareness, and actually execution on cyber security, which is more and more important. And, I'm interested to talk, too, about the common challenges outside of cyber security that startups in our field are facing. So thanks for the invitation. Christian: Yeah, well thanks for joining us. I know we, uh, ran into each other at JP Morgan not too long ago. And we're talking about the fog. I think what one of the things you help uh, companies do is remove some of that fog on their journey to commercialization, and would that be a good way to kind of kick off what you do and maybe describe a little bit about the companies you work with and everything? Chris: Yeah, I like that. I like that metaphor and and trying to bring clarity in strategy as you you've mentioned, and and how we execute against that and how we can actually fuel the tank with fundraising. Those are the things we do, but it it starts with the the concept of breakthrough impact. And to me breakthrough is an innovation in our arena of of of health care that will sustain and scale. Without that it doesn't have the ability to impact millions of patients and thousands of caregivers and clinicians. So that's what we're all we're all striving for in this industry really is to create breakthroughs that that scale impact. And I would say that, you know, the the challenges remain the same but it's it's harder than ever to address the significant questions and concerns or risks that startups have to to be able to answer the questions that investors have. You know, let's say that it it used to be the case that you could talk about your commercialization plan later in the company life cycle, because first we we know there's a demonstrated clinical need, we know the market is is big enough and we we think we have a line of sight on certain areas. And if we show technical proof of concept, clinical proof of concept, then maybe during the Series A round, we'll work harder on the commercialization plan and make it make it specific and concrete. This idea of of proxy or relying on the experience of the team and the judgment of others around, it it breaks down because now startups have to answer, they have to have a good a good path to answering all of the questions that investors will have, even from the earliest stage, that relates to commercialization. On the technical side, um, if we, if we dial back from a successful launch through, through not just reimbursement, but the regulatory approval, looking at the host of constraints that a development team has in in getting a product that's able to help patients, and typically would think about software life cycle processes, usability engineering and uh, and electrical safety, IC 60601. And those used to be sort of the big three in terms of standards and systems for making sure that we develop safe and effective medical devices. And I'm I'm going to say especially up up in this podcast that cyber cyber security and considerations of cyber security is added to that list of things that you should be thinking about from the beginning, making sure you make good design choices and and all that sort of thing. So that's another reason I was so happy to happy to be here and join you guys today. Christian: Yeah, it's it's interesting that the philosophy was to just worry about commercialization later on. I mean, we are bringing an innovative product to market, but it's also a business. And something you said from a breakthrough or impact perspective, if the business fails, then the technology doesn't get to the people that need it. The product doesn't get to the patients that need it. So they have to go hand in hand and it's one of those things like Trevor and I always talk about reverse engineering the market you want to get into, the healthcare delivery organizations you want to get into because they they may have specific procurement requirements that are, you know, very different than uh you might think. So from a commercialization standpoint or cost reimbursement standpoint, and just an acceptance and adoption standpoint, these are all things that I think uh are still thought about way too late in the game. And same with the same thing with cyber security. A lot of health care delivery organizations have very specific guard rails around cyber security now because there's been so many data breaches so they don't want to just accept any medical device that has some sort of connection into their environment. They want to, they want to see proof that it meets all these requirements. And that means you have to design the device and you have to have the right claims with the device to show that proof and that traceability and that body of evidence, which I think is still a little bit of the awareness challenge in the industry. Chris: That's for sure. I mean, if, if I take a step back and think about this, this breakthrough impact is the guiding light that we have or the, or the the vision or the mission or the purpose that we share. And then we're, we're going to try to deliver on that. It starts with deeply understanding the problem and knowing that it's worth solving and, and knowing what the ideal solution would be and developing criteria for the ideal solution. And in Medtech, you know, that that includes what's going to, how we're going to change and improve the clinician's workflows? How you're going to change and improve patient outcomes? But there are a host of other things and you know, we'll see, you can look at the Stanford biodesign program for a set of filters that you should use and screen your innovation and can you move it forward? And it relates to things we talked about, reimbursement, regulatory, IP, things like that. We think about cyber security, it used to be kind of a nice hack for your first generation product to be unconnected and inaccessible to the user without tools. So if we could say, look, we know cyber security is important, but for a first generation device, we're just going to make it not, not available and open to the outside world. Well, that causes a problem because you just mentioned that we have to understand the customer and the, the value we need to bring today, um, frequently, maybe the majority of times, is going to relate to devices that involve hardware and software that are connected to the outside world to deliver the value of the impact. If it's connected to the outside world and it's needed by the customer, then cyber security comes as a, as a mandatory requirement. If we decide that we want, if we had capital equipment, for example, and we needed to do things like software upgrades, whether it's in the field or in the software upgrades are done via the cloud, and we also are triggering the need to bring cyber security to the forefront. So, in our development, Christian, a lot of times in the very earliest stages when we're thinking about the configuration or the architecture of a product, we will look at some of these requirements, standards, testing, things that we need to verify and validate. And we'll make sure that our design choices make it easier to do that well. And so I, I mentioned electrical safety, we can look at a number of other areas, but that's a great example of making sure that we get a design review, making sure that we make good choices. And I'll just say that, um, I come into this podcast fairly naive to cyber security. I've worked on projects where we've had to prepare and submit to FDA on cyber security, but I am far from an expert in that area. And so one of the things that I wanted to think about is we move forward and, and vessel moves forward with our clients and helping them aim for the proper target and from the beginning make good choices is what we should be doing and thinking about with cyber security at the architecture stage so that we make good choices. And I'm just curious to learn from you when, when I join this conversation, what's some of the key tips that you have for folks? And also, honestly, everybody loves a good story and we learn a lot from, from failures and mistakes of others. I'm curious if you've got any examples of, you know, let's say you're developing a piece of capital equipment and it's got an embedded hardware with, uh, with hardware with embedded firmware like a micro controller with a, with a motherboard, a PCB, choices you make that, you know, say, let's say this sounded like a good idea at the time, and I would just wonder if you've got any examples of where people put themselves into a jam on, on cyber security without realizing it. Trevor: You know, I think it's something that, it's an especially easy situation to find yourself in. Cyber security comes across as uh, the way I usually like to put it is as an exploratory process more so than a prescriptive process. So if we're looking at most regulations, most standards, how a product needs to be, well, there's an acceptable tolerance and there is an unacceptable level. Cyber security, there is a lot that goes into it. You don't really know what the risk in the product is going to be until you started to test it, you started to model it, you started to analyze it. And even those risks once you realize them, they can be wildly different from your expectations. And so, it's, it's hard to have, you know, a descriptive set of, you know, these are the things that you need to do. This level of control is good, this level of control isn't. When you're talking about some situations where someone gets painted into a corner, the biggest thing that we see is a lack of preparedness around just how much goes into cyber security, but from a technical perspective, one really big thing, and if you were to pull up any thing as main takeaway is what components you put into your code. So when you're pulling in all of these third party libraries, you're building out your software build materials. It's obviously an extremely important part of the submission. It's the FDA's favorite thing to try to harp on recently. That is a situation where you can, it can be a product killer. You can integrate this critical critical component. your whole code base is basically wrapped around it, and then you step back and realize, wow, there are security holes in this and the vendor's not going to fix them. They're not, you know, they're not a medical company, they aren't subject to the same regulations. They're saying, you know, hey, this is on you for picking that. So, stepping back and having a process for vetting any components you're bringing into your product is probably, it's, it's going to make development more complicated. There's no way around it. Having a subset of what you can choose is going to be harder, but it's going to allow you to build a much, much more effective product. And truthfully it would clear out a very big majority of a lot of the problems that we're seeing come back relating to some of these early decisions. Chris: Okay, Trevor, especially when when we prototype and we want to make something fast, we reach for something that's at hand, even in software modules or components as you're talking about, something at hand, something we're we're we're used to working with, we want to make something work quickly. Sometimes that gets frozen into the, into the design, uh, over time. How does, how does someone who's working at the, from the earliest stages look at software components for cyber security? Like is there any type of resources available that would let you understand the, uh, threat profile might be a specific cyber security term, and that that might be a wrong usage of it, but the, but the level of of concern that you would have about including it as a, as a part of your product, how could we, how could teams that I work with look at that and make the choices when they're just trying to make a first learning, learning prototype and see if they can get something working? Trevor: I think part of why it's such a common problem is it is really hard. And, you know, that exact situation where if you want to see if something works, you're trying to just get validation for your idea, understanding if you really do have a product market fit, do what works. Don't worry about it until you're moving towards these steps. But that situation where it's baked in is what becomes difficult. So when we're really looking at what things the FDA is concerned about and what things the manufacturer needs to be concerned about. If I were to pick two, it's are the suppliers for that component still updating it, have they said when they're going to stop? Chris: Okay, so end of life, okay. And the level of support. Those are two things you should start with. Now, it's really hard. Well beyond 99% of open source components do not have a published end of life. Well beyond that figure. It is 99 point probably 999. It is a very, very small subset that do have a published end of life date. If you are on a service contract with someone, let's say Microsoft, you have Windows 10 on or Windows 11 now on your device. With Microsoft is going to publish when they stop supporting that. So trying to find that information is really hard. And if you can't, that doesn't mean you need to stop entirely and you shouldn't use that component. It means that you should just pause and think, where are we using this? is this going to be in a safety critical component? If we're using a component that has not been patched in two years and might have some known vulnerabilities, likely isn't going to receive any support. We probably should not use that in a class C component of the device. If we're using a class A component, maybe it's not going to be as big of a deal. So understanding what is that worst case scenario if something were to fail in that component and if that failure were to be as severe as it could. And that lets you do an understanding of how much due diligence needs to go into this. Do we really need to go track this down or maybe even create our own component for this high risk profile. There's a good chance you should lean in that direction. For a lower risk profile, you might be able to peel back a little bit of those controls. And so just having an understanding, uh, you know, mapping into your specific device is going to give you the most effective results. Christian: Well people do threat modeling all the time, they probably don't even realize it. I think I think in in cybersecurity and with MedTech we we overly complicated it, but like, I do threat modeling in my condo. I know where my doors are, what kind of locks they have, I know the windows, what kind of locks they have, I know the entry points, I know where the cameras are. So I I I know where somebody could break into here and I have the appropriate defenses, right? It's kind of like the same thing. We know we go park at a parking lot in the middle of the night, we have a nice car, maybe we should park under a light that's actually working, right? Or maybe we shouldn't park so far away by the garbage can where somebody can easily break in the car. I mean, we I think we naturally do a threat modeling, but we overly complicated it sometimes with cybersecurity, I feel like. Trevor: Yeah, I think that's a great point about threat modeling being something that you do. It's, and it makes sense. It's Christian: Well it's something I do. I'm not sure it's something everybody does, but I'm Trevor: Well, Christian: I'm hyper vigilant about these things for some reason, maybe it's because I used to be in the military, I'm not sure. So yeah. Trevor: You know, maybe even if it's not to the same extent, like we can take the the apartment example. So I can look around my apartment right now and go, what are going to be the entry points? there's a window there, a window there. I'm on the third floor, so I'm probably not that worried about the windows, I leave them open all the time. But I have a door right here. I don't have a lock on this painting. I don't have a lock on this wall because I wouldn't expect someone to try to break through the wall. That's not a very big risk scenario. It's not a real threat that you would expect. Christian: With some things what do you have to offer, the, what's not in there. It depends on what what what you may have that's of value, right? That's the other part of it. Trevor: Depends on how how valuable the painting is Trevor. Christian: I think Christian's saying if there was valuable enough people would come through that. Point taken, point taken. So you have a lock on your door. Not for this painting. Chris: Let let's go one level more specific, right? which is um, I like what you talk about. So, threat modeling is a first step and understanding, understanding the situation that you have and and how you're planning to do it and thinking about the risks or the threats from cyber security. I I draw an analogy to different elements of risk analysis that are been formalized for quite some time in medical devices. And maybe, maybe the the best one to talk about is a bridge or or you know, leading to more understanding of cyber would be around use risk analysis and usability. because we we have to understand how the device is used. You were talking about about this a little bit for a use risk analysis, we look at the tasks that are done by the different types of users and we look at the look at the places where there can, uh, they can go wrong and we can have harm. So, so go a level deeper, um, if I want to sit down with a piece of paper and a pen on a single page and and draft a threat model for a software containing product that I want to develop, what does that look like? The simplest version but specific to a product? What is the threat model? You mentioned connectivity? You also mentioned what you built into your product itself. What are the nuts and bolts are like a 1, 2, 3 on how to put a threat model down in the earlier stage while you're still thinking about your product? Trevor: So I love this, and I think that tying it back to a risk analysis from a safety perspective is a great way to think of it. This is where we start to see a different process though. So, threat modeling and there's the Miter playbook for threat modeling medical devices, which is seen as the global standard for this process, and it's going to ask us four questions. What are we working on? What can go wrong? What are we gonna do about it? And did we do a good enough job? And so really breaking it down into those four questions. What are we working on? Can we really understand everything about this device? So, you know, what are your entry points? What are you using? And then mapped back to each of those, what can go wrong? So when we're doing all these assessments, it should be from a worst case scenario. Uh, this factoring in, you know, how likely, and I'd put a little astrix next to the next to there so I can revisit that and then what the impact of exploitation is going to be. Now the reason that I hesitated on likely is this is where we're going to branch away from a safety risk assessment. Risk assessments as per ISO 14971 are done on the likelihood of the probability of an X of something going wrong per X uses. Cyber security risk assessments are done based on the criteria that must be true for X to happen. So, going back to the lock on the door example, would you you would say someone could not access it remotely. Um, and so you need physical access. Someone else needs to interact with it. I need to unlock the door if someone's going to open that door. So this, you know, having a user interacting with it is going to be adding more complexity. Are there factors outside of the attacker's control? Well, not really. The door's locked or it's not. It's not like sometimes the lock is the door is locked and they don't know what the timing is. So these are the types of questions that we're asking to get the criteria. It's instead of a likelihood. Uh it's actually explicitly disallowed to use probability for cyber security risk assessments so that we can have a bit more of an exact answer. So when we're doing the assessment, we're following a similar process, but we're looking at it through that less. Going back to those questions, once we understand, you know, what can go wrong, it's a matter of thinking about the controls. If we say, well, a worst case scenario here is, you know, we have a, a pax system and someone rips out all of these medical records. Right, well, what can we do about it? can we encrypt all the medical records at rest? Can we encrypt them in transit? How can we protect access to that pack system? Does it be to be on the internet? Can we hide it internally? And that's going to start these conversations on where to go. So it's a very much top down exercise. You start with just the device, what are the concern points on the device? What are the concern points with those concern points? Chris: Thanks. That's very helpful. Like a lot of um, sign posts to follow in that area. Christian: Awesome, and I'll end with one thing. We were talking about the FDA and I think Chris you used the term us giving the innovators kind of a hard time with cybersecurity from a business risk perspective. Blue Goat Cyber works on a product, we want to make sure to the best of our abilities and the best of our due diligence that that product is safe on the on the market that somebody can't hack into it. So we're naturally going to do probably above any regular wants or is it expects because it is super important to us and we're putting sort of our stamp of approval on that product as well. Chris: I love it and it's what we all do is put the patients first in our industry. So I appreciate that. Thanks guys for having me. Christian: Yeah, thanks Christopher for being a guest and thanks everyone for tuning in. I hope you found this episode of the MedDevice Cyber podcast valuable and hope to see you on the next one.