Shifting Sands of SaMD Cybersecurity Regulations

FDA has issued new draft guidance on cybersecurity for software as a medical device (SaMD). If the FDA releases that draft guidance ‘as is,’ it will massively and negatively impact the SaMD industry and it’s imperative that manufacturers understand how to prepare. 

In this episode of the Global Medical Device Podcast, Etienne Nichols talks to Chris Gates, director of product security at Velentium, about the shifting sands of medical device cybersecurity regulations for SaMD.

Listen now:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Chris views the FDA’s recent activity around cybersecurity requirements, regulations, and laws for SaMD as a necessity because manufacturers cannot seem to self-regulate. 

• The Protecting and Transforming Cyber Health Care Act (PATCH) will give the FDA a direct mandate to manage the cybersecurity of medical devices.

• However, a clause in the PATCH Act allows for cybersecurity to extend to all existing legacy medical devices—not just new devices entering the market.

• As medical device manufacturers (MDMs) become aware of the clause, it’ll have a huge impact. MDMs will likely end support for device lines due to high costs. 

• The biggest issue with the new guidance consensus vs. regulatory standards is alignment with software bill of materials (SBOM) tools.

• The most effort-intensive part of the new draft guidance is ongoing testing of anomalies to determine if they can be turned into vulnerabilities. The industry will be unable to keep up with additional testing because of resources and demand.

• All this added burden will be placed on MDMs at the cost of marginal improvements in cybersecurity. So, there’s no real benefit to the manufacturer.

• Structure a standard by not creating something brand new that is ill/undefined but align best practices to create secure medical devices.

Links:

Medical Device Cybersecurity for Engineers and Manufacturers

Regulations (Submit comments to the FDA)

Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions

PATCH Act

International Electrotechnical Commission (IEC)

ISO (International Organization for Standardization)

International Medical Device Regulators Forum (IMDRF)

Chris Gates on LinkedIn

Chris Gates Email

Greenlight Guru YouTube Channel

MedTech True Quality Stories Podcast

Greenlight Guru Academy

Greenlight Guru Community

Greenlight Guru

Memorable quotes from Chris Gates:

“Legally-backed cybersecurity requirements by a regulatory agency are necessary to ensure secure devices are entering the marketplace and hopefully replacing the insecure legacy devices.”

“This clause is going to have a huge impact on medical device manufacturers (MDMs) and I find it amazing how many MDMs are completely unaware of this.”

“An SBOM is a software bill of materials. It’s an ingredients list for your application.”

“This isn’t just one-and-done testing in your lifecycle.”

“You’re going to have a lot of extra work coming your way.”

Transcript

Announcer: Welcome to the Global Medical Device Podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge direct from some of the world's leading medical device experts and companies.

Etienne Nichols: If you're a medical device professional, what does your eQMS... what's it doing for you? If it's paper- based, I can tell you what it's not doing, and that's helping you accelerate the delivery of your life changing medical devices to patients who need them most. Paper- based quality management system, it always sounds almost like a oxymoron. How is your QA team going to achieve true quality if they're still chasing engineers for signatures or searching for the needle in a stack of papers? Greenlight Guru is the only quality and product development platform designed to support medical device companies throughout their commercialization journey. That's because we're from the medical device industry ourselves. If you're looking to deliver high quality life saving devices to market on an average of three times faster. Contact Greenlight Guru today to start the conversation. Hey, everyone. Welcome back to the Global Medical Device Podcast. This is Etienne Nichols, your host. In this episode, I get to sit down with Chris Gates and talk about the FDA's new draft guidance on cybersecurity for Software as a Medical Device. If you've read or if you've heard of that draft guidance, if it's released as it is, this guidance is going to massively negatively impact the Software as a Medical Device industry. So, you might be thinking, well, if it's a guidance, what impact is it going to have? And Chris addresses that in this episode. And the short answer is it's going to have a lot of impact. Chris Gates is one of the leading minds in cybersecurity for Software as a Medical Device. And he co- wrote the leading book on the subject, Medical Device Cybersecurity for Engineers and Manufacturers. Chris is the director of product security at Velentium. And really, he's a true master of his craft. He loves this stuff, and he lives and breathes it. He reads these guidance documents. And it'd probably be more job security for him if it releases as it is, but he wants to improve the industry and he wants you to improve the industry. So, while I hope you enjoy this episode, when you're done, go to the FDA guidance documents, read it, and submit your comments by the July 7th deadline. There's not a lot of time, but go to the link in the show notes and make those submissions. I hope you enjoy the episode. We'll see you next time. Hey, welcome back. I'm excited to be with you today, Chris. We talked a little bit at True Quality last week, which is great to connect with you in person. But we were talking about some of the regulations around cybersecurity and Software as a Medical Device. We've seen a lot of new regulations addressing the cybersecurity of medical devices. I wanted to get your take. What do you make of all this activity?

Chris Gates: And before I go there, thank you for having me on again on your podcast here. And thank you for True Quality. What an amazing show. That was fantastic. Some great presentations there. Eric Henry's presentation on the QMSRs was amazing. Really enjoyed all of them, though. They were really great. So, thank you so much for hosting that. Well, first off, let me say that I'm a huge fan of medical device cybersecurity requirements, regulations, and laws. Time and again, industries, including our own, the medical device manufacturers, have proven that they cannot self- regulate. So, legally backed cybersecurity requirements by a regulatory agency are necessary to ensure secure devices are entering the marketplace, and hopefully replacing the insecure legacy devices. And all of this brings us to the PATCH Act that is currently in Congress. It has left the House and is now in the Senate. It's very interesting, these changes that have occurred in the last couple of years, but the most important one is this PATCH Act. This is important for two reasons. First, it will give the FDA a direct mandate to manage the cybersecurity of medical devices. This is long overdue. While working previously under the umbrella of safety, the FDA accomplished a lot. But this direct mandate will clarify all of this and streamline everything and will, according to Dr. Suzanne Schwartz of the FDA, give it teeth. I am all in favor of this part of the PATCH Act. I think it's really a good move, and I'm glad to see it happening. Almost certainly it's going to pass through Congress. It has wide bipartisan support. So, I look forward to this. But the other part of the PATCH Act is had amended to it in the Senate's version of it a clause that will allow this mandate for cybersecurity to extend to all existing legacy medical devices, not just new devices as they are being entered into the marketplace. This clause is going to have a huge impact on medical device manufacturers. And I find it amazing how many MDMs are completely unaware of this. I think once the manufacturers become aware of this, we'll see a whole host of MDMs announcing an end of support period for many of the existing device lines simply out of cost to support them.

Etienne Nichols: And I want to ask you just a real quick question in here before you get back to this. You work with a lot of manufacturers. Have you talked to any that you think that are actually going to do this already or have you had any conversations like that?

Chris Gates: I haven't had those conversations, but from a financial standpoint, I don't see how they can. There are many manufacturers that keep older products around that have very limited sales for a very specific niche, treatment and indication. It's financially just not going to be feasible to keep these things around once this comes into place. So, the PATCH Act is good. The PATCH Act is bad. Either way, I think we're getting it that way. So, I think we just have to be aware that's what's coming down the pike here.

Etienne Nichols: Okay. So, you go on... There are a few other regulations that are changing. Go ahead.

Chris Gates: Yeah. Oh yeah, there is. And this has been a real active two years for cybersecurity and medical devices. And one of the big ones is good old ISO/ IEC. They've also been busy with their latest version of 14971, which is labeled 2019 +A11 for 2021. So, that's the 2021, when they added the A11 part of it. And it also came with it, it's a new sister document, the ISO 24971: 2020. This is basically splitting our old 14971 into two documents to make it a little more size restricted. These old regulations on medical device risk management support safety risk as always, but now address cybersecurity risk as a different process with different methods of assessing the risk. This is a whole separate different path through risk management besides what we've always traditionally used as safety risk. So, this is long overdue, just like the other one, and I'm glad to see it added. Because 14971 is the Bible for our industry. And it's good that they're now actually directly supporting it and talking about how it's two separate processes. So, also what's happened in ISO/ IEC is they've came out with the IEC 81001- 5- 1 in 2021. And this is for health software for health IT systems, and really the product development life cycle. Like any ISO/ IEC spec, it's well written, t's really good, it's very comprehensive of all the activities you would expect to see performed in the development life cycle that relate to cybersecurity. They even go a little bit into the post marketing, but mostly that's just event handling. They don't really dwell on that too much. And this lovely document will be harmonized into the MDRs, the European Union's MDR, in 2023. So this is the standard that is going forward for us if we wish to market our products in the EU. So, all this flurry of stuff out here, this brings us now to the last one, which is the FDA's new draft cybersecurity guidance that was released in April. As the FDA is in the process of transitioning from the quality system regs, the QSRs, to the quality managed system regs, the QMSRs, and thus harmonizing with ISO 13485 regulatory standard, which is a wonderful thing to see happening. I'm glad. It's taken a while, but I'm glad to see this finally going into place. Yes, there's some differences. Okay. Labeling's a little different. Some of the terms are a little different. Okay. Areas of concern, but nothing major. All right? It's just good to see them harmonize to these standards. So, now we can, as manufacturers in the United States, start to homogenize what we're doing for both the FDA and for the EU. And they'll be a lot more similar and take a lot less time and a lot less money to get these products into the market. But that's the point. And you should realize we're now harmonizing with ISO. And I was really hoping to see that this new April draft guidance on cybersecurity would harmonize with MDR, and therefore, a handful of excellent ISO/ IEC standards such as the 81001- 5- 1. Instead, they somewhat aligned with consensus standards such as IMDRF and AME.

Etienne Nichols: And I want to ask a question in there. So, maybe you can explain a little bit about regulatory standards versus consensus standards and why it would even matter which direction they went.

Chris Gates: Exactly. I mean, and a lot of people are not aware of that. They think in terms of, well, it's a standard, right? So, regulatory standards are those used by countries to enforce a standard for their country. In other words, you want to market your product in their country? You have to align to their regulatory standards. And this exists for all sorts of industries, not just medical. All right? But they all have them out there. Those are regulatory standards. Consensus standards, on the other hands, are standards that someone or a group of someones decided to create, and it is not inherently enforceable. Now don't get me wrong here. I love a good consensus standard, because they usually cover topics that are not yet addressed by regulatory standards. They are standards that are looking out years and trying to anticipate what's coming and how to do this, or something that has just been ignored by the regulatory standards. Right? So, these are really good. All right? So, yeah. And in fact, I work on a number of good consensus standards working groups. You also get with these multidisciplinary eyes looking at it. Because no matter how much you think you know the topic, trust me, you get in the room with a bunch of other experts, and they have viewpoints and use cases that you've never dreamed of. So yeah, I love that. I think it's great that we have consensus standards. But once you have a regulatory standard that covers that area, you should pretty much ignore that consensus standard, because the regulatory standard is the only one that's going to matter to you if you're intent to market your product in that specific country. And one other thing here that I need to point out. In this case with the FDA aligning to the IMDRF, the IMDRF is a closed group. So, they're not at all diverse as far as bringing in multidisciplinary people like you would have in a normal consensus standard. This is a closed group only allowing members from worldwide regulatory agencies. So, really, we have no representation from manufacturing or cybersecurity experts, all of whom could have brought some real world knowledge to the process. And that really shows in the kind of work they create. So, for the FDA to align to them really is, once again, why are you doing this when you've got good standards out there that you could align to that would be worldwide and be accepted by the EU and the FDA?

Etienne Nichols: Okay, so we talked a little bit about in this in the past. So, is that really the biggest issue with the new guidance, the consensus versus regulatory standard or...

Chris Gates: Well, no. And again, because this was written not taking into account cybersecurity experts, or the manufacturers are going to be impacted by this, you have a lot of different sections in this guidance that you have to just look at and go, what were they thinking? So no, they're not really even up to date on the current activities in the world of cybersecurity regulation, and it's clear from some of the stuff in there. Let me give you an example, the software bill of materials section. I worked for four years with the NTIA working groups and the great Allan Friedman of NTIA who's now at CISA and continuing the tradition of software bill of materials and supply chain cybersecurity. And we literally had a lot of participation with Suzanne Schwartz and Jessica Wilkerson of the FDA. They all knew what we were doing, and we were all aligned to all of this. So, literally the work that came out of those four years of working group is what was adopted by the NTIA and NIST as the minimum elements for an SBOM. So, really that section in that document should have stated machine readable SBOMs must be created and comply with the NTIA/ NIST minimum elements of an SBO document, period, end of story, that's it, mic drop. You don't need to say anything else. Okay? That was really all that was needed. But then they threw in all this other noise that no one has defined or supports such as the level of support element. What is that? Now bear in mind, these are machine readable artifacts. You can't just have free flowing text out there to say something like the level of support is green or number 10 or it's good or whatever it is. These are things that have to be able to be parsable by code. So, you can't just throw in these wishlist of things, elements that have to be there Worse, they left out a few things that NIST is looking for in the minimum element such as component relationships. This breaks all the SBOM tools out there. It also breaks the concept of sharing SBOMs with any of the other critical infrastructure industries in the United States under the executive order. So, why did they do this? I mean, they should have just said, " Go align with them." And if there was something else they wanted extra, then say, " We want separate artifacts to talk about things like end of support or level of support or any of that." But leave this up to the people who really did a good job defining it, and also aligned it with all the other industries. But that's just one example.

Etienne Nichols: Well, I want to ask you one more question about the SBOM sensor there. Because I know we've talked a little bit about this, but in case someone's listening for the first time, the SBOM tools that you're referring to drives at the reason or some of the real reasons for even having an SBOM. And can you give just a little bit of explanation about what the implication is if you are not able to use that SBOM in the way it's intended?

Chris Gates: Sure. To begin with, an SBOM is a software bill of materials. It's an ingredients list for your application. So, you write your piece of code, and it goes out and references some library. Since it was recently in the news a few months ago, let's talk about Log4j. And you go, gee, I'm writing this in Java, and I wish to bring in logging support in my application. Obviously, the thing to use is an open source package called Log4j. Well, you bring that in. When you bring that in, the developer, he includes it into his project, doesn't really realize that there's 294 other projects he's bringing in with that, transitive dependencies that are being represented there as well, too. And we're seeing more and more intentional poisoning of open source softwares and GitHub repos out there with intentionally inserted back doors and crypto attacks into them. So, they get the amplification of them as they use them in other projects. So a software bill of materials is there to be a machine readable system. They can look at not only that Log4j, the original library, but also all of its transitive dependencies. And obviously, as you can tell just from that one example, this quickly gets up into the thousands and tens of thousands of individual software components. There's no way human beings can do this. So, we need cooperation from all of these industries who create components, who consume components. We need standardized methods for communicating this in these software build materials. They're usually JSON. There's Cyclone DX and SPDX, good formats to do this in that are all previously defined that we work with. So, we can build them and create them. We can consume them. And depending upon what our use case is, we might be manufacturers consuming them to know about our products. But we may also be a health delivery organization who wants to know what their risk is when they bring your product into the things. So, these SBOMs really, really are a great tool. We're very much in a crawl, walk, run model that we're just now between crawl and walking. There's still gaps in the process, but they're getting resolved. There's a lot of open source out there to support it as far as tools, and there's a lot of proprietary coming online already to support them for various roles in this life cycle of an SBOM. So, very, very useful tools.

Etienne Nichols: Okay. And I interrupted you. You were starting to talk about something else that is coming or one of the other things that maybe wasn't the right way. Yeah.

Chris Gates: Yeah. And just to give you an idea when I said previously they weren't even aware of the current activities in the world of cybersecurity regulation. In the section on risk management in the guidance, they call out 14971, ISO 14971, and they use the 2019 version of it, not the current version. And they call it out and says it doesn't support cybersecurity risk. Well, not that version doesn't, no. If you had gotten the current version it would've, or its sister document. So, this is a lovely example of why you don't take a small group of people into a room to define these kind of things. They may not be aware of this. Everybody's not aware of everything. So, we have to have a multidisciplinary group that looks at this and says, what's the best way to achieve this? And something that's workable, something that actually aligns with other standards. This is the kind of stuff we have to start working toward, not more one- off standards out there that we have to support. So, yeah. And again, once again, they could have just gone through there and said, " Yeah, use 14971 and its sister document 24971." Once again, end of story, mic drop, period, done. And it's like, would've aligned with what they're doing with the QMSRs because we would be more harmonized with now what's happening in the EU. But instead, they decided to go their own way. Another area. Later on, they talked about architectural documentation, and they talk about views. Now whenever you hear those terms together, anybody who's developed software immediately starts to think of the object modeling group and their two main products, UML and sort of a sub UML, SysML, unified modeling language and the system modeling language. Both great tools. They've been out there for roughly 20 years now, even for about the last 15 of which we've had SysML- Sec, which is the security add on for system ML, which creates a model. And off of that model, you can slice it a lot of different ways and create different views to look at the security and the implementation in various ways. If you were an experienced security person or an experienced software developer, that's where you'd go. You'd go into there and call that out and say, " These are the views we want to see." But once again, they've made up their own thing and gone their own way and didn't align with existing practices and real standards. Model- based development has been mature for decades, so why try to invent your own? I mean, this is not... Yeah. I mean, and it's also shown they go in and they call the call flow diagram, which everybody goes, " Huh? What's that?" Okay. Well, in UML or SysML, it's a sequence diagram. And everybody goes, " Oh yeah, okay. We all know what that is." It's just that kind of a thing. So, in total, I counted up 41 manufactured created artifacts that come out of this new guidance. This is not an incremental change from the 2018 guidance. It's a huge sea change. Okay? Most of these, does that really improve your cybersecurity posture? It's really debatable. Most just appear to be nonstandard ways to communicate device cybersecurity activities or posture to the FDA personnel. Too bad these weren't tools that could improve the development process, future modifications to the device. I know ES convey all this information as well, too. All right. So, instead, they didn't take that direction.

Etienne Nichols: Yeah. That's a great point. I mean, the goal of the standards, the regulations, and so forth is not to communicate it to regulators, necessarily. It's obviously to make safer, more effective devices. So, I'm curious. So, you mentioned a few different things that might make it more difficult that aren't necessarily value add. What are some of the practical implications? Are these new requirements going to add new testing or what are the things that are going to happen?

Chris Gates: Oh yeah. Yeah, it sure does. And in fact, that's one of the most effort intensive parts of this new guidance. This isn't just one and done testing in your life cycle that you go through and do static analysis or boundary analysis or fuzz testing or fin testing. This is ongoing testing of anomalies, which they cleverly didn't define in the document. I mean, we can all make assumptions as to what that is, but anomalies to determine if they can be made into vulnerabilities. And this is ongoing. And then all the vulnerabilities need to be reviewed in context of potential for chain vulnerabilities. So, this isn't looking at a vulnerability or a potential vulnerability as an atomic thing. You're now looking at chain vulnerabilities and their impact. And for those of you who are keeping score at home, that's an exponential increase in work over a period of decades that that device is going to be in the market. If you couple this with the PATCH Act, this will not only be for the new products you're kicking out that you're going to be doing for decades, but it'll also be for existing legacy devices as well.

Etienne Nichols: Interesting. Yeah, no, that makes sense. We talk sometimes about resources and demand and so forth. Do you think that the industry will be able to keep up with this additional testing?

Chris Gates: No. No. You maybe have the top 1%, 2% of the industry who has a lot of money and a lot of personnel who can throw at this and has very large established security organizations, but we all know there's huge short supplies for both IT cybersecurity and especially embedded cybersecurity. Where are these people going to come from? I don't know. I haven't got an answer to that one. You're going to have a lot of extra work coming your way here, that's all I can see.

Etienne Nichols: Interesting. Well, we could maybe complain about this, but I know you are a man for actually action and taking action. But before we get to that, I'm curious, what do you think we could have done that would made this better? What could the FDA could have done to do a better job of creating this guidance?

Chris Gates: Well, you may notice a theme here that I'm going through, which is don't reinvent the wheel. Okay? Use what we know works. What works here for creating these things, and I'm going to go back to consensus standards on this one, by the way. You have seen out there, a number of public private partnerships on working groups successfully performed by things like the NTIA with the software bill of materials and now CISA who has adopted this, but also and especially by the Health Sector Coordinating Council. Greg Garcia has done a wonderful job of making the HSCC forward looking out to five years ahead that we're looking at this for all things we're going to need to define for medical device cybersecurity, very successful things like the joint security plan and event response and legacy device and the recent model contract language. I mean, who would wade in? The model contract language is amazing, because who would wade in to the relationship that is so dysfunctional between manufacturers and hospitals? And that's exactly what the model contract language does as it goes out and starts to normalize that. What is the hospital's... what should they include in the contracts for cybersecurity with these manufacturers for the devices? And it's like, it's great. Those kind of tools work. These type of working groups are staffed by regulatory, government, cybersecurity experts, medical device manufacturers, all sorts of folks. These working groups create comprehensive, well written documents that are workable and tied in other practices and standards. They don't stand alone, either. We need to get FDA out their echo chamber of IMDRF and their own offices to be informed of other standards and practices that they clearly are unaware of. While I applaud the FDA for back in 2014 being the first government agency to attempt to improve cybersecurity, they've had a terrible track record with the result in guidance documents starting with 2014, 2018, and now this April 2022 guidance. They need to work with a different model for developing that will be cybersecurity requirements for medical devices. Creating terrible guidance documents, and then putting them out for comment is not efficient, nor does it lead to a good finished product. And I'm going to be submitting a lot of comments back into that system. I mean, I'm waiting a little bit more, but it's getting close to the deadline, and I'll be putting it in. And it's all public record, so people can go and look at all the stuff I criticize. But that finished product is the music that all the manufacturers are going to have to dance to from now on. We have to get this right. And that's difficult to do using only comments on a poorly written document.

Etienne Nichols: Yu talk about these other documents. You make me curious how many others are out there like OT and IT.

Chris Gates: Well, we had no shortage. I think that XKCD cartoon that talks about standards, and it's like, oh, there are 15 standards. Let's make one to unify all of them. And it's like now we have 16 standards. Right? And that's so very true. Right now, there's somewhere over 600 OT and IT cybersecurity standards, both consensus and regulatory. We really don't need to make another one from the FDA. Let's try instead, just show some maturity. We've been at this a few years now. We should start to get mature about how we handle this. So, let's try to align with existing regulatory standards instead, and maybe even make cybersecurity easier to perform for both the FDA and the EU and the manufacturers. I mean, isn't that the end goal, good secure devices that we can prove or secure, but we can turn them out and actually get the products out, helping save people's lives and improve the quality of their life?

Etienne Nichols: So, you talked about the PATCH Act and giving it teeth, and then this guidance that is going to increase not only testing, additional resources they needed and so forth. Are there plans to pay for this somehow or do you know who or how this is supposed to be paid for?

Chris Gates: Look in the mirror, you manufacturers. Those are the folks who are going to be doing this exactly who is going to pay for this. They never talk about this. I mean, that ongoing testing that's going to be performed against all of your products, all of your legacy products, I mean, start to think about what that means. That's a lot of money. There are no good answers here. Are we talking about a subscription service? I don't know. I don't think that would work. I mean, maybe it will. These days all the cybersecurity tools I buy are all subscription service, and I pay a lot of money every year to use some of the best of breed tools. Maybe that's the answer. But I think that's going to have its problems, too. So, I don't have a good answer for this one. All this added burden is going to get placed on the manufacturer, and really only at the cost of marginal improvements in cybersecurity. So, there's no real benefit to the manufacturer. Oh, I'm creating a view that the FDA can now look at. Well, that's just great. It's just another expensive box to check. But it really doesn't have to be that way. And I'm going to go back to the Health Sector Coordinating Council. Great organization. Right? So, their model contract language work took basically two years to accomplish with a multidisciplinary group. Resulted in 45 clauses that allow any and all HDOs to include cybersecurity in their contracts with manufacturers, thus decreasing to some degree their cybersecurity risk, and decreasing their cost to create that contract. They don't have to hire a cybersecurity lawyer to write legalese in here. We've given them that in the form of these clauses. This increases the speed of creating a new contract as well, gets these products into the marketplace faster, and will to some degree decrease the cost for manufacturers in reviewing these contracts. Because previously, they were all unique one- offs, lovely little snowflakes all of their own that had to do intensive research and investigation by each of the manufacturers before they could do this. Well, if we can start to standardize parts of it, like cybersecurity, that will speed up these contracts and get them unique. That's how you structure creating a standard to be a win- win for everybody. All right? It's not creating something brand new that's ill defined or undefined and no one supports and doesn't align with best practices that have been out there for decades. It's looking at how best it's going to align everybody and achieve your end goal of, in this case, creating secure medical equipment. So yeah, it's going to be interesting who's going to pay for these. I don't know. I don't have an answer.

Etienne Nichols: Yeah. Well, so, what do you recommend people do? So, I mean, we mentioned what's going on, what the implications are. Is there anything left for us to do, or are we just going to have to sit down and accept it?

Chris Gates: Well, unfortunately, between my client base and a lot of others that I've recently been into a couple of shows, including Quality Summit from Greenlight Guru, and I've talked with a lot of people, and I'm surprised at how many people are unaware of all of this that's taking place. I mean, maybe we've gotten to the point that it's so divisive in politics these days in this country, we try to ignore it. I guess I do, too. But these are stuff that's going to impact our business. So, the comment period for this guidance document closes on July 7th. That's not that far away. Go out there. Get this guidance document. Go read all 49 pages, for those who are keeping track, that's twice the size the 2018 one, of this new guidance, and push back on some of these new processes that the FDA is trying to create. It appears to be the only way we're going to get even hopefully a somewhat workable set of cybersecurity requirements out of the FDA in this premarket guidance. I wish it had a better development process, but that seems to be the only thing we can do at this point. So, get involved. Go look at it. See if there's things that, hey, maybe you like everything that's in it. Good. Good for you. I like the concepts of securing the medical device. It's the execution and what they're proposing that I'm not a fan of.

Etienne Nichols: Well, that sounds like a mic drop to me. I'll include in the show notes a link to that FDA comment section so that you can go directly there. So, go to the comments. Chris, if they were to reach out to you, how would they get ahold of you?

Chris Gates: Hi, I'm Chris, period, Gates, G- A- T- E- S, at www.velentium.com, V- E- L- E- N- T- I- U- M.

Etienne Nichols: Okay. And I may have volunteered you there for additional information from people, so sorry if your inbox gets flooded. Yeah.

Chris Gates: Actually, I don't mind this at all. I'm trying to raise my industry and get it to a workable point of secure development. So, I field questions all the time that are just very one- off. If the question is, how can I secure my medical device? Yes, we're going to start talking contracts. If it's, how do I do this one thing? How do I do threat modeling efficiently? What sort of crypto do I use for this activity? Feel free. I mean, this is what I do all day long. So, I can answer this stuff quickly off the top of my head.

Etienne Nichols: Okay, awesome. Well, go check out the FDA's website. Look in the link for the show notes, and we'll get that link directly to that guidance document for cybersecurity and medical devices. Chris, thank you so much for taking the time out of your day to talk about these things.

Chris Gates: A pleasure as always to be here. Thank you for having me.

Etienne Nichols: All right. As always, you've been listening to the Global Medical Device Podcast. Go make the industry a better place, and we'll see you next time. Improving the quality of life. I know we say it a lot here at Greenlight Guru, and I'll bet it's something you probably said at your company, too. We help babies breathe at night. We give you another day to be a dad. We give you back your eyesight. Those are some of the things the medical device industry and our customers are able to say because that's what they're doing. They're improving the quality of life for these individuals. Greenlight Guru is the only quality management software designed exclusively for the medical device industry. We built our software around standards like ISO 13485 and risk- based principles to help you bring safer devices to market three times faster. We're building the tools that will make it easier for you to build yours. If you're ready to find out how to improve the quality of life, contact www.greenlight.guru today.

About the Global Medical Device Podcast:

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.