What Is Required for an FDA Premarket Cyber Submission? | Ep. 47 - Full Transcript | The Med Device Cyber Podcast

Hi, welcome back to another episode of the Med Device Cyber Podcast. Today, we're talking about something that is commonly misunderstood: what is required for an FDA cybersecurity pre-market submission. There are 18 deliverables that we're going to go through today briefly and show you how they map to EAR, which has 13 sections. There's a little bit of confusion like why do we have 18 deliverables and 13 sections? But we'll explain the rationale for that and provide a little bit of an overview of what makes up each of these deliverables. I'm here with Trevor. He's our co-host. I'm Christian Espinosa, founder of Blue Goat Cyber. Trevor is our CTO. I think the first thing that's really good to talk about is drilling a little bit more into that point you just made where it's always the same deliverables no matter what. This is probably one of the bigger misconceptions about cybersecurity. We'll talk with some prospects or clients saying, “Hey, you know, this is a low-risk device. Do we need all of this? I can get why you would need all this for a surgical robot or for a drug infusion pump, but do you really need this for an oxygen pump?” It doesn't make sense. And the answer is yes. This is stated in the FDA guidance as well. In appendix 3, they state that the documentation does not change. No matter what type of device submission pathway regarding risk profile, you are always going to prepare the same deliverables. However, there will be a scaling level of complexity based on device risk and device complexity. So in that example, an oxygen pump, single functionality, single interface, probably going to be pretty brief when you're talking about your security controls. You might have a few here and there, maybe a single diagram for your architecture views. Whereas if you're thinking about a diagnostic platform, surgical robot, something more complicated, these are going to be very lengthy, detailed deliverables. So that's where we're going to start to see some of the distinctions. But with that in mind, speaking to some of those points, we'll go ahead and just start from the top and work our way down. So, just to back up for one second, you're saying, I just want to make sure our listeners understand, that a Class 3 device, which is a PMA submission, we do the same 18 deliverables. It's just the degree of scrutiny and the complexity of that device and the degree of risk is greater typically. So there's going to be more documentation and more testing involved than potentially a Class 2 device, which is mainly a 510k, and sometimes a De Novo submission. Exactly. So if we have complicated, high-risk devices, we're preparing those same deliverables in just very great detail. There's also way less tolerance on our risk assessments for high-risk devices just by nature of their use. When we're scoring risk, we have a very unique methodology that we follow. So it's a custom methodology that we've developed in-house here where our risk is based on the actual worst-case scenario as opposed to hypotheticals around data, which is more traditional for cybersecurity risk assessments when we're looking at XYZ vulnerability leads to XYZ result, instead of what is the vulnerability. So if we have, say, picking an example out of a hat, a buffer overflow where we can write into memory and control the device in an oxygen pump, not a big deal. Okay, maybe we can turn off the flow of oxygen or increase it or something like that, but it's not really going to hurt anyone. And so we might say, well, we can cause a disruption to the therapy treatment. We'd probably call that maybe a medium risk. If we can do that in a pacemaker, alter its operation, that's immediately a critical vulnerability. We can see immediately how someone would die from that. So the same vulnerabilities are going to present differently in different products. And high-risk devices have so much less wiggle room to try to get through just compensating controls or soft mitigations like that as opposed to completely removing risk. So that's another area where we're seeing a lot more distinction between low-risk and high-risk devices. Awesome. That's good background. So before we jump into the actual list, one more thing I wanted to go over: which version of EAR are you referring to with the 13 sections that we map our 18 deliverables to? So we're currently on EAR version 6 as of October 1st, so two weeks ago at the time that we're recording. Now, we also have EAR version 5.6, which is the previous version that we were on; that was when some alternative, that was the most recent change to the actual documentation requirements. Now, with that in mind, that's more on alternative submission pathways, but the EAR headings haven't changed too much since the initial September 2023 guidance for traditional submission pathways. But we are currently on EAR version 6.0 and that would be what we're talking about with the latest FDA cybersecurity guidance published in July of this year, 2025.