Episode 52 · November 27, 2025 · 34m listen · 6,289 words · ~31 min read
What Is Required for an FDA Premarket Cyber Submission? | Ep. 47 - Full Transcript | The Med Device Cyber Podcast
Read the complete, searchable transcript of Episode 52 of The Med Device Cyber Podcast - expert conversations on medical device cybersecurity, FDA premarket and postmarket guidance, SBOM management, threat modeling, and penetration testing.
Prefer the listening experience? Open the episode page for the synopsis, key takeaways, topics, and Apple / YouTube listen links.
Episode summary
In this episode of The Med Device Cyber Podcast, hosts Christian Espinosa, Founder, and Trevor Slattery, CTO of Blue Goat Cyber, provide a detailed breakdown of the requirements for an FDA cybersecurity premarket submission. The central focus is on clarifying a common area of confusion: the 18 specific deliverables required by the FDA and how they map to the 13 cybersecurity sections in the eSTAR (Electronic Submission Template and Resource) template. The hosts begin by debunking the major misconception that the documentation requirements change based on the medical device's risk level. They emphasize that every device, from a low-risk oxygen pump to a high-risk surgical robot or pacemaker, must produce the same 18 types of documents. The difference, they explain, lies not in the *what* but in the *how much*; the complexity, depth, and level of scrutiny for each deliverable scale directly with the device's risk profile and complexity. A simple device might have a concise set of documents, whereas a highly complex, life-sustaining device will require significantly more extensive and detailed documentation, potentially spanning hundreds of pages.
The discussion then unpacks the structure of these 18 deliverables and their relationship to the eSTAR template, explaining the "many-to-one" mapping. For example, the overarching "Risk Management Report" deliverable actually comprises four distinct sub-documents: the Threat Model (often using the STRIDE framework), the Cybersecurity Risk Assessment, the Software Bill of Materials (SBOM), and SBOM supporting materials which detail component support and maintenance plans. Similarly, the single "Cybersecurity Testing" section in eSTAR is satisfied by four separate deliverables: the Static Application Security Testing (SAST) report, the overall test plan, the specific test cases, and the final test report. This modular approach, they argue, provides a more structured and review-friendly process for both the manufacturer and the FDA. The hosts also touch upon cybersecurity labeling, which itself consists of multiple documents tailored to different audiences, including the JSP2 for end-users and the MDS2 for hospital IT departments, as well as specific interoperability risk assessments for connected devices that influence clinical decisions.
The overarching advice from Espinosa and Slattery is for manufacturers to "begin with the end in mind." They strongly advocate for integrating the creation of these 18 deliverables into the product development lifecycle from the outset. Rushing to generate this comprehensive documentation package just before a submission deadline is inefficient and difficult, as it relies on source materials and analysis that should be conducted throughout the development process. By understanding these requirements early, manufacturers can build a robust, defensible, and compliant submission package that demonstrates a commitment to security, rather than treating cybersecurity as a last-minute checkbox. This proactive methodology not only streamlines the regulatory process but also results in a more secure and trustworthy medical device.
Key takeaways from this episode
The 18 cybersecurity deliverables for an FDA premarket submission are the same for all medical devices, regardless of their risk classification.
The required documentation does not change, but the level of detail and complexity scales based on the device's risk profile and intricacy.
The 18 deliverables map to the 13 cybersecurity sections of the FDA's eSTAR template in a "many-to-one" structure.
Major deliverable categories include a comprehensive Risk Management Report (with threat model and SBOM), extensive Cybersecurity Testing documentation, and specific Cybersecurity Labeling.
Risk assessment for medical devices should focus on the actual worst-case scenarios related to patient harm, not just hypothetical data breaches.
Manufacturers are advised to "begin with the end in mind," incorporating documentation creation throughout the entire product development lifecycle.
The Cybersecurity Management Plan (CSMP) is a crucial document detailing the strategy for post-market security management, including vulnerability monitoring and patching.
For unresolved anomalies or residual risks, manufacturers must provide a thorough assessment of their potential safety and security impact.
Christian: Hi, welcome back to another episode of the Med Device Cyber podcast. Today we're talking about something that is commonly must understood. It's what is required for a FDA cybersecurity pre-market submission.
Uh and there's 18 deliverables that we're going to go through today briefly and show you how they map to eSTAR which has 13 sections. Uh and there's a little bit of confusion like, why do we have 18 deliverables and 13 sections, but we'll explain a rationale for that and a little bit of overview of what makes up each of these deliverables.
I'm here with Trevor. He's our co-host. I'm Christian Espinosa, founder, Blue Goat Cyber, Trevor's our CTO.
Trevor: Yeah, and 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. And we'll talk with some prospects or clients saying, hey, you know, this is a low risk device. Um, 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, and 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, risk profile, you always are going to prepare the same deliverables at 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, uh maybe a single diagram for your architecture views where 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.
Christian: So just to, just to back up for one second. You're so you're saying uh, I just want to make sure our listeners understand that a class three 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 two device, uh which is mainly a 510K and sometimes a De Novo submission.
Trevor: 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. 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, uh 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 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 uh 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.
Christian: Awesome, that's good background. So before we jump into the actual list, one more thing I wanted to go over, which version of eStar are you referring to with the 13 sections that we map our 18 deliverables to?
Trevor: So we're currently on E-star version 6 as of October 1st, so two weeks ago at the time that we're recording. Now, when this, we also have E-star version 5.6, which is the previous version that we were on. That was when some of the, that was the most recent change to the actual documentation requirements. Now, with that in mind, um that's more on alternative submission pathways but the E astar headings haven't changed too much since the initial September 2023 guidance for traditional submission pathways. Um but we are currently on E star version 6.0 and that would be what we're talking about in with the latest FDA cyber security guidance published in July of this year 2025.