Secure Your Devices Today and for the Quantum Era A MedTech Masterclass

Hello, and welcome everyone to secure your devices today. And for the quantum era I'm Sean Smith. I'm host today of the Medtech masterclass with Mark Omo, engineering director at Marcus engineering and Axel Worth, Chief Security strategist at medcrypt. I'm super excited to have these 2 speaking today about this exciting new topic that I hope will be rewarding for everyone on the call, and I have a couple housekeeping, keeping announcements as we get started, and as people are still joining. I'm going to drop the housekeeping announcements into the chat button. But for starters this webinar will be recorded.

The recording will be available to all registrants. By tomorrow you'll receive an email if you registered with a link and a passcode in it. Secondly, there will be an additional link for the slides. The speaker slides today which are going to be really valuable with a lot of resources in them. So make sure that you download the slides. There will be a poll that we're going to run during the thing and following. There's going to be a survey. We appreciate your participation in the polls and surveys. That helps us understand who you are and what you're interested in. Use. The Qa. Function vigorously throughout this thing to ask questions of the speakers, use the chat function to communicate with me and to get other information. Speaking of the chat function, if you would like a certificate of attendance, please put your name

as you would like it to appear on your certificate along with the email address that we can send it to you at. And in the next 48 h or so we will get that over to you. They're handsome certificates, and I strongly encourage you to share them on Linkedin. To let people know that you attended the event. Particularly if you find it worthwhile. That I think, is it? I'm gonna put our contact information in the chat. And if you have any questions please reach out to me directly. With that I'm gonna turn it over to Mark and Axel to get the substant part of the webinar started. Guys. Welcome.

Hey? Good morning. So my name's Mark. I'm the engineering director, Marcus engineering. We're a full service product Development Comp and and Cyber Security company focusing in the medical device market. So we're excited today to talk to you guys about securing your devices and cryptography, especially as we move into an era of quantum computing. So today we're going to cover, you know. What is cryptography? Why is it important? The new NIST post quantum cryptography guidance? How that ties in with the FDA's existing cyber guidance, and how hard it is to implement post quantum cryptography, how we show compliance! Why, it's important to start now. That kind of stuff.

Pass it to Axel here.

Thank you, Mark, and and thanks everybody for joining. Today. I am Axelworth. I'm the Chief Security strategist here at Metcrypt companies, focused also on the medical device industry. Specifically, we offer an array of tools, software solutions and services that help medical device manufacturers of all sizes to address the growing demand for security, and their devices growing, demand coming at them from regulators, the FDA, but also in in Europe, Singapore. Australia, other markets, but also from their customers right, as customers increasingly put cyber security requirements into the purchasing contracts.

And you know the idea for this webinar was born when, a few weeks ago, Mark and I. We're talking about, you know. What do we see in the market? Right? We see certainly. An increasing need for security implementing of security controls in devices. specifically around cryptography to address concerns around confidentiality. integrity, availability, trust and identity, and and so forth. And we are certainly keenly aware that that FDA recently has started to raise the bar on cyber security and and is now specifically looking into a device's security properties as part of the market approval process, and we have seen many devices, many devices where

market approval was rejected or delayed because of cyber security questions. And we'll talk through a couple of examples actually in the course of this presentation. But also we have seen companies come to us with what I would consider a failed cryptographic implementation or other failed security implementation. And of course. if you're getting to to introduce you product to the market, and you realize you have a problem with your crypto implementation. There is a pretty severe setback, because many times you need to go back to the early days of your design and architecture and deep aspects of your implementation to to address those examples of things we have seen where

cryptographic implementation has failed was, for example, that manufacturers looked at the device and and realized the existing resource. Constraints of the device, be it compute power, memory, battery, power. You name it, and because of those perceived constraint made hasty decisions about cyber security and cryptography which then led to an implementation that was insecure and didn't reach market acceptance. Also, many times we see companies focusing on the cryptographic implementation itself, the algorithm, the key strength, and and so forth. But they are not looking at the big picture, as, for example.

how the cryptographic materials should be protected at the cryptographic keys, for example, as they are provisioned in your manufacturing process, or as they are stored on devices and and so forth. We've also seen cases where they are perceived operational priorities, for example, a very complex multi-location manufacturing process that then led to decisions about insecure key sharing and insecure provisioning processes. Because, again, the you know, the the attempt was to make the cryptography implementation and processes fit the operational complexity, and and that resulted in a less than ideal secure

implementation. Other things we've seen is certainly the use of a single key across multiple devices or a single key to support different crypto functions within the single device. But crypto functions with different security risks. So using the same key, for example, for authentication functions as compared to for code, signing functions as compared to integrity, protection, and other crypto functions. Clearly again, and not not ideal architecture and design decision. and then, of course, the last one. And then that will be a big topic here in our presentation today, as an example, is the failure to

plan for not only key lifecycle management and key updates in the future on your fielded devices, but also the update of your crypto libraries. Should vulnerabilities be uncovered in a crypto library, which happens on a regular basis, or even more complicated and more severe, but nevertheless important case, and that is An update of the actual crypto algorithm, as we leave the you know, let's call it the pre quantum area and enter the post quantum area over the next couple of years. And yeah, we'll talk about that in more detail. With that back to you. Muck.

Yeah, so start off with a little bit of background. So like, what is cryptography? And why is it important to our devices, to our systems to how we operate and cryptography is how we secure sensitive information and protect it. It's how we we make sure that people can't get at your your health information can't get at your device. Data can't intercept communications. People can't decrypt messages and information and and really, cryptographies is based on mathematical problems that experts in the field consider very hard, and you can't break the cryptography because these problems are so challenging.

And so the the thing is is cryptography is a highly specialized field. It's not the kind of thing that would normally be under the purview of software developers or even people lots of people in security. It's a niche field within that, and it requires people who are deep experts in it, especially to make it. But even when we're implementing it and understanding all the parts and how they fit together, and how we can construct a secure system supported and based on cryptography. And so for low risk applications, areas that are not highly critical. It's the kind of area where developers can apply

existing software best practices. There are these well established patterns that people can use and apply and implement. But as you move up the risk chain of your system, as your system becomes more complicated, security becomes more integral to what you're doing. That's where you need to really think about and understand engaging with a team or people who are specialists in cryptography to make sure that when you apply it, and when you use it, and when you plan for it, it's you're using it properly and securely. And so, you know, I like this quick reference chart of you know how risky is it, how how much importance should I tribute to cryptography? And so, at the lowest risk? These are systems that are not networked. If you don't have networking, if you don't have

Bluetooth wi-fi USB stuff like that, if your device is not a highly critical like life supporting function, or it doesn't support large. It doesn't process large amounts of patient safety data, that kind of stuff. That's where you could go ahead and apply the best practices. So we're thinking about like blood pressure cuffs, thermometers, pulse oximeters, these kinds of simple, low criticality, non-network devices. And then, as we move up to medium risk devices. These are devices that are networked. And you know, we talk about our hospital networks. They're no longer these safe, fuzzy places. They're now

these much more aggressive places where we can't assume that things are safe. And if we have interfaces where we can access the outside world, or we're working on devices that are critical. They do have life and safety critical functions. You know, things like home health trackers. They're handling. They're connected. They're handling patient data, you know, standalone Eeg, ekg, systems, you know, nerve stimulators, things like that stuff that is more complicated and more critical and and or connected, and this is where you want to consult with an expert check in with people, make get them to at least take a look and review your

your system, how it's designed. Your architecture views things like that. And then all the way at the high end, where we have high criticality devices, network devices or data and systems that are holding large amounts of patient data, things like that, things like ventilators, continuous glucose monitors. They're both connected and could have serious implications. They fail medical record systems, you know, huge targets of hackers and people trying to breach systems along with large complicated systems like surgical robots. This is where not only do you need to check in, you should work closely with experts in cryptography to really make sure that what you're doing, how you're applying the data, how you're storing your keys, how you're architecting your system, how you're planning for the future is really on point and on target.

And so you know, next thing we're going to touch on is quantum changes. Cryptography. So quantum computing is is something that's coming up. And one of the biggest areas that is strongly affecting is cryptography. And so, quantum computers, they can solve those hard mathematical problems much faster. All of a sudden these problems, we thought for a long time were hard problems. And those hard problems we rely on security are, it turns out, some of them are not so hard for quantum computers. And so this means that quantum computing makes some current cryptography vulnerable. And so that means we need this new class of cryptography called post quantum cryptography, cryptography that uses problems that are hard not only for traditional computers, but that are hard for this next generation, the quantum computers.

And so you know, the main reason we're talking about now is NIST just released. The 1st version of their transition to post quantum cryptography, standards, guide. And so NIST is the Us. National institutes of standards, technology, and they are one of the forefront and setting the standards for what cryptography is accessible, evaluating the risk, really understanding the algorithms and which ones you should use, and it outlines the transition timeline, and who and how they should transition for people who are using the types of cartography that are vulnerable, and it turns out quite a lot of them are vulnerable.

I'll pass it to Axel here.

Great thanks, Mark, for the introduction. If you want to move to the next slide. which is a little bit of a you know tangent the step to the side here from our main topic. But I thought I include this for 2 reasons. One reason is you know, it's the time of the year, where we look back to 2024, and and try to understand how any cybersecurity, threat, breach, and so forth, trends have changed, but also, secondly, and I'll get to that on the next slide. This actually points directly to the current thinking by agencies like the FDA. So so in summary. Here in the Us. Under Hipaa, we have this thing called the breach notification rule, that requires any entity that handles protected health information to report a breach that affects more than 500 patients

within 60 days to health and human services. And then Health and Human Services publishes those breaches on a website called the Wall of Shame. And then you can download that data, analyze it as I've done it here, if you would, you know briefly, click, mark so what we see here I mean, 1st of all, since 2,010, since we have full year reporting, we have seen a steady increase of reported breaches in a given year between 75 and 80% of those breaches are healthcare providers, others are insurers, clearing houses, business associates, and and so forth. But providers typically account for the the largest number of breaches here.

What is interesting, though, is that the the overall picture has changed right back in the early years we had theft and loss of devices, laptops, other equipment, external, hard disks. You name it as the highest category that has been almost driven down to nothing, and since 2015 we have seen huge increase of what is classified as hacking it. Incident which coincides with cyber adversaries discovering healthcare as a very fruitful target for ransomware attacks. Right healthcare has a perceived low security posture. Healthcare has a high pressure to restore operations.

Unlike many other industries and therefore, healthcare organizations are more likely to pay quickly than than other industries are, and therefore I think we see that many financially motivated hacking organizations have honed in on the healthcare market. And again, the really the the single driver since 2015 for the growth in breaches has been that yellow category hacking it incidents, and it's even more profound if you look at the number of breach records which, as of last year, 91% were actually due to hacking it. Incidents so unauthorized access is still there as a second. Everything else is irrelevant, but it's down to a few percent, even below

percent. If you look at the number of breach records. And next, please. So if you look at collectively the data we have since 2,009, it's a average of, you know 10% year over year growth rate in terms of the number of reported breaches we have seen 6,590 reported breaches to date affecting 686 million patient records, and that is against a population in the Us. Of roughly 330 million. So more than twice the number of people in this country, and also what is interesting is that the biggest breach we ever had? That was the Unitedhealth Slash change, healthcare breach last year was reported to Hhs last year as a impacting 100 million individuals, and last week there was actually reporting in the press that that number needs to be revised upwards to 190 million records. So that 686 million, this is going to go up likely by another 90 million.

Okay, so next slide, that brings us back to our topic cybersecurity and the FDA. So the the previous slide certainly explained why the FDA has advised medical device manufacturers to consider hospital networks as inherently hostile. Right? The you cannot rely anymore on a secure network. To operate your device. You need to consider that your device operates in a compromise in a compromised network. Also, we have since March of 2023, the Food Drug and Cosmetics Act section 524 B. Which gave FDA

a legal mandate to enforce cybersecurity, and gave FDA the legal authority to implement that mandate. And since then we have seen significant action from the FDA, including the September 2023 updated pre-market guidance as well as Yeah. A number of market approval. Rejections for cyber security reasons alone. And specifically, FDA looks at areas around security architecture and threat modeling overall. Your risk management process, your cyber security practices and controls. You implement. Your ability to detect security events and and log the events and few the devices.

overall your cyber security labeling and documentation, including a software bill of materials and then security testing and traceability. Right? So FDA expects that your tests confirm that a. The identified risks. the rescue identified during design. are addressed through the appropriate controls, and that you can confirm through testing that those controls are working. And then the same is also true for your security requirements demonstrate that they're implemented and demonstrate through testing that your implementation, indeed, meets the core requirements for cybersecurity. And then, of course, your obligation to provide post-market management

activities, so that few devices are and analyze from a security perspective, but also that you can address any new security risks that you that you find in the post market, and, in fact, FDA has made the inclusion of a post-market management plan in your market approval, application, a condition for market approval. So you not only need to demonstrate to the FDA that your device is secure, but you also need to demonstrate that you have a plan and processes in place to maintain the device's security risk once it is market released next slide, please. So In general high level, FDA expects you to have a secure product development framework in place

that you provide evidence of security and security processes, your threat modeling your Sbom, your testing, your traceability, and so forth, that you have cryptography-based security implemented where? Appropriate that you can monitor behavior and log and do your post-market surveillance. that you can manage both pre and post market vulnerabilities, and that you demonstrate that you have a plan in place to maintain your device's post-market security posture next, please. So specifically, the FDA expects based on the latest free market guidance from September 2023. That you, as a manufacturer, provide a reasonable assurance that the device and related systems are cybersecure. So there are 2 important things here, a

that you provide assurance through documentation, including testing but also that you not only look at the device, but also related systems. Your device is part of a larger information system network in the hospital. Your device receives software patches by some path, be it network or via USB. Or other ways of getting patches on a device that is all part of your cyber security posture, and you need to demonstrate that you have thought through all of those aspects to make sure that your device is secure. FDA defined a number of security categories, including authenticity, integrity, authorization, cryptography, code, data and execution, integrity, confidentiality, event, detection, logging.

resilience and recovery, and then updatability and patchability. And if you look at that list, you see that some directly point to cryptography, such as the second one, or confidentiality as the 4th one. Others indirectly relate to cryptography. For example, your code integrity, of course there is a lot to be said about it. But proper code signing and configuration management and secure distribution of your software code are certainly part of that. It doesn't matter whether it is release of your code into your production environment, or the release of patches for fielded devices. And and

certainly FDA reiterates and actually has a couple of sections that specifically talk about cryptography and cryptographic algorithms and protocols that are recommended to be implemented to achieve the overall secure by design objectives that again, you need to demonstrate as part of your pre-market approval. Next, please. So specifically. And and, as I said, there are several sections in the pre-market guidance on cryptography. but this one section here as as an example on what FDA is looking for. They're expecting you to implement sufficiently strong cryptography throughout the expected life of the device, and that you use NIST recommended standards and practices, and Mark already referenced one of the NIST standards that are important here.

But it is not just about the algorithm, right? It is about key lifecycle management. It is about key protection both on and off the device. For example, as part of your provisioning process. It is about algorithm lifecycle management, and it is certainly also about your overall key hierarchy and the purpose of varying keys. Right. You again shouldn't be using the same key to sign your code as you use to protect, for example, device to device communication. Those should be properly separated. Next slide, please. So to start summarizing this section here, achieving secure by design objectives

through, for example, providing your device with a unique and trusted identity. That is a cryptographically strong identity of your device, so that the device can identify itself against other systems it connects to. But also the device is capable of verifying the identity of other devices or of data that is coming added, including software updates. Cryptographic authentication is the extension of that identity function overall data and code integrity which includes. But it's not limited to authenticating your firmware and software. But how does the device know that a software update is indeed coming from an authenticated source, meaning you the manufacturer. And there is at least one known case of a compromised medical device software update that actually included malware that was distributed with the update for the device.

and then, of course, from an overall information, protection, perspective, assure confidentiality, integrity, and authenticity of data. And we'll talk about a few examples in more depth in a moment, here and next, please. So specifically, cryptography for medical devices. Obviously, you have use case challenges right? Whatever you implement needs to meet a very high standard of reliability depending on your type of device. But certainly that standard is higher than the reliability you need of. For example, your web browser identifying itself relative to a, for example, shopping website.

many medical devices. You need to deal with resource constraints, and Mark will talk about that in a moment. In more detail. You may have real time or near real time requirements and adding encryption, signing hashing other functions to a data stream may become a challenge to meet those real time goals. You may have devices that have intermittent connectivity. They may be in somebody's car making house visits for a week or a month before they get back onto the the hospital network and can receive updates and patches and including updated keys and and whatnot, and then, of course, errors and exception handling right? What happens if a cryptographic verification fails? Well, that what happens should be very different. For example, for a pacemaker as compared to for a surgical robot or proton beam accelerator, those are very different use cases that require very unique consideration on

when to stop a communication or stop a process as compared to just flagging it. But where it would be safer to continue it. Yeah, we intermitted or no connectivity. We've already touched on that. Also, what is unique to the medical device manufacturing industry is that you have a complex production environment. but it is many times very distributed includes many 3rd party vendors that produce components or complete devices for you, and then, if you include cryptography in the process. The question becomes, for example, who provisions the keys? Who has access to the keys? Is it your company? Is it, you know, a 3rd party manufacturer. And then, lastly.

healthcare is unique, although other industries are catching up in the very strict requirements for post-market risk management, including the avoidance of deprecated security next, please. So FDA pre-market guidance, highlights, cryptography as one way to implement security controls. But I think it stands out amongst other controls. FDA is discussing gets a lot of real estate in the pre-market guidance. You need to make sure that you build cybersecurity securely, and that you provide evidence that you did specifically according to the appendix in the pre-market guidance you should provide to the FDA description of the cryptographic method that you used, including

the algorithm, the keys, the key strength, the considerations that went through you determining which algorithm to pick and so forth. Then a detailed analysis by a crypto, sorry cryptography expert, because these implementations are complex. You need to make sure that you got it right. And sometimes you need to call on external resources to do so. And then, of course. you need to make sure that for each authenticator that you have created, that you have a list where it is verified, and and how, for example, credentials will be verified, whether those are certificate, symmetric, asymmetric, chat keys whatever. How do you distribute those to your devices in your production environment, and and all these type of questions

next, please. One thing also related to it, and I already touched on on the importance of post-market management is is the overall expectation with regards to post market vulnerability and risk management. So the overall life of a medical device after market release is certainly you have a production and sale period. At some point you end of live a device, you stop selling it, but you still offer support, but at some point that guaranteed support comes to an end, and I assume that is all defined in your in your maintenance contracts. There may be a time of limited support, but then comes the time where there will be

no further support whatsoever. Now, one thing is important. If you talk about software and cybersecurity is that your end of life. Scheme or software may be different than the end of life scheme for the rest of the device. And what do you do as a manufacturer. if certain software components are end of life, end of support from whoever your supplier is. But you're still producing spare parts for your device. But then, all of a sudden you have 2 separate end of life schemes you need to manage, and there are no general rules on how to do that, because each individual scenario is different. But next, please, what is important is that

during your support period you continue to communicate any changes to end of life, end of support to your customers that you keep them abreast, and also that you initiate a formal risk transfer process sufficiently early so that you're customers can decide whether they want to take on the risk of operating a unsupported device, and there could be ways of doing that, depending on the type of device and depending on what the customer is is confident in. but in many cases that also mean that that device will be decommissioned, and will be replaced by by a newer version. So again, that is very case by case driven, and also what falls under that umbrella, of course, is at that point a potential license transfer right? There may be regular license payment required for certain device software components. And you as a manufacturer

at end of support. Typically, you want to get rid of that, that license payment, obligation, and forward it to your customers. All of that, again, should be defined in contracts should be continually communicated and updated as needed. And then, of course, the last important statement is that risk should only be transferred if it is transferable right here, you know, catch is not a good approach to risk transfer. It needs to be something that is planned. That is a mutual decision between you and your customers. and that decision needs to be made before things happen next, please. But during that

support phase you, you have a time where you need to manage post-market vulnerabilities next, please, and that you know, you can break out into high level. You know phase where you collect post market signals from your suppliers, from security researchers through periodic scanning and testing of devices, events and logs, customer reporting threat, intelligence, alerts, you may, getting from various organizations and so forth. that then leads to a triage and risk assessment process. And then, if the risk is high enough that leads to the development of a patch or other security measure, it's not always a patch. Most cases it is, but not always. And then, of course, you share that patch with your customers, and especially during the last half of that process you continually communicate with your customers.

And this process, the purpose of this process is to monitor for new vulnerabilities. But you may be using a Crypto Library that has a newly published vulnerability. And you may need to update that Crypto Library, for example, or any other piece of software in your device. But it is also about managing changing risks, and that is back to the topic of post quantum cryptography. But the algorithm didn't have any new vulnerabilities, but because the external threat. the ability to break that algorithm has increased through post quantum capabilities. It is a changing risk that need to be addressed next please.

and back to Mark here.

Yeah. So let's talk about what kind of devices are affected by quantum computing. And so it it turns out, this isn't a problem that's only for people developing new devices. This is a problem for everybody with devices in the market. Every device in the market, even if it was released far before the cybersecurity. Guidance from the FDA is expected to comply with that guidance, and that includes all of the important parts of complying with up-to-date cryptography that is secure, and one of the things the FDA calls out is secure for the whole life cycle of the device. Your cryptography can't be secure for a portion of it. And old cryptography gets deprecated

occasionally. And this has happened before with different types of keys. And we're seeing this again for whole classes of algorithms because of the threat from content computing. And so that means every single need device needs to be reassessed for compliance. You need to understand? Are we using these algorithms? Do we? Is there a threat from the quantum computing? And how does it affect our device? And then really cyber security? Including cryptography, is is constantly evolving. You know, it's not like, you know, we can have nice testing. That shows we we achieved something. And now it's done. Our device isn't going to magically, you know, no longer

diagnose properly or something like that. Or it's gonna it's not going to magically stop being biocompatible. But that is the case for cybersecurity. It's this shifting target that you have to constantly look at throughout the lifecycle of your device like Axel talks about. And this is one of the reasons why patch ability is really one of the most important topics, because we expect things to change. We expect threat actors to get better. We expect people to find gaps in our systems, you know, even the most secure systems will have vulnerabilities. They just haven't been discovered yet. And you know this is true just as much for cryptography, whereas these capabilities that we once thought were impossible or very far away, are starting to come up really fast.

You know, we've seen NIST has been creating and issuing this guidance, for how do we deal with these threats? And you know one of the big things is, why are we talking about it now? You know, quantum computers are still these big science experiments that are doing interesting things for physicists, but you know it's not like I can go buy one off the shelf. Maybe if you have a lot of money in a very large facility. But NIST's guidance deprecates cryptography. That's not quantum resistant by 2030. And so this is a section. This is an excerpt here from the FDA pre-market submission, guidance. And so, you know, manufacturers should not implement algorithms that have been deprecated or disallowed, applicable by standards. And that's NIST. And the FDA specifically calls out that NIST's guidance is binding for the FDA. That's why we care what NIST says, what the recommendations are, how important they are. It's because the FDA

is not themselves an expert in cryptography. They're not themselves experts in a lot of these deep technical areas. They have NIST and other organizations who are experts in that area, and they defer to their judgment. And so that means that we only have 5 years to come into compliance. 5 years before these old algorithms are going to be deprecated. And so 5 years might sound like a long time when we're thinking about, you know, what's the next quarter, or what's the next thing? We're tomorrow. But in medical device years, that's quite a long time. So yeah, I was going to ask everybody what you know. If you're brave, you can put it in the chat. What do you think the average age of an on market medical device is? How many years old do you think those devices are.

you know, one of the things that we say is, if you design your device without at least planning for post quantum cryptography, your device is going to have a limited shelf life. Your device is going to have an end date after which it will fall out of compliance with the FDA guidance. So it turns out. I ran a report over the database, the guid database medical devices, which includes information on what devices are on market. And when devices are off market, and I selected only for devices that are electronic. And I plotted the data here. And so it turns out, the average. The mean age of medical license is 14.8 years, and the Median age is 12 years. So if you're releasing a device today, you have.

And you're not planning for this. Yeah, it's going to affect you. It's going to require your device to have changes at a minimum and at a maximum. It could require redesigning your device entirely, and even devices released 10 years ago are still likely to be on the market today. You know most businesses. I talk to. Most of the people whose products we develop and help maintain are not planning for their devices to go off market. They're planning to have a long, profitable life for their systems. and so that we only have 5 years for this. So you cannot wait. This isn't a future problem. This isn't a thing to address. This is something that's going to affect us right now.

And so you know, one of the caveats is, we talk about existing data. So we have a bunch of existing data all encrypted using that may be encrypted using vulnerable methods or messages that are authenticating, using vulnerable techniques. And so we need to start that migration by 2030. And so this is about the details of NIST's guidance when they say deprecated legacy use disallowed. And so it's going to be completely disallowed by 2035, which means that legacy use allows for you to decrypt existing devices and systems. Disallowed means that that's not even allowable for the purpose of accessing existing information. It needs to be completely purged from your system, so especially for vendors and systems who are storing large volumes of information things like that that is, you know, a critical timeline that's coming up.

And so the last thing to touch on is the post quantum cryptography challenges. So post quantum cryptography takes 10 times the space, and a hundred times the processing power of traditional cryptography. So this makes it even more challenging to add than existing crypto. We've already seen instances where people have come to us with constrained, embedded devices, things like that that they want to update to meet the cybersecurity regulations, or that they've designed without consideration for that. And it has forced not only software changes but hardware changes. Real world changes to their system. And this is going to occur again at an even larger scale.

And so if you're planning a new device, you need to at least be planning for the storage and processing power for this. And ideally, you're planning, you know. How are we going to manage our keys, how we're going to transition? How are we going to design our system? And the other thing is the ecosystem. Lots of people are not releasing brand new Greenfield devices. They are part of an ecosystem, or they're entering into an ecosystem with other people. And so it's not just about your device. It's not just about other systems about how you interact with your existing systems, with 3rd parties, with people you integrate with. How is post quantum cryptography going to integrate into that lifecycle?

And the other one is, you know, can we add this to existing devices? And so it it really depends on. Do you have enough space and processing power for these new algorithms. And so it turns out for systems that are just full computers, running, complete operating systems, things like that. Those are generally likely to have the extra compute and power for the systems, and then smaller devices, you know, in between, you know, it might fit. It's going to be, depend on a case by case basis, and for lots of embedded and IoT systems, you know, they're often constrained, and they're designed to be as small as possible to do their job as good as possible, and this additional resources are not likely to fit.

So we have some poll questions. We want to ask everybody before we. So we have some time before we get to the Q. And a. Sean, if you want to kick those off And so, no matter what this is going to need to be in devices that are on the market, starting in 2030. So now I'll go back to Axel to touch on the C-bomb. Oh, you're muted here.

Okay, thank you. So on to the next slide, please. just tying the Sebom discussion back to FDA. Right? What you see on the screen here actual deficiency letters that medical device manufacturers have received from the FDA that relate to cryptography. There are other security issues as well, but I picked the ones that that relate to cryptography. Lack of confidentiality controls, lack of integrity controls. lack of availability controls, use of deprecated protocols in this case was a Cse checksum, which, of course, was questionable to begin with, but you know the the direction that Mark was talking about earlier still holds that between 5 and 10 years from now many more protocols will be considered deprecated.

but also then onto your software update mechanism. Assure the integrity of the code you're putting on devices, and you're distributing to your customers. And then, lastly, the protection of your cryptographic material like your keys, your algorithms. your hashes, whatever you're using, make sure that you can demonstrate that those are secure. And while I'm on this slide, maybe I briefly want to address one of the questions. I saw in the chat, and that was about whether we see any of this change under the new administration. And the simple answer is that this definitely falls into the your guess is as good as mine category.

Having said that FDA action. as well as the current FDA pre-market guidance, are deeply rooted in the Fdnc Act, and the Fdnc Act is law right? So FDA has the legal mandate and the legal authority to enforce cybersecurity and law is not changed that easily. Second statement is that we've seen in the past that cybersecurity seems to be a topic that carries forward across administrations right? That everybody recognizes that the cyber risk is not going down, and that cyber security is really not something where we, as a nation, can take the foot of the gas, so

I think that is a as good as of an answer I can give.

Graphic.

To that question.

I wanted to add on a little bit, which is you know, we get this question a lot about like, Oh, our cyber security exam, or FDA Examiner allowed this cybersecurity last time. And you guys are telling us this isn't okay. They said it was, okay. That's fine. Well, it turns out that even if the the FDA says it's okay, the threat actors may be better than the FDA, and even if it's not the law that doesn't mean that the hackers and the people who are trying to cause patient harm are taking their their foot off the gas. It's a very important topic for protecting your devices, regardless of whether or not

you know it's mandated by law.

Yeah, good, good point. And to add more to that. even though the FDA has, I think, brought the regulate a cyber security discussion to life all the way back in 2014 other Regulators have caught up and and have basically leaned in the same direction as the FDA has right in Europe. Under Mdr. And Ivdr. You have very explicit subsecurity requirements. Singapore, Australia, China, Japan, those are all countries that now have medical device specific regulations in place as part of their market approval process, or have added cyber security under the large umbrella of existing processes. Canada is another example. Brazil is another example. So

yes, the FDA is still directionally important, and is certainly important as the relator of the largest medical device market in the world. But we need to recognize they're not the only driver anymore. Next slide, please. Yeah. So what you need to do is basically that you demonstrate to the FDA that you. Your security implementation meets FDA expectations, and that includes your cryptographic compliance. But is your photography the the level it needs to be? And I mean, we are familiar with today, the expectation to provide an S bomb to the FDA as part of the market approval process, but also many customers are actually putting that into their contracts in the future. Expect also that you have to provide a cryptography bill of materials as part of your security documentation as part of you demonstrating that your cryptography is sufficient and how you will manage it in the future. Right? So a C bomb

you know, summarized, is basically a listing of and description of your cryptographic assets and their dependencies. it documents your cryptographic implementation as one of the supporting documents, not the only one, and in overall the concept of a Cbom is not as mature as the concept of an S bomb, but overall. The expectation is that you list your common data elements that it is machine readable, that you define key crypto assets, such as algorithm key certificates and describe their respective properties and relationships to other software components.

and all of that then provides visibility and enables management of your crypto implementation. You can demonstrate confidently that your implementation meets the state of the art, but also it. It helps you to going forward. Manage post-quantum readiness next slide, please. And the best document I found so far that goes very deep into what a Cbom is is from Owasp, and I put the link here in the slides. You know they give you a listing, and and the hierarchy of the data elements that make up a C bomb next, please. And you know those elements are.

you know, broken down here. What they mean. That's summarized again. Look at this overstock document for more detail and a much deeper explanation than we can get into here in the presentation. And next, please. So, summarizing our key lessons, FDA emphasizes cryptography as an important security control. and it is an enabler of critical security functions, including post-market management and patchability. Obviously demonstrating that your device is subsecure requires evidence, meaning documentation. S bomb. C bomb testing, traceability. your post-market risk management. Plan all of these things.

Any cybersecurity. Deficiencies can lead to market entry, delays and rejections, and we have seen many examples of that already. Fda points to NIST for what is cryptography? State of the art. And as Mark discussed, that state of the art is not static, it does will change in the future. In fact, it will change within a time. Span. That is the life expectancy of any medical device that enters the market today. Designing future-proof security requires future-proof cryptography, very simple statement, and the availability of quantum computing. We'll raise the bar and we need to start planning for post quantum cryptography today.

And with that we'll move to our Q&A, and the next slide has our contact information. And then there's also in the handout another slide, with additional resources.

So we had a question here about you know, Bluetooth, and what is their roadmap for? Post? Quantum cryptography? And the answer is, it's it's it's still early, especially for the flow down devices and protocols about what? how post quantum cryptography is going to be integrated into those kinds of low level protocols, you know, like bluetooth, ultra wide band. those kinds of things. And I the the challenging part is that the medical devices generally lead the pack in that stuff because of their long life cycle. It's not like a phone or consumer devices with a much shorter, like one or 2 year cycle. And so they don't need to have this long look ahead. And so one of the areas that we can

that that we could focus on is in the meantime, while we find ourselves leading in these areas, and we can't lean on other protocols as hard is, we can use other encryption methods quantum save encryption methods over channels that may not be as secure. You know, we can't just count on Bluetooth for security. We have to encrypt data before it goes over Bluetooth, or we have to authenticate, not just using Bluetooth method, but using an additional separate method. Those kinds of things.

Then another question is about whether their standards or defining C-bomb. the one I just had up 2 slides 3 slides ago from Owasp. That is one I found that is built on the Cyclone Dx standard. I didn't find any other ones. That doesn't mean that they don't exist. But they were not readily popping up in my Google search. But I'm sure that moving forward that that will happen as well.

Yeah, I can speak to that a little bit. There are standards that are recognized by NIST and the FDA as the minimum set of information for I S. Bomb software bill of materials and those same the Ntia. And so, though the same consortiums are currently working on what is the minimum set of information we need for Cboms to help make that more clear, because, like Axel said, it's still pretty early. So.

And then maybe the last question here, because we come to the end of time. There was one question further further up in the chat about de-identified information. And it's a, you know, point to point connection. And there's no patient data in in the in the data stream. Does that still require cryptography, and the answer is, it depends, 1st of all, cryptography is not only used for confidentiality, protection, and that is, you know that what you address through de-identification, but also for integrity, protection, and authenticity of of a data flow. So that is an additional consideration. Second is, there are several examples

in the literature from security researchers where people were able to re-identify data sets that a given manufacturer thought was sufficiently de-identified. So if you go down that route of de-identification. Make sure that you bring in an external privacy expert that can look at your method and can look at your data and investigate whether there would be any possible re-identification risks, because the last thing you want is that your device? You know, shows up in a research paper as a yep. You know, we

demonstrated once again that the identification is not sufficient.

Wonderful. Thank you both very much for your time and expertise today. This is extremely valuable information, and I'd like to thank everybody who gave up an hour to attend the webinar today. Please complete the survey after the call. If you have 1 min and we really appreciate it, look forward to seeing you next week for the next week's webinar on commercialization, innovation to commercialization. Please tune in. Thank you everyone. Any questions, please. Email me. And that's it. Thanks.