How Vulnerable Are Your Medical Devices Cyber Device Global Risk and Security Summit

Hello and welcome, everyone, to today's webinar. I'm sorry, Cyber Device Global Risk and Security Summit with Eric, Mark, Richard, and Lena. I'm going to introduce them in a minute. But before we do that, a couple housekeeping items. Let's see if I can get a more interesting screen to show up. Sorry. There we go. That's better. Um, so the housekeeping items. If everybody would take a moment and say where you're dialing in from, that would be awesome.

And you can just put that in the chat. Feel free to use the chat function or the Q&A function during the event. We're going to try to get to all questions. We've left a little time at the end of each presentation. And four questions. So, you know, have lots of questions for the speakers. This is a very rich and full topic, risk and security related to cyber devices, timely. And we are very honored to have all four of the speakers, Eric Henry, Richard Koch, Lena Ramirez, and Mark Omo.

Thank you. And we're going to take a moment to introduce ourselves and your background. And then we'll pass it to Richard. Sounds good. Hi, everyone. My name is Eric Henry. Currently work for the law firm King and Spalding. I'm a non-attorney advisor in our FDA and life sciences practice. Um, I joined the firm about five and a half years ago, um, after a little over 30 years in industry. Um, working for the law firm. Um, I'm a law firm. I've been working for a lot of the larger medical device players running technical organizations and regulatory compliance and quality organizations, uh, for those companies, uh, globally.

So, um, I've dealt with a wide variety of, uh, enforcement and, uh, uh, remediation and compliance matters with the course of my career. Um, both large and small settings. And, uh, now I'm just helping people solve problems, uh, every day, uh, through my work at the firm. So, uh, uh, I'm really glad to be here and I'll pass it on to our next speaker. Hi, buddy. I'm, uh, Richard Koch, Australian in Switzerland. I'm actually a ex CFO and supply chain director. We're now focused on, um, efficient and high velocity design and development operations cloud systems. They take a similar sort of operational approach.

We've learned in, um, large finance and supply organizations to, um, our employment and development. Uh, I also develop my own medical device software. I have an ISO 13485 certified, um, company, and I have a private membership group for medical device software professionals, uh, with a personal aim to support medical device software professionals to help them with their challenges. And as an industry produce better, compliant, performing, safe software. So that's me. Thank you. When work. Hey, good morning. Hi, Mark. Hi, Mark. Good morning. My name's Mark. I'm the engineering director here at Marcus engineering.

Although I'm not the mark in Marcus engineering. Um, we, uh, uh, we focus in product security, especially medical devices, mainly high security, high risk systems. Uh, we like to help people, uh, take their devices all the way from, from concept to market. I have a background in cybersecurity and engineering. Uh, I previously, uh, uh, worked at Google and Raytheon. From places like that. Oh, and Lena. No. Good morning. My name is Nathan Ramirez. I own regular. I own lucid array and I support com customers, especially from Latin America to reach global markets. Including the us and where you based.

I'm based in Belgium, by the way. Yes. I'm based in Belgium and Richard, where are you based? Uh, based in Switzerland, Mark. the U.S., Tucson, Arizona. An error. Yeah, I'm also in the U.S. My business card says Washington, D.C., but I work out of my home in Cleveland, Ohio. Ah, welcome. And I'm Sean Smith, publisher of MedTech Leading Voice. If you're not subscribed, please subscribe, medtechleadingvoice.com. And now we're going to get started with Eric Henry and his presentation on what's going on in the U.S. Hey. So, again, really glad to be here

to speak to everyone. We're going to just spend a few minutes talking about where the U.S. is in terms of its regulatory framework and landscape in the cybersecurity space. And a little prior to that, just a brief discussion about how cybersecurity can be defended in inspections and audits and what that means in terms of the design controls work that you're doing. And then, again, then we'll jump really quickly into how the regulations are driving some of that activity. First of all, I think we need to be clear that cybersecurity, most of the cybersecurity activities that we're involved with are a part of design controls

and risk management. Obviously, there's a huge post-market aspect, but there's a lot of work that we need to do to get to this as well. But much of the controls that we've put in place around cybersecurity are done so as part of the standard design controls and risk management processes and standards that we use and have in place already. Note that in both the IEC 62304 standard, which is the international standard for software development for medical devices, as well as the health and safety standards, which is the international standard for health software standard, IEC 82304-1, and sort of the how do I do agile scrum

or iterative methodologies and still comply with these standards, AEMI TIR 45, all of them make reference to security or cybersecurity work that needs to go on during the life cycle and relate it to that risk management and design controls work. There are several documents in the United States or that the United States recognizes through FDA's consensus standards program that have cybersecurity mentions. We obviously have the content of pre-market submissions for cybersecurity, the pre-market guidance in the FDA. There is a Health Canada guidance as well that derives a lot from some of the US sources,

but kind of goes its own way as well. We also make leverage to the FDA to an insignificant extent, the IMDRS medical device cybersecurity document, as well as what you'll see in a few minutes is one of my favorite IEC standards around cybersecurity, which is 81001-5-1. And I'll talk a little bit more about that lately or in a few minutes. Notice that on the left side, this is just a standard V model kind of software life cycle, very waterfallish. On the right side, using this sort of the AMI-TI R45 standard is a way to comply with the regulatory requirements and still use iterative methods. And I put these up here just to illustrate the fact

that we would, and this IEC standard that I mentioned lastly, it gives us a way to do that. We can drop all of the regulatory, all the cybersecurity activities that we have outlined to execute in our companies inside those boxes that already exist in terms of software design control. And in fact, one of the best ways to defend your cybersecurity practices within an inspection or a notified body audit is in fact to map those activities to the standard design controls models that we already have defined within the existing quality system regulation, 21 CFR part 820.30,

which is the design controls interface. And you'd have to do that anyway, because those regulations are still very much in place. And we obviously, many of you may know that the FDA is getting ready to migrate from its sort of standalone quality system regulation globally to one that's harmonized to ISO 13485, which is the global, which is the international standard for medical device quality systems. But in either case, we have to map to those sort of traditional design controls and product life cycles and product lifecycle steps. It's important to take the also not only to the regulatory requirements within the regulations, but also if there's global guidance or standards that you can

map to, that is also a great way during an inspection to reflect that mapping. And I would recommend even having that mapping either built into the quality system or available for presentation in the inspection or audit so that they can see that the credibility of your work really rests not only on your own thinking, but also on these internationally recognized documents and obviously the U.S. requirements as well. The other thing I would do is to say that any documentation that you create around cybersecurity should be incorporated into the design history file. Now that name will go away on February 2nd, 2026 in favor of the design and development file

in ISO 13485. But whatever you call it, whatever that bucket is called, I would take those cybersecurity documents that you create and drop them into that lifecycle library that constitutes evidence that you have followed those design controls and risk management processes that you've defined in your quality system. This next little last one here, the second one from the bottom, is not as big of an issue as it was even just a very few years ago. The FDA does have dedicated professionals now that are focused on cybersecurity, both within the Digital Health Center of Excellence, as well as in the Office of Product Evaluation and Quality,

or OPEC, within its different review teams that are called OHTs. But you still may find yourself in many instances because the investigators themselves that are there in your facility in inspection are not necessarily well-educated in cybersecurity principles. And so the tough thing with a regulator is to educate them without knowing that they're being educated, because they want to be, they want to seem and feel authoritative and let you know that they know what they're doing and that their word is law. But there are ways around that. And obviously, there's a lot of people that can help you sort of make those nuanced sort of approaches.

And finally, we are seeing a bit of an uptick, although less so after the COVID days in remote inspections. So be prepared to address that as well. Very quickly, there are some common issues, and I'm assuming that even with the other panelists that are on this call, that they're going to see some things in here that look pretty familiar in terms of what regulators typically find when they are doing audits or inspections, not having the right documentation related to design controls in cybersecurity, not handling encryption and authentication. Those seem to be, those seem to rise to the top of things that the FDA especially identifies both in inspection,

483s, which are their list of observations during an inspection, as well as the deficiency letters that they publish after or as part of the submission review process. Not having adequate links between vulnerability assessments or threat models and safety risk management is also a huge issue, as well as not handling in a post-market space cybersecurity patches and reflecting that those are part of the design controls process. Even if they don't drive a new submission, they have to be at least recognized in that vein. And then, I think, as we're looking at the next slide, I think we're going to see a lot of

data that's going to be available in the future. And then, I think a failure to address cybersecurity for off-the-shelf software. I am currently dealing with that with a client that has a deficiency letter where they have rather innocuous off-the-shelf software in place, but the FDA is very much wanting some fairly sophisticated cybersecurity documentation from that off-the-shelf provider to move forward with the review. Also, look at every possible entry point into your device, because the FDA will start asking you to do that. And then, I think, the FDA will start asking you about the ones you missed, such as wireless, BLE, physical ports,

and other kinds of interfaces. And they're going to want to see that in threat modeling and the software and cybersecurity architecture. And finally, and this is a big one, don't put as a risk mitigation in your threat model that you're going to rely on your software, your system sitting within a, quote, risk-based system. And that's a big one. And that's a big one. And that's a big one. So, when you sit in a, quote, safe clinical environment or health IT environment, you should assume that whatever environment you're sitting in has already been compromised, and the burden is on you to provide protections for your own system and your own device. And the

FDA, frankly, will reject, in almost every case, your argument that sitting in a clinical environment or an operating environment with good protections in place is a sufficient mitigation for your system. David Robertson So, with that, let's get to the core of what we're going to talk about today. David Robertson Mark Thank you for joining us. David Robertson Mark So, with that, let's get to the core of what we're going to talk about. David Robertson Mark So, with that, let's get to the core of what we're going to talk about about today, which is what's out there in terms of the cybersecurity literature in the U.S.

First of all, from the FDA, going back to 2005, there is a cybersecurity document for network medical devices containing off-the-shelf software that we don't see a lot of reference to nowadays, and frankly, a lot of the burden there is put on the hospitals and hospital environments in collaboration with the manufacturers. 2016, FDA published its post-market guidance, post-market management of cybersecurity in medical devices, and that talks a lot about one of the big content elements of that is participation, number one, treating patches, cybersecurity patches that are routine in a manner that does not require a submission or any significant change notifications to the FDA.

And secondly, if you participate in information-sharing organizations such as ISAWS or ISACs, and you sort of reveal vulnerabilities that you might have, the FDA has promised not to use that as an enforcement mechanism in your company. There is, in 2021, a document that was Best Practices for Communicating Cybersecurity Vulnerabilities to Patients, which was a good way to handle your coordinated vulnerability disclosure program. There is a Refuse to Accept Policy in 2023 that was published around cyber devices. This primarily was driven by the omnibus bill in December 2022, where Congress placed as a

statutory requirement the inclusion of software, bills, and material into submissions and design history files for or into submissions to the FDA. Congress gave FDA. The authority to require that. So that is now not just a regulatory requirement. It is a statutory requirement. And the FDA has basically said, if we don't see an S-bomb, we're not even going to start the review process with you. And finally, we have the premarket guidance that was republished in 2023. Originally, it was 2014. And that has a significant number of new requirements. Big ones include things like cybersecurity archival.

And then, of course, the architecture and other information that has to be included in the in a submission that previously would have been much reduced in terms of the amount of paperwork or amount of documentation that's required. And what we find is a large number of details that are in both the main text of that guidance as well as in the appendices that for each architectural requirement have to be in place. And then, we have a host of non-government guidances and standards that are recognized either on a consensus basis across multiple stakeholders or within specific governments. Amy, the Association for the Advancement of Medical Instrumentation, has published two guidances back in 2016 and 19, respectively, handling risk management and post-market.

Those documents actually, especially TIR-57, I find are referenced even though Amy is a U.S.-based organization. Amy, this is a special case where we have a post-market diagnosis. This is important because it's a story, and I think we also have a more present case if you will of a medical industry organization, because of its collaboration with the FDA and the creation of most of its documentation, there are other global standards and guidances outside the U.S. that tend to reference the the AMI documents. We have an SW-96 guidance, which is a standard for medical device security. For medical devices.

a principles and practices document for cybersecurity. They also address medical devices and SBOMs or software bills and materials. IEC 60601-4-5 talks about safety related to technical specifications and security. We have a UL standard 2900-2-1. I may get in trouble for saying this out loud in a public forum that's being recorded, but you can basically ignore that standard. I don't know anybody. I know some authorities that do recognize it, but my information has it that the guy that wrote that standard and maintains it actually left UL a few years ago and they've not replaced him. There is no intention to update that standard and I don't

know of it driving any real regulatory requirements anywhere. It's pretty high level. There's a hospital organization that collaborates with medical device manufacturers as well. So another industry organization in the U.S. that published a joint security plan as well as some model contract language for cybersecurity. MITRE, which formerly was MIT Research Engineering, now I think it just goes by MITRE and pretends that doesn't stand for anything. They started off doing a lot of Department of Defense work, but have moved into a much broader commercial set of high technology types of work and projects, along with the Medical Device

Innovation Consortium published. And then finally, I have an underlined, bolded, italicized IEC 81001-5-1. This is sort of the if you don't follow anything else, follow this standard because it overlays on top of task by task or box by box on top of the IEC 62304 standard, which is, again, our software device standard for software development for medical devices. It lays on top of that standard so that you can continue to follow that IEC 62304 standard and drop cybersecurity activities into your existing SDLC or software development lifecycle, and you're good to go. You don't have to upend your quality system to be able to make that work.

And finally, what I want to do is go over just real briefly, if you were to collapse all of those documentation into major themes, what do I see across all that documentation? All those documents that will take you ages and ages to read. Are there some things that are common? And yes, there are. I listed nine here. Go over them very quickly. First of all, in risk management, that is a common theme, doing good threat modeling, good vulnerability assessment, and linking that to safety risk management where appropriate. Those links overlap a little more than they used to because the risk management standard within the medical

device industry, ISO 14971 in 2019. Redefined harm to remove the word physical from that definition and stated three times in that standard that they did so, so that they could incorporate data privacy issues as harms and subject to the normal risk management process. So you may find yourself now with a little bit more overlap there. Software bills and material, sort of the recipe list of what's in your software, both that you've developed and that you've incorporated from outside your organization. And then you use that list to then keep constant eye on vulnerabilities and things that you need to

mitigate from a cybersecurity point of view. I haven't seen Mark's presentation, but I assume we're going to talk about SBOMs just a little bit when he gets into things. Also, a requirement for cybersecurity requirements within your design process is common across these documents, as well as in the verification side to make sure that you're doing effective assessment and evaluation against those requirements. And you'll see specific requirements. So for example, you'll see a lot of references, especially in the new FDA guidance, to things like penetration testing and fuzz testing as mechanisms for cybersecurity testing.

There's a heavy emphasis in a lot of the literature around monitoring. Post-market, there are multiple now databases of vulnerabilities that are out there. There are these ISALs I talked about that where this can be communicated. as well as internally just having logs of activity within your own system that can be used to monitor suspected malicious activity. The next thing on the list here is a coordinated vulnerability disclosure. This is a process in place by which you determine how, when, under what circumstances you will notify regulators, your customers, the public, other stakeholders, both internal and external, when a vulnerability has been discovered, either in theory or academically or through research or through your own verification or as a response to an active breach.

Information sharing, which is sort of the title. A side to this monitoring activity and vulnerability disclosure is also a heavy element within all of these documents. Again, participating in information sharing analysis organizations or ISALs, CERTs. A note that anything you share in those documents is exempt from the U.S.'s Freedom of Information Act, which is a means by which you can get government documentation or documentation of the government possession for the asking, unless it's criminal. And information sharing is also a massive part of the identification process and has been using it to gather the greatest protection necessary for the claims against people under complex national security law.

There are consequences associated these organizations are classified for national security reasons or other such reasons. And they will say that if you share information in these organizations that the FDA will not respond to a FOIA or Freedom of Information Act request for that information. So, you are protected there and again, they will not use it for enforcement. Next to the last thing on here is obviously having a, This is common across all of literature You need to have a plan for how you're going to do this. You need to lay out response teams. I know outside the U.S., I think it's in the NDCG guidance, they get very specific in the European Union about what roles should be in such a team.

But even in U.S. central centered documentation or documentation referenced by the United States, there is a mandate or a recommendation to have that plan, have these response teams defined and a good process for how you're going to respond and mitigate these issues. And as part of that process is the last item on my list, which is to effectively address vulnerabilities, both in a proactive way where you've identified them as an outcome of the monitoring program that you have in place. Any testing that you've done or as part of these information sharing organizations or in a reactive way where you've had a breach and you need to react to that breach in a timely way and then close that gap.

One thing to note as far as addressing vulnerabilities here is if the vulnerabilities are being addressed as part of a routine cybersecurity patch, the decision tree within the FDA's 510K guidance for changes. Will typically exempt those patches from requiring a new submission in the 510K program. So these are the common themes that I see across all that list of literature that you saw on the previous slide. And with that, I'll end this. And Sean, I'm happy to entertain questions right now, but we can also just move on to the next speaker and that'll be okay to go off mute, I think.

There was an interesting question from somebody. You said, considering the vastness of this information, what are a few documents that they should focus on? And while you're contemplating that, I'm going to go ahead and launch your poll question. Sure. Are you seeing the poll question? Yep. Okay. We'll let that run for a minute and a half while you're... And all of you, if you had a favorite document that you would direct somebody to around cybersecurity, what would it be aside from this webinar? Yeah, I would say from my standpoint, from a process point of view, I would point to this IEC 81001-5-1.

I would also say that from threat modeling, which is so endemic to being able to understand what cybersecurity protections you need to put in place, how to mitigate vulnerabilities and the chance for exploitation of those vulnerabilities, the MITRE MDIC threat modeling playbook. The threat modeling handbook is a fantastic one. Anyone want to add? I'll definitely echo the threat modeling handbook is a great place to start for people who are unfamiliar with it. And one of the things that we see a lot is people who don't understand the guidance because they haven't read it because they're afraid it's so dense and difficult.

It's really not that bad. And if you follow every step in the guidance, you're in a good spot to submit your 510K. And if you don't... Then you're not going to be able to get it approved. It's a great place to go and really digest and understand. They have a great appendix that outlines every single thing they expect to see. Okay, great. So let's go ahead and end the poll. Share the results. Are you seeing the results? Great. Okay. So 36% yes, 38% no, 26% uncertain. I think really the 510K is where the rubber meets the road for this new legislation or new regulation.

When did it go into effect, Eric? April? The new regulation for QMSR, the quality system regulation? The new 510K requirements in E-Star 5.0. Oh, gosh, I don't know. Yes, I think that's right. But I'm not sure. I'm pretty sure it's April of this year. So really a lot of people don't have... There's not a lot of track record with this. So I think it's going to get interesting. Shall we move on to Mark? And by the way, Sean and Mark, I'm going to type where I know... Where I can address some answers here in the Q&A. I'll go ahead and type some of those in and then people can add to them if they want as we go.

Okay, fantastic. Thank you. All right. So I'm going to go ahead and talk about it. Can everybody see it? All right. So I said I'm Mark with Marcus Engineering, and we'll jump right into it. So this is what I'm going to talk about, but we'll just go and talk about it. So one of the biggest things is that the reason the cybersecurity regulation is coming now is not because the FDA really wants to process more paperwork or make it harder to make devices. It's because it's a real problem. This has been something that's been going on for a long time. And cybersecurity has been a problem for a long time.

And cybersecurity has been a problem for a long time. And cybersecurity has been lagging best in class in the industry because of the life cycles. And these are a whole bunch of real things that really happen. From pacemakers from Abbott that had to be recalled a half million devices because of vulnerabilities to both Medtronic and J&J had infusion pumps with serious vulnerabilities that had to get patched before they got out into the market. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right.

Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. you know in insulin pumps and fusion pumps those are the kind of the the poster child for uh these kinds of devices where they're carried around all day by people they're they're essentially consumer devices they're not in the hospital or something like that and they can if

they operate incorrectly they can cause serious uh harm or death and a whole series of capital equipment um critical infrastructure things like that are also at risk you know hospital networks uh you know even things like the pneumatic tube system if that goes down in a hospital you can show the delay and treatment and care can cause people lives it's hard to pinpoint that in any particular case but overall we can really show that these things are having a serious impact in the devices and the safety um so we're gonna start off with to understand like why are you know so people people are struggling in a whole bunch of different ways with this but i wouldn't under you

know we're not going to be able to answer all of your questions but i'm going to start off with a question that i've been getting a lot of questions about and i'm going to ask you to answer it and then we'll launch a poll question and let that run we'll continue to understand from you guys what kinds of challenges do you have in your organization with implementing the cyber regulations complying with it uh things like that and so the really the the main parts of cyber security regulations like eric said map to the way that we develop the rest of the device we have to be able to get to the right data and how are they going to do it what's every way that

someone can get into it and also what are they trying to get to are they trying to get to data about the people are they you know could they affect the operation of the device both could they deny an operation or could they cause it to operate improperly um or give bad data back to the users that causes the harm and then the next one is you having a secure product development framework as you develop your product just like safety it's not something that you just kind of add on at the end it's it's not a it's not a something that you can glob on or it's somebody else's problem it's everybody's problem through the

whole cycle uh if you can't just make a device safe right at the end and address it this needs to be part of the development of your device and this software company struggle is implementing a good framework understanding how it works and making sure that it's being addressed through the whole life cycle of the device one of the main outcomes of your development of your device is the s-bomb and the s-bomb is one of the most important parts of your of your documentation because you need to know what's in your device if somebody if you had a physical device and somebody and somebody said do you know every piece in that device you'd say of course you know we can look at everything we

had to buy every part we had to install it we know every single thing in that device and lots of people don't realize how much software is in their devices how much how many components how interconnected it is what's going on and that's why it's so important for you to just understand what's even in there what are all these components and how can they affect the operation of my device and then the the last thing is the post-market surveillance which people often neglect when they're doing cyber devices they're thinking about gosh uh you know we did all the great development we put it out there and we're done it's ready to go and there's a there's a large body of work

in the post-market surveillance you need to understand for every piece of third-party software did we find something is there vulnerabilities in software that needs to be updated that's the most important activity the next one is monitoring your devices to see is something happening to my devices um the in in addition to a whole flow down of other things coordination and vulnerability exposure understanding what's actually going on so my favorite analogy for cyber security and how it's implemented is home security so if we think about your home as a medical device you know it's a cozy place but it has some important features and every home is going

to be pretty useless with outdoors we have to have some way to get in and out to access the home to to use it and in i like to think about those is those are your entry points to your device those are your network ports those are your data ports those your wireless interfaces all of those elements are part of your home and then the next one is windows and i like to think about those as it's kind of like our third-party software components and third-party software components are bad they're actually really really good they help you reduce your time to market they're more secure than you can pop then you can generally design your own software you know when i'm building a home i'm

not a window expert i'm going to go build a home and i'm going to build a home and i'm going to go buy windows but i need to know what every single window is and i need to have all those windows locked um and so you know think about it uh you know our locks and keys those are uh you know kind of how we we want to prevent get only the right people into our home and that we do that by issuing people keys and putting locks on our door and we need to make sure both those keys are handled properly and the locks are appropriate and secure enough for our system um and then like we talked about our surveillance we need to look at every device in the out there

and see is something bad happening to a few of these or do we see bad things happening to a large subsection as i think about our alarm system where we're monitoring all the houses that are out there and getting information back from them to see are they being broken into and then the the last one is the safes so some our devices protect some really secure data some really secure functionality and we're going to be able to use them to do some of the things that we're going to be able to do and we need multiple layers of protection on that so that way we can prevent you even if you get in the front door we break a window we bulldoze down the wall there's still

protections between us and our most critical pieces of data our most critical pieces of operation and then we like to think about our hackers as intruders these are people trying to break in they range from people who are going to go jiggle all the doors and windows on your house and see if they're unlocked to people who are going to buy a house exactly like yours tear it to bits understand how to get in and then they're going to go and they're going to go and they're going to be able to break into your house based on that knowledge so uh you know like to talk about the s-bomb i won't go through all the elements here but um it's really important to know every

piece of software you have in your system you need to know what what what it's called what version is it uh what are the details about where it's from what software does it depend on and what software does it support like i said if you don't know all the windows in your house how can you possibly tell if they're all locked even the basement window down uh down in the back you know the windows up high you know the even the ones that you don't think people are going to get to it's so important to know every single component of your device every single place that people could get into their uh to your home and then

threat modeling is so critical um it's i i like to think about it just like your risk and hazard assessment where you're trying to understand both what are all the ways that people can get in and who is trying to get it um you're not going to try you're not going to be able to defend against you know nation state actors people with huge amounts of resources trying to access your device but you should be able to defend against people who come and knock on the doors people who are scanning the whole internet people who might pick up your device and put a little bit of effort into it to try to understand how to break into it and then

you also need to understand what are we protecting how are we trying to prevent people from getting into our device and one of the areas that is actually really important and people often neglect is you know third-party software is is really high up there one of the things is user factors so i'm sure everybody here has seen or themselves will write down passwords on sticky notes or use the same password for every device in the hospital or all kinds of things like that that's one of the most important areas to defend against is human beings the squishy parts are the worst part of any and then scrolling down there's physical access but then there's also the supply chain

which is actually really important because those people have even more than physical access they build your systems every component you integrate is a target and they may not be targeting you specifically but they might be targeting everybody who uses this component everybody who uses this system and that's why it's really important as part of the your device threat model and the next one is the risk assessment so after we understand all the threats to our system, how they can go, we need to do risk assessment. And I'm sure everybody's seen the exact same chart where impact and likelihood. And it's important to do this for

cyber devices as well. And really understanding what's the real likelihood and what's the real risk. Because there's a little bit different with cyber devices versus some kind of physical risk and hazard, which is you can have a systemic risk, something that can affect, gosh, if we break this one thing, which might be really hard, but we could get access to all 500,000 pacemakers, for example, that would change the impact from high to really critical, where if we could break any small part of our system, no matter how hard we can affect all our devices, that's an unacceptable risk. In addition to, like Eric touched on, data security, privacy, people's information is one of

the most important. things to protect as well, because that's actually what lots of cyber criminals want. Cyber terrorists, people who are going to cause havoc for the sake of causing havoc, sowing distrust, shutting down systems, are going to be focused on the physical devices. How do we stop them? How do we cause them to act inappropriately to cause physical harm? But cyber, lots of cyber criminals, organized crime, things like that, what they're actually doing is they're trying to understand how do we take data from our devices and turn it into money. We can take health records and sell them so people can use them to create false prescriptions, create false charges for

services to insurance companies, turn that information into dollars. And that's actually why it's so important to protect that information in addition to the privacy, security of our individual users. And that's why we're trying to understand how do we take data from our devices and sell them so people can use them to create false prescriptions, create false charges for services to insurance companies, And that's what is interoperability. Most systems don't stand alone. They're part of a larger organization, that might link into your hospital systems. They might link back to the Internet to provide

monitoring to, they might interact with other, you know, other components locally. You know, we connect, we connect systems together, like our beds, to the bed controllers, or our vital signs monitoring to our hospital system, we connect systems together, like our beds, to the bed controllers, or our vital signs monitoring to our hospital systems, those are all parts of systems that interact and at those interfaces is where we can have bad things happen we can't rely on the other systems perfect so nobody can get in and they can because they could say the same thing well we'll trust that you're perfect so nobody can get in and then

nobody's holding the ball every one of those interfaces is a possible way for threat actors to get in it's not enough to just say oh we're connected to a trusted system we need to actually validate and trust those interfaces we need to really understand what's going on between systems and how are they going to affect each other this is also part of a really important concept that they call that we call defense in depth there's not just one thing standing between the the bad guys and you just like our home we're going to lock the doors but we're also going to put our valuables in a safe we're also going to have monitoring systems we need to have multiple

systems that are going to be able to monitor and monitor each other and we need to have multiple systems that are going to be able to monitor each other and we need to have multiple systems that are going to have multiple systems that control each other and traded data so don't worry about just things that go wrong for hackers criminals to cause harm get data out do bad things especially without being detected and so the next one is third-party software and lots of people react to third-party software and say we will never use any third-party software and then we won't have a problem we're not going to integrate stuff because they have all these vulnerabilities

and in the reality is not these well trusted components have so many vulnerabilities they have so many reports of bad things going on because it's bad software and it's definitely not because you can write better software in-house it's because those things are been hammered on by the smartest people in the world trying to find cracks in the in the way if you were going to go design your own window you might think oh I've designed it really securely and people who are experienced are going to say well gosh you didn't have this this bar here so I can bump the window and pull it open or we didn't have mesh in the window so we can't just smash it

and those are things that developers of very large complicated software components do do and do have and when you develop it yourself the only difference is you don't know about those vulnerabilities so third-party software is really is something you want to rely on because it has been hammered on and has had all these things fixed and also it's somebody else's job to collect those vulnerabilities and fix them and you just need to roll it into your software but you need to actually do that you need to know what are all the doors and windows of my house are they locked and then continue to monitor hey if we see something happen if we have this vulnerable

component we need to update our software to address that continuously and so that brings us to our unresolved anomalies and it's where we understand that for some reasons we can't use the latest up-to-date software maybe the vendor is not issuing patches maybe we know about changes but it's going to take us some time to roll them out and understand and that's where you know you need to carefully document these these aren't things to be swept under the rug until they're fixed or understand you need to be upfront understand every single one of those you need to understand what their impact could be how they could be

how they could affect your system and then how we're going to manage that risk if we have one of our defense and depth layers that maybe isn't as strong as we'd like our system is still protected but if we lose all of our layers of protection then that's probably an unacceptable risk and it's really just about the same steps in our risk assessment is what's the worst thing that could happen and do we have other layers of protection that can keep us from seeing these risks occur and the this this is kind of a life cycle exercise this isn't a a one and done this isn't a linear step this is um you know we're going to go all the way from we're going to plan

our device we're going to do risk assessment threat modeling architecture so we understand what we're actually doing and how we're building it and how we're going to actually make a secure system and avoid those single reports of failure and take it all the way through the same steps we would go through for any medical device development you know we're going to develop it we're going to validate it we're going to uh operate the device then we're going to have our post-market surveillance just like any other operation any other development process for our systems and so our security architecture is really

where the rubber meets the road it's where we take our threat modeling learnings and our actual system design and we describe the architecture of the system what are all the elements that connect together with technical details what are all of the measures that we have protecting every one of those interfaces and how is data flowing through the system how are we connecting the system what are all the interfaces and how do we get in uh just like in our home uh you know not just hey we have doors and windows we're going to keep them locked those are the ways that people can get in is through the front door

or the back door or the side door well gosh our front door has a Kingston lock our back door uh has a Medico lock and we're going to distribute keys in this way to these people we need to to actually understand the details of what's going on so we can document and test them and when we implement those controls they need to be tested and certified that's one of the biggest things we see is uh gosh we're going to have a password protection or we're going to validate this interface is going to keep you from going in you know like our door lock we're going to issue keys to people and they're going to unlock the door but if we don't validate that those

protections are actually effective it's that they may not be so for example you might issue super secure keys with to all your friends and say gosh no one else can get in and it turns out that any key will open the door not just the keys that you issued we've seen instances like that happen where people implemented security controls they're like we're going to check all these things and it turns out that nobody checked all these things but it does happen to work in a secure state because nobody checks anything and it's it's one of those areas that people don't think to test is are we actually checking all the items we called out in our cybersecurity architecture and so the

architecture is the architecture of the security architecture of the security architecture of the security architecture views is how we communicate that to the regulators and how we communicate what we did how we did it and all those interfaces and they and the if you look at the FDA guidance they have some really specific ways that they want to see the views set up some really specific points that you want to hit and you need to make sure that you document every single one of those points how you're addressing them what's going on what are all the interfaces and all those protections that you hopefully designed in the

your system and the last one is testing and testing is not just validating your security controls it's not just validating your SBOM it's also doing things like there's static code analysis there's dynamic code analysis there's penetration tests just like if you were going to build a home when you build your house instead of saying gosh I'm a house builder I think it's secure well house builders don't have a lot of experience breaking into homes they may think that they've designed a really secure home just like software developers think that they've designed really secure software but if they're not if they're not

skilled in the art they don't know all the best practices they don't know all the latest techniques they're going to have a hard time defending against people who do know that stuff and so that's where you need experts specialized experts to come in to do penetration testing to do code reviews analysis and look for all those weaknesses just like a if you're home builder you might think gosh I put all the doors on they're fully secured with locks there's no way I could get in and you talk to the experts you're the expert intruders the expert hackers who are going to come and evaluate your security and the first thing they say is well gosh you put the

hinges on door side out I pull those out and your your lock is completely ineffective it's really important to have people who are skilled in the art understand try to break into your system and review even briefly is going to cause is going to help you much uh pay large dividends in designing secure systems so um oh and take some questions here um you know but I want to I want to reinforce the you know the importance of the s-bomb because that's really one of the core things that you're protecting is do you even know all the parts of your system that's where the number one vulnerability is is people come

and they knock on all your doors and windows and they find a window unlocked and they just open it up and get in just like for your devices they will run a scan see what's out there and they're like huh someone put this vulnerable component just connected to the network and they're able to break in using that publicly available information the number one way the number one risk for devices so there was a question regarding the s-bomb it said please suggest a best way to do the environmental scoring I could have no idea um and so the question is how do we do that from any of the speakers um yeah I think there's I'm not sure

about environmental scoring but there's a whole bunch of scoring around how you do uh vulnerability analysis and what's likely what's unlikely um and and how we like the the NIST standard for defining how secure your devices are so Mark I think this sounds almost like a CVSS attribute yeah that they're describing and so it sounds like they're applying CVSS scoring to their s-bomb elements right yeah and I think frankly the CVSS model defines how you do that environmental scoring within the model yeah they have a really good if you go read the standard for it it's really excellent you know very specific about how you score it and what you do let's see so someone

talked about likelihood um and and I would I would agree that uh there are there are very few exploits that are considered that I would say are unlikely um the you know the only things that might fall in that category are something like somebody your security I see is somebody decaps them reads out data things like that and even in that case if your device is can be if you can exploit every device in the whole market by doing that to one device that might that is still probably an unacceptable risk if you were going to say gosh is somebody going to do that to every device or one device particular that's probably unlikely

um the you know certainly scoring any software that we're going to write it perfectly is is not going to happen every every piece of software is going to be vulnerable in some way especially for a medical device for something non-trivial I would also Mark I'd be interested in your thoughts on distinguishing between likelihood in a safety risk management setting where it defines really how probable or how likely it might be that an event will occur versus likelihood in, say, a threat model where you're really looking at or a vulnerability assessment where you're really looking at exploitability.

Yeah, I think that's a really good distinction is, you know, for software, it's not you can't test a failure and test 10 systems and see if it breaks, you know, for a mechanical system. It's more about how likely is someone to actually put in the effort to exploit this, especially if we know a little bit about what that looks like. And also, how often do we see this happen for similar devices? You know, if you have third party software, we can see, hey, this piece of software. Has been worked on for a long time, has lots of vulnerabilities that have been identified and all the ones that are being identified are low, low impact.

You know, we can rely on that where your software doesn't have that same heritage. Let's see. So we have a question here about architecture diagrams for people who haven't worked in medical device software. And and it's it's really similar to. I think if you've done. Architecture diagrams for other software components where we identify all the bits of software and all the interfaces. In your system and how they operate together and how we defend against them, you know, in more detail, that might be gosh, we're going to have keys that sign the data that goes back and forth or we're going to have passwords that are stored in this way or protected in this way or we're going to.

You know, have a use some kind of. Form trust zone or hardware element to store our data. And really identifying it's really important to identify in your architecture. Where are the components that can cause harm, like the ones that interact with physical systems and where are the components that hold the data that people might want to get to your databases, your patient information, things like that, and how do they interact with the rest of the system? Very good. Do you want to advance the slide? Oh, sorry. Yeah. So yes. More some more links. And there's a lot more stuff that I didn't really think I kind of skimmed over in the slide.

So those will be available later. Okay. Well, let's move on to Richard and his presentation. Again, feel free to keep adding questions as we go. And we'll try to get to all of them. One thing that I'm going to mention is that if you would like a certificate of attendance, we will make one for you. But what I need you to do is put your name and your email address in the chat and say that you would like the certificate of attendance. And so name and email address in the chat. Otherwise, I have to go and look them up. And it takes a really long time to do that for 100 people.

So please do that. And in the meantime, we're moving on. Richard, it's all you. Hi, everybody. Thank you very much for being here today. You could be anywhere, but you're attending here, which is great. And thank you very much, Sean, for inviting me to speak. I've already covered this. But just quickly, I really do three things. I consult mainly in the area of cloud, SAMD, and related IoT devices. And more and more developing a specialization, what I call FireOps and DatOps. Which tries to fill the gap between traditional DevOps, which is more sort of deployment focused.

And FireOps and DevOps is really about coming down the V and reconciling and managing like hundreds, if not thousands of individual requirements and specifications. I developed my own software. You can see it there. It's not regulated yet. I'm self-funding. So it moves forward as I get money. But hopefully, the next 12, 18 months, I'll do it. And that's really important. And for me, because it's sort of my lab to solve problems for customers. So I think it's important for consulting to actually be the customer, not just come from a theoretical position. And finally, as I said, there's a snapshot for my website for my medical device software professional group.

And if you're interested, you can take a look at that yourself. Right. So what I want to do is, while this presentation focuses on Europe, I just want to send a simple... I just want to send a simple message here, because it all sounds complex, but don't worry. There's nothing special about the EU. Just focus on building high quality design control operations, your design development process, and you'll be fine. Sounds simple, right? So design controls. The way we move from requirements device is a little bit like a car on a road. As it goes down the design V, it picks up our passengers, shall we say, which are the bus stops.

So there's a lot of different ways to do that. The beginning of the road is the beginning of the next release, which could be, you know, if you're starting for your first release, you don't have anything, so you're starting from scratch, or you could be on release one to 100. It doesn't really matter. And the end of the road is the release. So, you know, we pick up our passengers. We go down the B. We've got the risk helicopter, keeping an eye out to make sure we've got safe passengers, the right passengers on board. And then with cloud software, we can actually run a loop on that between releases.

So we don't have to have everything at once. It doesn't have to be linear. But as we get into the further design control, we get our traffic lights. You know, so when we implement integrate, we can do that in iterations, in sprints, and slowly integrate our release through different cycles. But once we get to verification, we need to have a fully QA'd integrated release. We've got to have a fully QA'd integrated release. So, you know, in some ways, there's discipline, but there are places there for flexibility on how you want to run your design and development cycle. If we go to the next slide, if we look at a global device company, most companies have

global ambitions, global scope, which could mean that you could be registering in up to 100 countries. So given that the EMDR covers 27 EU countries, that could mean you could be registering in perhaps 1% of every country. That could mean potentially 70 other countries. So you could be deploying a cloud SAMD system across maybe 70 reins raised regimes on the upper end. So in some ways, the EU is just one in potentially 70 potential regulatory dossiers. And again, our wire ops, our quality regulatory operations have to be able to manage and reconcile a list of hundreds, if not, you know, single digit, thousands, global requirements,

regulatory requirements and other requirements. Now, These requirements also have to consider standards, guidance, state of the art and maybe other areas. And we've heard a list of the USA, we've heard from the other guys today. And in the requirement stage, these are going to end up in generally three types of artifacts. Our product requirement list, obviously our software development plan, and then also other sort of artifacts, which could be product requirement report. Regulatory strategies, documentation of activities, why we've chosen certain ways. So you can see even at the requirements level, there's really a lot to handle there.

But the message is that the EU is just another regulatory regime. Ultimately, you end up with one large cloud system, which can be configured and misconfigured for different regulatory regions. But it's overly simplified. You know, it's kind of one and the same. So the next point is, there's obviously a big difference between compliance and security. A regulation doesn't mean you're compliant. A regulation is a starting point, not an ending point. The ending point is your secure and compliant system, which is there to prevent breaches and do all the things it's meant to do. And security is really only achieved through the conversion of the regulation.

So the end point is, you're not going to be able to configure the requirements into a fit for purpose, state of the art and secure software system through your design and development operations, i.e. how you operationalize your design and your design controls. So while regulatory requirements are there to ensure system security, the requirements are really only the starting point. And we achieve compliance and security from how we move from those requirements to our state of the art system, the security design, how it's managed day to day to identify security. So we've got a lot of security gaps or active defense against attacks, you know, and it complies with regulation.

So we've sort of got this start with requirements. Go through, you know, our design controls, end up with the system, and then we can demonstrate compliance by coming back up. So, you know, obviously related, but different. So look at what the EU thinks. We can take a look at the introduction to the EU Medical Device Coordination Group, the MDCG, cybersecurity guidance. That MDCG 2019-16, revision one. And highlight just a couple of points. First of all, they identify here that cybersecurity is a new essential safety requirement. So you can see it first highlight. And for me, I think that's quite insightful.

And it reflects the awareness of the potential negative consequences of particularly cloud devices, cloud connected devices. Because when we think about a battery. Recall for a cloud system, especially if it's the S and D system, the batch actually could be the whole system, you know, in a regulatory regime, like in the EU and USA and Australia, wherever you are. And in worst case, it could actually mean a global recall or global shutdown of your system, depending on the severity. So with physical manufacturing, you know, you can be recalling a few devices, a batch, you know, what have you. But, you know, we cloud connected.

You can be recalling a few devices, a batch, you know, what have you. But, you know, we cloud connected. You can be recalling a few devices, a batch, you know, what have you. But, you know, we cloud connected. Like I said, particularly cloud S and D, maybe it's your whole business goes down. And I think device manufacturers are slowly waking up to this new reality. To the unique aspect of cloud S and D and IoT products that it could have on their business in terms of business risk, patient harm, and, you know, especially the financial cost if it all goes wrong. You know, these are 24 hour systems have to be up and running.

You know, God knows how many. You know, God knows how many customers or, you know, intended user on the system. And if something goes wrong, you know, this is huge risk. So, you know, the recognition that this is a new essential safety requirement is, you know, important. Good to see that our regulators have identified it. Secondly, if you look at the second step, they discuss manufacturers must develop products according to state of the art. Now, I don't think there's anything new here. But we'll take a short look at this later on how you can practically implement that. And finally, probably a bit duplicative here from what some of the other guys have said.

But risk management includes information security, quote unquote. And, you know, I've seen examples of device companies are moving towards, you know, IoT converting their on premise to IoT devices. And, you know, I've seen examples where their risk file is often more focused on clinical risk rather than a holistic approach. Or if they have a cyber plan, their cyber plan is completely separate from the risk file. And in my view, a more integrative approach is needed as a single cyber risk could result in many harms. You know, patient harm, it could result in data loss. It could result in, you name it.

And one side. And the other side is that the risk may have to be mitigated across the system, you know, through processes, hardware, software, facilities and people. And I really like Mark's house analogy. And, you know, we now have to really move towards a more integrative and like a one to many mapping as we move through from a risk to harm to mitigation. So these things get pretty complex and pretty quickly, very manageable. But, you know, obviously you need to know the tricks. And then just quickly on this one, the guidance points us to annex one of the medical device regulations, the MDR, which is the section that lists the general safety and performance requirements.

And we'll start taking a bit of a look at that. So here I've overlaid two diagrams for the MDCG guidance to give a more holistic view of the EU's thinking. And we've got at the high level in the blue, see Cybersecurity Act, GDPR, the NIST standard. I'm not really going to address them here. But just to say that. As a medical device manufacturer, you know, you need to look outside of just the MDR. And you need to look at more high level guidances. You need to be aware of these acts. And, you know, again, there's other acts, too. There's the GPSD, the General Product Safety Directive, you know, and I've had to do consulting, go to lawyers, my consulting career to look at impacts and the criminality of putting in Switzerland, putting a device on the market.

Fortunately, it can be covered under the Criminal Act. And obviously, we're not going to touch on. Any of that. But the importance is a medical device, putting a medical device on the market. There are many, many, many different regulations we need to be aware of. And then you come down from that, from these sort of general EU acts. We've got the MDR standards and common specifications. I've just got a couple of screenshots there from the IBDR and the MDR. And that lists, you know, things like the 14971. 3485 and other things. Pretty interesting to take a look at if you haven't already. And then we get to the main focus of the cybersecurity, which are these sort of green boxes.

And in the green boxes, in the blue, we've got this section, for example, 17.4, 23.4 AB, et cetera. And that's actually listing the clauses in Appendix 1. And the way they've grouped it is, you know, identifying. Basic cybersecurity concepts. As I said before, 17.4, 23.4, section 14.1, et cetera. And then, you know, if you look at the vertical bit, they've got a box there for secure design and manufacturer. Then it goes through verification, validation, acceptable risk. So, you know, some sort of quasi design control process. Ends up in documentation, information for use. And then we've got this little box in the middle, state of the art.

Which is really about the identification, implementation, and monitoring of state of the art requirements. So, you know, when you look at it, it's a pretty good document, I have to say. But like all of the MDC documents, it takes a little bit of reading, thinking, interpretation to really absorb what they're trying to say. Because it's still, I think it's like nearly 50 pages long. There's a lot of information in there. And it's, you know, really simple. It's a language. But to really, you know, master it and really adopt it, it requires discussion. And working out how to translate it into your, you know, design and development planning and operations.

So, we take a look at some of the InScope clauses. And forgive me for this. I've obviously tried to put too much on a slide. So, you know, this is a report from my JIRA, from my product requirements list backlog. And on this one, you know, they're all pretty standard. You've got things like reduced risk. You need a risk plan, foreseeable hazards, evaluate risk, etc. And, you know, again, it just goes to show that they've identified these clauses from annex one as related to cybersecurity. But, you know, these clauses are applicable to a lot of other parts of your product. So, you know, cybersecurity is really embedded into your product.

So, you know, cybersecurity is really embedded into your product. Due to the physical characteristics of your product, just like you've got a heavy object, a sharp object, a radioactive object. You know, that will be embedded in terms of your central requirements. Cybersecurity is obviously a critical part of the physical characteristics of software. But there is a section there. There's a few clauses there, which are probably more of what we might consider cyber requirements. So, we've got here the 17.1. 2. 3. 4. which talk about electronic programmable systems and they talk about things like reliability,

design and manufacture, minimum requirements for hardware networks, etc. And yeah, as I said, these are probably what most people would call more identifiable cyber requirements in the standard. But just an important point, if you read it without the guidance, you may look at these three clauses. There's a lot more than that you need to consider. And again, they're documented in the guidance. And again, the important point is to look at a hazard, a performance or a compliance issue that may result from a cyber security issue and you need to address it holistically. So I think if you go to Thailand,

they've got a saying, same, same, but different. It's a bit like that. There is a speciality definitely for cyber, but it cannot run completely separate and outside of your whole design development. So it's a bit of a different process. You need to do deep dives on it, activities, but it has to be integrated completely into your system. And we take a look at one example of state of the art. So again, this is from my technical file. We've got an example of a product requirement from OWASP, which is the Open Worldwide Application Security Project. And we're looking at their mobile application security verification standards.

So there we've got my naming for it, cyber security, strong cryptography, and the app employs current strong cryptography and use it according to industry best practices throughout their life cycle, including key generation, storage, and protection. So this is my editing of it. I haven't just copy pasted it. I've written it in a way that relates to the app, but effectively it comes from there. And you can see I sourced my requirement where it comes from. And you can see here on the right-hand side, my traceability from requirements, into specifications. And it's a longer list, but we use OAuth framework for our session tokens.

And if we go to the bottom, we're using TLS encryption for the data transport, our APIs from the front end to the back end. And we have other standards there on how we're using the tokens. So sign out revokes a token. We automatically sign out over a year. I don't know, Mark, if that's best practice, if that's too long or too short, but we are relying on a bit of time. We're relying on the amount of device security that the user has access to their device, the session persistent for the patient, et cetera. So, and again, some of these requirements will map to other requirements or specifications

for requirements and sign-in. So again, this is just a very short example on how you address state-of-the-art. And again, if you get asked by the regulator what your state-of-the-art is, what your state-of-the-art requirements are, this is one example of, you know, obviously many you have in the system. So summary, any company registering in multiple jurisdictions, you really need very effective design and development operations. Again, I call it DevOps, call it what you want, design controls, to achieve compliance by your design control process and mapping regulatory requirements into your release products.

So going from requirements to specs, to design into your code, and then back up again through your testing regime, QA testing, verification, validation, and making sure you've got full traceability that you can demonstrate from any point in your system up, down, across, how you're demonstrating compliance to these requirements. And again, cyber is just a subset of, you know, a whole lot of them. And you'll find that clauses from different regulatory jurisdictions will map to a common specification. So you go from requirements into specifications, you get this many-to-one mapping. So obviously there's a lot of duplication

from our regulatory regimes, which is good for us. There are certain variances. And, you know, if you're doing a US submission, you have to make sure that that regulatory dossier can be spun up through your design and development file so it meets the requirements of the regulator. And again, for EU, if you're submitting, going through a CE audit from the notified body, you have to make sure that your regulatory dossier is compliant. But, you know, for global systems, you need to be able to make sure that you've got one design development process. You can configure that to deploy to regulatory regimes

and you can spin up your regulatory dossier. And then the other one too, which I think is, I'll just throw it in there, for the speed, is that you need to have a very long design development cycle. So if you're in the middle of a cloud development, you know, traditional devices, you have a very long, you know, months, if not years, design and development cycle, you shut down your design and development file and you transfer to manufacturing and they have multiple batches. Cloud software doesn't work like that. You design once, produce once, and then you move on to the next design cycle. So you just don't have time,

don't have long development cycles, you've got very fast type ones. And, you know, as the other guys have pointed out, cyber, you know, you've got to have a very fast type ones. So you need to be looking at that on a constant basis. And when you're planning your next release, you need to be constantly reviewing your vulnerabilities, are there framework upgrades and, you know, vulnerabilities in your packages identified. And you need to be prioritizing what's in the next release. And then you're obviously, as you go through the sprints in the release, you know, integrating testing. So this is a constant thing.

And it's not one, it is one product, but again, it's across multiple regimes. And again, you know, where I'm sort of building my specialty is the operational side of doing that. It's no different to running a factory, except your factory is not having a standard bill of materials. Your design changes with basically every manufacturing run and your reconciliation, again, is, needs to be on top. But, you know, if your medical device companies can reconcile, you know, $20 billion of revenue down to the cent, we as medical device professionals, should be able to reconcile hundreds or thousands of requirements and specs and tests, right?

So that's where we need to go. We need to, you know, move to that direction. So to wrap up again, EU has recognized cyber as an essential safety requirement, which I think is a really important statement. And I think I've touched on the last one. Cloud products don't really behave like traditional devices. And cyber touches everything in software, but especially if you're, you know, if you're a software developer, you're connected to the internet, either, you know, through your cloud systems or through an IoT connection from the device. You know, cyber is important due to the physical characteristics of software.

And I think, you know, Mark has done a really brilliant job of describing that with his house. So a couple of questions, which I don't know the answers to, but, you know, if you're in the EU, the notified body has rights to do unannounced audits. You know, they can come visit me in my office, but they're not going to see much because everything's on AWS servers. So, you know, will they start doing penetration testing of my software as part of an unannounced audit? I find out when they say, hey, Richard, we did a pen testing and you've got a vulnerability. Here's your audit report. So no interest to see.

And another one that I think has been echoed previously is I'm not sure how the notified body is going to resource the cyber skills because they already seem to be having difficulty to find auditors with the appropriate software system knowledge. And the notified body, they're going to have to be able to do it. And they're going to have to be able to do it with the right software. And the number of cyber devices are going to grow. So we've already got emergency legislation to compensate for, you know, potential lack of supply due to the MDR. So what are they going to do for potential, you know, lack of supply?

I don't know. It's obviously we're in a transition point to stabilize over the years, but, yeah, it's a very interesting time for the MDR. So we'll wrap up there. And thank you. So, Richard, don't you think this is complicated, too, by the fact that a lot of these notified bodies are now, not only have they not been able to find the right software resources for cybersecurity or for software design controls, design development controls more broadly, but now they're looking at trying to do dual audits against both the MDR and the AI Act coming up. I mean, wouldn't you see this as this seems to me

like even complicating an already complex problem in terms of finding the right resources for high-tech devices? The short answer is yes. But what I would say it's also a good time for a medical device company to get on the market. So, like I said, I've got my own ISO certificate and I've been audited by a bond disposal expert, a couple of biologists, microbiologists, et cetera. And I do my technical file in Git. And when you show them Git or Jira, they cloud over and they kind of don't know what they're looking at. I don't do it on purpose. It's just an observation. So, you know, I would probably argue potentially,

and I hope my notified body is not watching, you can probably get away with a bit more now than you can in the future. But that said, you know, there's no freebies in this world and eventually they'll catch up. So, you know, there's probably a short-term opportunity to get ahead of the curve until the notified body catches up. You've got to catch up just before the notified body does. I don't recommend this. It's not advice, but, you know, you should always be compliant. But the other one about these multiple, you know, requirements, so you said, you know, the AI Act, you've got the Cybersecurity Act,

you've got the, you know, the Cybersecurity Act, you've got GDPR, et cetera. You know, so again, you know, just to repeat what I said before, as a CFO or a supply chain director, you spend a hell of a lot of time reconciling, right? SOX controls, you've got, you know, US SCAP, you've got Swiss SCAP, you've got whatever. And we manage to, you know, reconcile tens of thousands, hundred thousand transactions globally without a problem. So, you know, I think, you know, as I said before, you know, hammering this home a little bit, I see so many times very much engineering focused teams, and they're not, they're not resourcing coming down to V.

I think at the moment, there's really not a great understanding from boards and leadership teams, the actual true cost of deploying cloud S&D products. They're really underestimating it. I've seen this really impact really great people, good engineers, burning people out, you know, pressure, it's causing trauma to some degree, literally burning people out. And if you want to build a sustainable cloud compliant operation, you know, unfortunately, you know, leaders and teams need to wake up to the cost. And you do not want to be the recall example that the FDA rolls out to get the industry to be compliant.

I'm not sure I'm answering your question directly, but I think I recognize it. It's a good one. Yeah, it's a good answer. You know, I totally agree with you. I have startups that they get in touch with our firm on a regular basis. And they're like, look, I built this system in two weeks or three or a month, you know, in my, in my garage. And how soon can I have it on the market? And so I have a, I have a boilerplate email that I send with the long list of documents, of practices, of quality system elements they have to put in place. I wait a week for the crying to subside. And then, and then we have a conversation about their ATMs,

to two year journey to get, to get things going. Right. Yeah. And just, just to build on that and sorry, I don't want to do it, but where I get it, if you've got the car here, I can grab the car. I'm not sure I can. Usually they come from this direction, right? They come from here. We built the device. They haven't followed the design controls. That's right. And guess what? There's a big brick wall there. Yeah. You can either, you can either go to the, you can go to the, you can go to the, you can go to the, you can go to the, you can go to the, you can either stop and go back to the beginning.

You can crash through the brick wall. And to be honest, you know, there's no freebies. You're going to get caught. Right. Or you're going to have to, you know, pay the true cost and do it properly. Right. Which oftentimes is, is really re-engineering your device to some extent, to, to get, to get caught up. Yeah. And I've seen startups, they've got their $5 million startup capital. They've burned through most of it. Yeah. And they don't have the money anymore to get it. So they can go back. So they're in a really tough situation. That's right. I've seen the big companies, they've got commercial launches planned and the commercial guys and bonuses are all in there.

And the culture doesn't accept that we can go back. And it's like, I don't get involved in that. I'll give you the view. I'm very happy to help. But you know, no free lunches, unfortunately. Yeah. So Eric, similar experience. Yeah. I wanted to echo what you said about, you know, the inspectors, just because your inspector is not skilled. In, in cybersecurity does not mean that your threat actors are not skilled in cybersecurity. That's a really good point. If your devices are vulnerable and something happens and you get sued, you're not going to be able to say, well, my inspector was a biologist.

He should have figured it out. That's not how it works. Yeah. And, you know, I think it's, I think that we've been sort of trained by our regulators, notified bodies to think of risk only in one dimension, right? Which is safety. And we forget about all the other kinds of risks that are out there. And then even within the safety space, we forget about the skill sets of all the people that, that are not in our regulatory community. Yeah. And so maybe another point here, I see a really big problem in the industry, in the industry with the QARA culture as well, which is not fit for software, high-velocity software development.

Document-based QMS, document-based thinking, et cetera, does not work. The software development industry has solved how complex text gets compiled. It's called Git. And QARA really need to learn from the development teams and construct their technical files in Git. At least in Confluence, web-based is better, but move to Git. So the QARA department is not putting unfit-for-purpose systems, processes, tools onto software development teams. It's going to crash, going to spend money. And that's really, again, I think, my evangelical position that they want the software development teams to move towards the QARA department.

We've done it for years. It works. No, it doesn't. You've got to come and meet in the middle. And don't get me wrong. The agile guys have a lot to learn, too. But there's a real whole shift in culture we're going through. But there's a huge opportunity for the companies who want to take a breath, get it right, and there should be no risk, no conflict, and you can really get a step ahead of your competitors. Yeah. I'm an old guy. I'm an old guy. So when I see the same issue with the folks that I work with, I tell them to take an object-oriented, independent approach to design, right? Every requirement, every specification,

every architectural element should be treated as an independent object with its own life cycle and its own relationships. And if they do that, whatever tool they're using, they're going to be much more successful in the current development environment. And I will add just that in terms of how fast NotifyBodies will catch up, I think quite fast. If manufacturers continue to submit, they're PSUR, and they include vigilance activities, including any cybersecurity issue. I think they will have a look on that very quickly. And hopefully when Udemy is going to be available online, also these issues, we're going to go up in that database

and it will be publicly available. So I think that I will say like within a year or so, we're going to see more and more NotifyBodies that are experts already on software. They will go deeper and deeper in cybersecurity, but they're going to be more and more active in the future. So I think that's a big thing. Because those are the issues that are going to pop up the most on vigilance, I will say, vigilant side. And we actually have kind of a track record of this in the U.S. and the FDA to sort of use. You know, it's not exactly apples to apples, but the first FDA guidance on cybersecurity came out in 2014.

They had really no true cybersecurity experts on staff. The guy that wrote that was a PhD chemist. But, you know, now that I look at what's happening since the 2023 pre-market guidance, since they rewrote that guidance, I see a huge uptick in expertise, although obviously not comprehensive yet, but a huge uptick in expertise in the review teams and the inspection resources that are available. It took six or seven years, even more really, for that to embed itself as a skill set within the agency in the U.S. NotifyBodies may be a little quicker. But if we go back to maybe when the MDCG guidance was first published,

from there, I would expect, you know, again, give it five, six, seven years, and you're going to see a catch-up, Lena, like you discussed. Before we switch to Lena, I would just like to put a plug in for the digital transformation webinar tomorrow, same time. I put the link in the chat. I think that they're going to be looking at some of the issues that Richard was discussing. And the need to move away from document-based QARA towards a more fluid system and a more fluid way of communicating with the NotifyBodies in real time. So this should be interesting. I hope you can join us. Sorry for the ad.

And I'm going to go ahead and move to Lena because I want to make sure she has time. Sure. Sure. So now we're going to... I'm going to move forward to Latin American... the Latin American landscape. It's a bit... It's not as advanced as I will say for the FDA and European side, but I think it's catching up as well. So we're going to go over different requirements for different countries very quickly

because so many countries is very diverse. What is the common ground? And then what are the steps towards global market? And then what are the steps towards the global market space? So as I mentioned before, you have like different regulations for different countries and different levels of maturity. So I will just bring up some three different type of examples that I think are very relevant for today. So we have on the first batch, we have Brazil and Mexico. They both have regulations already regarding data protection. That is very intertwined. As Richard said before, with the whole picture of cybersecurity.

And they also have cybersecurity policies for the country as an important policy. And more specifically for cybersecurity, Brazil has the Resolução da Diretoria Colegiada. And they have the Resolução da Diretoria Colegiada. And they really in this document 657 from 2022, they describe all the different requirements for software, the medical device. They provide definition that is quite aligned with IMDRF. And they also describe this is quite harmonized, not only with IMDRF, but also with FDA and with European community.

There's a lot of harmonization there. And also they provide different definitions for cybersecurity. And interoperability, it doesn't mention specifically the standards as FDA or the MDCG for Europe does. But they touch base on the fact that you can use ISO 14971 for your risk management globally, which I think is pretty interesting. Then on the group of countries that have already regulations for cybersecurity or that touch base on cybersecurity is Mexico. They have Article 83, Reglamento de Insumos para la Salud. And they is not as detailed as the RDCD from Brazil, but they really mentioned aspects regarding security

and the risk assessment of security. So it's also those two countries are leading requirements for medical devices on cybersecurity in Latin America. Then we have Argentina and Chile. They don't have a specific regulations for cybersecurity as we saw previously for Mexico and Brazil. But Argentina, for instance, is an active member of the software as a medical device working group of the IMDRF together with the FDA and Canada. So Argentina has a good overview on all the aspects regarding cybersecurity as well. So both countries share this side of the conversation.

They have data protection laws. They have national security policies. And both their ANMAT for Argentina and ANDIB for Chile, they are actively working with IMDRF and also with the groups for software and cybersecurity. And then in the other group of countries, they are starting to move on this end. They have data protection laws. They make cybersecurity as an important or a priority for as a country. And their regulatory agencies for Colombia and Vima or the for Mexico, they are, sorry, for Peru, they are also working towards cybersecurity, but not as explicit as it is for Brazil and Mexico.

So this is like the three different scenarios for countries in Latin America. So what is common? What is the common ground for these different countries? So we have that despite, you know, they have different maturities, these different systems, Mexico, Brazil are like on the lead, and then like a little behind other countries. You see that for among all these countries, cybersecurity of medical devices is a concern. They share definitions such as software as a medical device, in Spanish, software como dispositivo medico. So they share the differences. They are all aligned with the IMDRF definition.

They are broadly aligned with IMDRF guidance. They also work, they have working groups. Most of them, they are working as observers or really actively working on the working groups of the IMDRF together with FDA and Health Canada, meaning that they have the knowledge and they know that these different guidances are appearing, especially for the US regarding cybersecurity. And also for instance, Brazil and also Mexico, they have agreements to recognize FDA clear devices and CE mark devices. So that's also like a positive, if you're going from those big markets towards Latin American market, that's a plus to have because they are already aligned in that sense.

So it's the higher regulatory level that can come to Latin America. And I will add as well that Brazil is actively in this app. It's a medical device single audit program. So that also helps a lot in, and that also gives you an overview of what is required for the regulatory authorities in Brazil. If you're part of MDSAB, that is an interesting step for Brazilian companies going towards global markets, but also the other way around. So that's the part of like what is common for our countries. I would like to know, I think that's a good moment for, for Apol to know, how the leadership is participating in this different

and how the leadership, yeah, involved in the, in the awareness for cybersecurity. Sometimes the difficulty is that regulatory quality affairs professionals, we are all very aware that this is necessary to implement, not only for the device, but as organization, but sometimes it's very difficult to get leadership to be involved and saying, okay, this is not my problem. So, it's not a problem for our organization, or I don't have the time or the money to spend energy in this. Well, it can impact. I will say now I'm going to mention which one, but some regulatory or specifically one regulatory agency

have been victim of cyber attacks. So it can happen to everybody, even for the lip regulators as well. So moving forward, sorry. I will leave here like some that you can have some basis, but I'm going to leave it here. We're going to have some basis regarding Brazilian law, Mexican law for the regulations for the cybersecurity both. It's broadly South versus medical device, but there are aspects for cybersecurity as well involved, of course, and the IMD RF cybersecurity guidance, the other resources are also available as well.

So when you're going towards the market, the global marketplace, where do we start? You know, there's the companies in Latin America, or Europe, they have different levels of their authorities, the enforcement and the level of compliance is not as high as it will be for the US and Europe. But as you can see, I've been saying some names and you have heard some different names and regulations that can help. So we have the results for the awareness. I know, Sean, if you want to jump in here as well. Sure. So it looks like 19% said very aware and supportive, 33% aware but not fully supportive,

33% somewhat aware but not fully engaged, and only 2% said not aware. And then, so yeah, very interesting results. Thank you, everyone, for participating. Thank you very much. So yeah, and this is so technical sometimes. It's difficult. It's difficult to transfer, to discuss this information with them. These are hypothetical scenarios, difficult to discuss. But this is your key to access the global marketplace. So it's a good starting point. So if your objective is to bring your product from Latin American perspective to US and Europe, we already have a good, very good description, discussion before with the other panelists.

But you will say, well, where do I start? What do I have now? So you should make sure that you start. You should start to having cybersecurity policies and the different SMPs that will be necessary. Because as all of them, as Eric, Richard, and Mark mentioned, it makes part of your quality management system. Cybersecurity is not in the vacuum. It makes part of your quality management system. So you should make sure that it shows. There's also, Mark mentioned, a secure product development framework, NIST software security framework. So you should make sure that you have that. So you should make sure that you have that.

If you have a secure software development framework, you can implement those already. Even if you're not there in the US or European markets, you can start. And it's quite, it's a bit technical document, of course, but it's understandable and it's free. It's available for free. And you can start implementing for your, within your quality management system and also with your product. Most of the, most of the regulate, most of the regulators require companies to comply with ISO, ISO 2.0, ISO 3.0, ISO 2.0. 40,971 2019. So start there also as a good starting point. Eric mentioned the physical assets is not, the word is not there. So you can also extend that to the cybersecurity aspects.

So it's a very interesting starting point if you already have it enforced that risk management file. If you follow IMDRF guidance as well, it will be great help as a starting point. They are for free. And you have FDA, you have European Union as well working in IMDRF. So you will have some level of harmonization as well. And as an extra follow or at least understand FDA and medical device coordination group guidance that are available on cybersecurity. If you have the money and the resources, you can do that. So if you have the money and the resources, you can do that. So if you have the money and the resources, you can do that. So if you have the

money and the resources, you can do that. So if you have the money and the resources, you can do that. So if you have the money and the resources, you can do that. So if you have the money and the resources to implement within your organization, that will be great. But this, I think I will say it is the starting point if you want to go towards the US and European markets. And of course, call to the professionals to help you reach in those markets as well. Experts will help you to, depending on your resources and on your objectives and the timeframe to reach that objective. So that's it from me.

I don't know if you have any questions. Go ahead. We'll be happy to answer as well. You know, I would actually add, can you back up to the slide you were just on before? The NIST document that you mentioned is a really good one. For those that are on the call that may have involvement in establishing sort of more broad cybersecurity structures within their company, whether it's specific to the products or more broadly across business operations, I'd also highly recommend the NIST cybersecurity framework. 2.0, version 2.0 of that was released in February of this year, where they added a discipline of governance or govern as an aspect to that.

It almost reads like a capability maturity model, like a maturity model, except it doesn't have sort of the evolutionary steps through maturity. But in terms of the way it's broken down, it looks like a maturity model. I would just encourage people to take a look at that, and even if you're just focused on product development, you can extract really good little nuggets out of some of those. Yeah, I agree. Even extend, like adding, well, you have a table, adding extra columns and saying, well, I suggested that some of my customer add a column where you say QMS aspects, which of your procedures and also, well, so plus QSR, which parts are compliant

regarding the, as a company, you know, as a company, what are the sites that are compliant? And then in the, on the verification evaluation activities for the product security side as well, you have those columns and you start already having like sort of a checklist going to cybersecurity, cybersecurity compliance. That's awesome. I would like to take a moment to thank the four speakers, Lena, Mark, Richard, Eric, for doing an excellent job of covering a very complex topic. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Um, I asked that, uh, everyone who participated,

complete the survey at the end. Um, that will pop up on your screen or be emailed to you or something like that. Um, and provide your feedback. Your feedback is really meaningful, um, and, uh, helps us understand who you are, where you're coming from. Um, and how we can, how can that serve you in the future? Show. Um, please say a moment to do that. Again, if you're interested in getting a certificate of attendance, you should put your name and email address in the chat or in the QA. It doesn't really matter. And I'll try to get those out this week. Please be patient. They're done manually. And, you know,

we have to, you know, make sure we spell your name right and everything like that. You know, that's complicated for people like me. But if there are any final remarks from any of the speakers, please feel free to chime in. No, this is really fun. I appreciate getting to spend time with everyone on the call. And I always like it when we're not just focused on the PowerPoint, so we get to have a little bit of a conversation as part of it, because that's when, to me, that's when you get the most valuable nuggets. So it was just really great to participate. And Sean, we appreciate you bringing us together.

Thank you all. Okay, I'm going to go ahead and end the call. Thanks, everybody, for your time. And we will see many of you tomorrow. See you, everybody. Bye. Thank you.