What Is Required for an FDA Premarket Cyber Submission? | Ep. 47

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.

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. Christian: Okay. And why the 18 uh deliverables mapping to the 13 sections of EST star 6.0. Trevor: Well, there are a couple of items that are difficult to capture in a single deliverable or a single process. So I'll speak specifically to the ones where we do a many to one mapping and then we can go through the full list. Um the areas where we do a many to one mapping is with the S balm, with our cyber security testing and with our cyber security labeling. For the S-BOM, the FDA requires the software bill of materials itself. We prepare that in industry recognized formats with NIA specifications and we submit that. In addition to the S-BOM, we need the software level of support and whether or not the component is actively maintained. We need all of that information to be provided to the FDA as well. So when we're going through that, that is generally something that's supplementary or supporting material. There's some parts where we can roll it directly into the S-BOM, but we like to go above and beyond as well and provide any strategies for ongoing monitoring and maintenance around the S-BOM specifically since this can be a very sensitive area. So we have the S-bomb itself that maps to the S-bomb heading in EST star, and then we have all the supporting material that also maps to the S-bomb heading EST star. For cybersecurity testing, the FDA calls it cybersecurity testing instead of penetration testing, instead of vulnerability assessments for good reason. It's a very big umbrella that we have here. There are a lot of items that go into it. With our process, it's a little bit modular, so we have our static testing as a separate deliverable, our S-BOM assessment as a separate deliverable, our test plan, our test cases, our test report are broken up not only for the ease of our customer review. So when we're working with clients, we can say here's your test plan ahead of us executing the test as opposed to just throwing the entire package at them at once. Here are the test cases that we're going to execute once we have confirmed this test plan is good. Double check on this. Move into our test report. This is essentially just a pass fail on our test cases. So the process that we adhere to is very structured and regimented and it makes more sense for us to break out these deliverables a little bit more as opposed to having everything in one go. Cybersecurity labeling is another area where we break this out and this is mostly for the distinctions between what the FDA wants to see and what HDOs and insurance want to see. The FDA's labeling approach maps most closely to the JSP2 Customer Security Documentation, which is a standardized medical device development and software practice framework. But customer requirements, hospital requirements, insurance requirements more closely map to an MDS2. That's a manufacturer disclosure statement for medical device security, I believe. And that form is a lot more complicated, mostly focused on the interoperability of products. The FDA is less focused on that, they're more focused on the first one. The inverse is true for HDOs. So we try to help get our clients prepared for the post regulatory step as well. The final document that we have in that labeling is specific labeling focusing on interoperability. So when you have a device where there's a connection or a data flow that is actively supporting or making a clinical decision, you need to have specific interoperability labeling and risk assessments provided for that interface. So this is not applicable to every device. When that is applicable, you need to make sure you're talking about how that device or how that connection is used safely, securely. Um what some of the contradictions around it could be, how you're maintaining time synchronization, what standards were put into place to develop this? Who are the intended users of this interface? Things like that. So those are where we have this many to one mapping within E-Star. Christian: All right, very thorough and well sought out explanation. I like the mini-to-one mapping, which is exactly what it is. So let's uh run down the list. So the first item on our list is the risk management report, which has four things under it, but there is an actual report and the way we organize it there's four things under it, a threat model, the actual cybersecurity risk assessment, the S-bomb, and the S-bomb supporting material. So let's just start with the overriding document, the risk management report, and maybe you can explain that a little bit, then we'll go down each of the subsections of the four. Trevor: The risk management report should be thought of as a process summary or the outcome of going through a clean and repeatable cybersecurity risk management framework. Our preference is AAMI TIR57, which is starting to shift more towards AAMI SW96 for a little bit more of a modernized and all-encompassing cybersecurity risk management framework. Um but regardless of the standard, it is essentially an outcome, uh an outcome summary talking about the activities that went into the risk assessment and the conclusion of the risk assessment. Now, moving into the specific activities, we're talking about how we go through our threat modeling exercises early, our vulnerability identification, how we're scoring these risks, what we're doing for risk mitigation, pre and post production activities after the fact. So the risk management report is essentially just boiling down all of these items into what can be thought of as pretty much just a summary. Moving into some of the sub items is when we get a little bit more detailed in the process. So the sub items you mentioned, the threat model, cybersecurity risk assessment, S-BOM, and S-BOM supporting material. We talked a little bit about those last two and how they're mapping to a single heading under E-Star, but we'll talk about the threat model. Our threat model is top of the risk management report for a pretty good reason. It's often going to be top of the risk management process as well. This is when we're going through hypothetical exercises to say, what do we think could go wrong with this device. Um, FDA prefers threat modeling based off of the MITRE playbook for threat modeling medical devices, which asks you four main questions. What are we working on? What could go wrong? What are we going to do about it? And did we do a good job? So it's really trying to think, you know, based on the product, based on the experience of our team, our engineers, our cybersecurity team, what can we do wrong to this device and how can we fix it proactively? Before moving into your testing, before moving into your risk assessment, all these activities to verify what can actually go wrong. Christian: And I think one important thing to mention there also is, we think what can we do wrong, but there's also a framework applied to that, the STRIDE framework. So we look at it through, can we spooof something, can we tamper with it, there's a little more granularity or specificity in than just what can go wrong, right? We're looking through the specific lens of STRIDE. Trevor: Exactly, yep. And there are a few different threat modeling frameworks that can be applicable, STRIDE, DREAD, MI ATT&CK, some of the more popular ones. We prefer STRIDE since it is, it covers a lot of ground, um and it's very easy and very flexible to do mapping as well. You can do element to STRIDE mapping, STRIDE to element mapping, where you're picking a component and then saying it's applicable to the STRIDE categories or you pick STRIDE categories and list the components that might be applicable to each one. So even within that there are several different ways to go through that threat modeling exercise, which is why we prefer to use it due to its flexibility and granularity. Christian: And I would say acceptance on the market is as, I mean there's PASTA and DREAD and everything else, but STRIDE is probably the most accepted and best practice I would say. Trevor: Yep. Yeah, it's pretty common place, especially in this industry. um to use STRIDE and it is pretty standard to see that. If you ask someone for a threat model, just whatever they have internally, odds are pretty good, they're going to give you a STRIDE threat model. Christian: Cool. So do we discover, discussed threat models in enough detail, you think, for people to get a concept of them? I guess, what do the links of the MITRE framework, MITRE playbook? Trevor: At the high level and under the context of what we're talking about within our risk management process. And any of this threat modeling acts as input and helps with our decide or our decision making on what should we do for our testing? What should we do for our risk assessment, which is the next item that we require under our risk management report. The risk assessment is the actual outcome of what we identified. So we have our threat modeling, what we think can happen. Our testing, what can actually happen, and our risk assessment, what does that mean? So the risk assessment talks about the criteria that goes into this vulnerability, what situations must be true for this vulnerability to be executed, the exploitability factor, what happens when this vulnerability is successfully executed in a live environment, the impact. We meet the intersection of those two items and that gives us a score. Whatever that score is, we can say this is controlled, uncontrolled, acceptable, unacceptable, however you want to put it, but we're trying to do with this risk assessment is sift through all of the hazardous scenarios that we can identify in the device, understand what are our big ticket items, what might be acceptable risk and just categorize everything. So this risk assessment is essentially the outcome of that process. Christian: That process or methodology needs to be defined in the risk assessment as well. So we have a repeatable process that is very articulate as well. Trevor: Exactly yeah and I think you bring up a good point this needs to be defined in the risk assessment. This isn't something that can be done ad hoc or a little bit you know you can't apply different methodologies to different risks. You have to have things in a standardized simple approach so that you're using a clean repeatable process in the entire life cycle of the device with your security and safety intersection with all of these different risks. Of course factors may change um often post-production activities and post-market vulnerabilities will have different factors in play than pre-market vulnerabilities. um as a more common example but we still need to have that clean repeatable process that we're adhering to for any risk in the device. Christian: Okay, awesome. I think we covered that one, the risk assessment pretty decently. Uh you hit on exploitability, threat models and input, testing helps them form the realization of that input if we can actually do what's on the threat model. And then uh the next item is S-bomb the software bill of materials, which is really all the third party components that make up the software that the manufacturer has developed. Uh and there could be vulnerabilities with those third-party libraries uh and this provides that traceability which is a big push for the FDA. So we have complete visibility and traceability into all the items that make up our software. Uh the fourth item we have on here is a software bill of material supporting material, which you alluded to this before, uh which is essentially for any of those third party libraries, what is the expectation that they're going to be managed properly? Is that correct? Trevor: Just about. We're looking at what components are actively supported. So these are components where the original engineer manufacturer working on them is still pushing out security patches for the component or regular updates for the system. Uh especially with open source components, these can often just be dropped on a whim, so it's pretty important to see what is actively maintained and what might need a little bit closer of a focus. Part of what we do is we prepare and submit a plan for what we're going to do in the event that any component becomes no longer supported with minimal notice. Since this is a situation that happens all the time. A lot of these are just passion projects and the maintainer doesn't want to do it anymore. We need to have a strategy for analyzing the risk, saying how are we going to pivot out of this component if there is unacceptable risk in it, how are we going to do accelerated monitoring, can we fork it ourselves? There are a lot of different strategies we can take. But what we want to do is make sure that any potential risks that could come up in the S-bomb are properly and safely mitigated. Christian: Cool, so we covered the risk management report which had the four subsections, threat models, cyber security risk assessment, the SB and SB supporting material. Let's go to the next deliverable, which is the cyber security assessment of unresolved anomalies, which there's a lot of confusion on this one, maybe you can provide some clarity. Trevor: So an unresolved anomaly in the traditional sense is a feature in the software that behaves strangely for some reason, maybe you know, maybe you don't, maybe it just can't be mitigated or maybe you have no idea why the software is misbehaving. But whatever it is, it is something that is unintended behavior in the product that may or may not have an impact, may or may not have a risk, it might just be annoying, but it's something that it should not do. What the FDA wants to see is that we're going through a list of any of these known anomalies in the product where it's behaving in a strange way and capturing whether or not there could be a safety or security risk from that anomaly. So as we're doing an assessment of any weird behavior in the software, we also are doing this assessment on anything that is determined to be acceptable residual risk in the software. That's going to be unintended behavior that becomes a part of the system and is acceptable risk, so we think that should be registered as an anomaly with these other ones. When we're going through that assessment, we have to map the anomaly to our evaluated impact relating to cybersecurity, whether or not we think it has some impact. Maybe it's low impact, maybe it's none. Uh and the FDA also wants to see that we're mapping this to the CWE category. So the CWE category There's a CWE that maps to that. So that way we're have we have an understanding of what category this is going to be. Generally, cybersecurity vulnerabilities within a specific category are going to lead to a specific outcome. So we can have a better way of tracking these anomalies in the future. Christian: Good explanation. Let's move on to the next one, which uh we have cyber security metrics, which includes measures and metrics. Uh I think we have it called cyber security metrics that maps to eStar. So this one is a a challenging one too from my experience with our clients uh because we're sort of looking at things we may measure in the future. So what is uh your explanation on this one? Trevor: Yeah, so the FDA wants to look at a few main metrics as minimum baselines and then anything additional that the manufacturer sees as applicable in the device. These main metrics are the percentage of vulnerabilities that are remediated or the overall defect density of the product. The timeline for remediation or patch development in the system and timeline for deployment in field of devices. These items are things that you should track for field of or if you are submitting with a predicate device that you control, you should reuse the measures and metrics from that predicate device. Now, given that medical devices typically have long development cycles, we are still pretty new to this modern cyber security guidance and so we're dealing with a lot of manufacturers submitting their first product. Um a lot of these manufacturers are not going to have these measures and metrics readily available internally. So they're more looking to the future to capture this and then leverage it for future submissions or maintain it within their device. In additional area that the cyber security metrics deliverable captures is talking about the total product life cycle considerations within the medical device. So how you're going through your ongoing vulnerability identification, remediation process, maintaining your design history file, process review, and your risk profiles within your medical device are all captured in this area as well. The cyber security metrics deliverable is essentially trying to capture data from your vulnerability posture in your device and talk about how you're capturing that data. Christian: Awesome. All right, let's go to the next one, which is the cyber security controls, also known as the security controls and it has several categories to where we talk about how the device manufacturer is covering specific controls from a cyber security lens. Trevor: For the most part, what we're looking at with that is just what specific controls are within a device to boost the security posture in a range of categories. The FDA lists some of their examples. We were going over a few of those as far as what they think should be applicable, but they also state that you may have some unique ones in your product. Whatever controls you have that increase the security posture and whatever category they're going to map back to, you should document how you are boosting the security posture around confidentiality through XYZ controls. How you're insuring that your authentication is safe because of XYZ controls. So that's pretty much all we're doing in this deliverable is saying these are these different critical security concerns and here are the different controls we have to make sure that these concerns are addressed. Christian: Right. Or to say that this control is not really relevant to the way we've implemented our product as well. Trevor: Exactly. Christian: So, let's go to uh the next one, which is security architecture views. Trevor: So the security architecture views are meant to capture what the device is and then specific scenarios on how device design can prevent hazardous situations. So those four views at just the highest level are the global system view, what is the device, what are all the components within the device, what does that look like? The multi-patient harm view, what situations or scenarios can lead from a single compromise of one device to the harm of multiple individuals? The updatability and patchability view, how are secure update mechanisms built into the device? And then security use case views, which are specific use cases in the device, think power on, power off, therapy administration and how is security built into these use cases? So for these different functionalities, different states in the device, we're just trying to map security to specific components within the product. Christian: Awesome. That brings us to the next one, which is uh really the plan for post-market management called the Cyber Security Management Plan. Uh other than that's the plan and how you're going to manage the product once it's cleared and on the market, what else should we discuss about that document? Trevor: So the cyber security management plan talks about a lot of active responsibility for field devices. There are ongoing testing requirements, you have to host and maintain a coordinated vulnerability disclosure panel, there are a lot of recommended third party resources that you need to subscribe to, you need to have accelerated ongoing monitoring for your S-BOM, tracking against known vulnerable vulnerabilities. There's a lot that goes into this process. So exactly like you said, we're trying to convey to the FDA how security is to be addressed once the device has been field. With that in mind, this is quite a big document and often requires a lot of commitments from the manufacturer to ensure that security posture is met. It's not a passive process, it is a very involved active process. Christian: Cool. So let's go to the next one, which is one of those many-to-one mappings, the cyber security testing, which has four subsets to it. We have SAST, the test plan, test cases and test report. We'll start with SAST, which is one of the subcomponents to the overriding category of cyber security testing. SAS the static application security testing and that's basically where we run through the source code and look for flaws in the source code using a tool with some manual analysis as well to help eliminate false positives and the results of that are put into a SAS report. Trevor: And I will note that's pretty much the only reason why this is a separate deliverable. Um there are a lot of different types of cyber security testing that we go through, but the SAS is done with separate tooling, separate targets and separate processes. Similar to our SBOM risk assessment, which is captured as part of a spam supporting material, but we're scanning directly against the source code instead of the compiled code or the product, which is where we're doing most of our testing for the other activities. So that's the only reason this is broken out as a separate deliverable. Moving into our other deliverables, that's talking about our cybersecurity testing. That includes vulnerability assessments, dynamic application security testing, penetration testing, abuse case testing, misuse case testing, fuzz testing, robustness testing, vulnerability chaining, there's a lot that goes into it. All of this is derived from NI special publication 800-115. That's what our deliverables look like and that's what our process looks like. So for the most part, we're just breaking it in. I talked a little bit about why we separate these deliverables mostly for ease of review with our clients, but we're capturing all of these different activities within single deliverables here. Christian: Yeah, it's also best practice to have a plan, the test cases, and then the test report which is a validation of the applicable test cases that passed or failed. Trevor: Yeah, and this is something that should be applicable in every industry, but most of the time if I'm looking at a penetration test report for SOC 2 compliance or HIPAA compliance, I can't think of too many times I've actually seen a dedicated test plan prepared for one of these industries since it's not an explicit requirement there. It is with the FDA, but in the industry, it is considered a best practice that is unfortunately not always adhered to. Christian: Okay, so let's go to the next overarching category, the many-to-one mapping, which is cyber security labeling, which has uh three subcomponents to that, the JSP2, MDSS2 and interoperability. So you want to explain uh I mean from a labeling perspective, we're trying to show some transparency to whoever is purchasing our device, like what the risk are, uh how to use the device, various scenarios that should be used in, various environments that should be used in, and what the risk is. But what else is really going into these three documents? Um the JSP2 and MDSS2 and interoperability. Trevor: Well, that's going to vary a little bit, but what we're trying to do is capture enough information that users are able to configure and operate the device safely and securely. This is going to depend a lot on who is the user, where is this being used? An oxygen pump for home use, very different from a surgical robot set up in an OR suite. So, we need to think about who is going to be reading this document and what level of information do they need. If we're thinking an oxygen pump and someone's home, you might expect an elderly patient, someone who's maybe not very technically savvy and so they're not going to need too much information on what the internal architecture of the device looks like. They more need to know, here's how to safely pair Bluetooth to your phone, or here's what you need to be aware of. Here's what some of these warnings mean. Where if you're talking about a surgical robot and trying to convey that to an installer or a hospital IT admin. Here's how you safely integrate this into an existing active directory infrastructure. Here's how you build this out into different types of networks. Here's how you can set up a segmented network for specifically this robot, but that information might go over a lot of people's heads. So, it's a balance to strike here, but all these deliverables are trying to do is capture things from slightly different approaches, to be a little bit more geared to the FDA, to healthcare delivery organizations, to end users and just ensure that they are armed with the appropriate information to use the device securely. Christian: And so they can make an informed decision on even if they want to use a device from a cyber security perspective as well. Trevor: Exactly, yeah. Part of this labeling is disclosing existing risk in the device and it may be the case that you disclose a certain level of risk that the patient is uncomfortable with and they don't want to be they don't want to receive therapy from this device since they are not comfortable accepting that level of risk. That is their informed decision to make and manufacturers need to provide them with that information so they can make this decision. Christian: Yeah, like if I'm going to buy a defibrillator and it's got some disclosed wrist that every six months is going to randomly shock me. Maybe I don't want to uh purchase that particular brand of defibrillator. Trevor: That might be the worst case scenario with a defibrillator. Just random surprise shock. Christian: I would probably not buy that one. I'd prefer the one that doesn't have that that risk associated with it. But that's the whole point, right? We're trying to make an informed decision not just for the patient but the healthcare delivery organization as well. Trevor: Yeah, and it'd be the same as, you know, saying, if this phone blows up every, you know, every third phone just explodes. Probably wouldn't have bought this phone. And if Samsung was hiding from me that these phones tended to explode, which that's definitely never happened before, but um if they were hiding that, then I'd be pretty upset if I bought this phone and it exploded. Christian: That is not being transparent, which is what we're pushing for. All right, with the last one is the interoperability risk assessment. Trevor: So, for this one, we can actually bundle in the interoperability labeling into this category as well since these are not or not optional but not always required deliverables. You need to have a data flow that is making or supporting a clinical decision not just transferring or converting formats, not used for purely maintenance, not an inactive interface for these to be applicable. As long as that criteria is met, you need to talk about how that interoperable connection is prepared safely and has a proper risk assessment conducted against it since you are relying on external components for a critical component of the software or a critical use case of the product. As soon as you are relying on things that you can't control, you need to have really tight considerations on what you can control. So that's mostly what we're looking at here is how those considerations are factored in and how we're securely and safely interacting with other products. Christian: Awesome. So we've covered them all. I'll go a quick review of the list here. Uh we got the risk management report which consists of the threat model, the cyber security risk assessment, the S-bomb and S-bomb supporting material. We have the cyber security assessment of un-resolved anomalies. uh cyber security metrics which includes the measures, security controls, security architecture reviews, cybersecurity management plan, which is also the postmarket management plan effectively, cybersecurity testing which has four things that fall under that umbrella, SAST, the test plan, test cases, test report, cybersecurity labeling, three things fall under that umbrella, JSP2, MDS2 and interoperability. And finally we have the interoperability risk assessment. So we covered all 18 deliverables that map to the 13 sections of E-R 6.0 Any anything else we should discuss in terms of this topic here, Trevor? Trevor: Yeah, I think that covers about everything. Um the one thing I do want to note is this these list of deliverables are expected for new submissions or expected for um submissions where there's a cyber material cyber security change. There are other submission pathways if you're making different types of changes, but that might be a conversation better suited for another time. Christian: Before we wrap up last minute words of wisdom or final thoughts here. Trevor: I think start with the deliverables at the end in mind. Uh this is a common situation that comes up not just with cyber security, but even with general regulatory problems is we go through all these activities, rushing to make a product, we're really excited to get it out the door and then we opened up that FDA submission filing and they require 100 deliverables and we didn't even know. understand what you're going to have to prepare and just start getting ready for it. You're going to have to prepare all these deliverable. This is not a nice to have, this is a requirement. What can you do to get ready for it early? How can you build out your software documentation maturely to act as input into your security documentation. Make decisions like this early on and just start with the end in mind. Christian: I agree with that. And we've taught we've talked about the 18 deliverables, but the reality is on our from our experience, uh this could range from for a very simple device like 150 pages to a complex device, we could be talking over 600 pages of documentation. So as Trevor said, begin with the end of mind and start working on the documentation sooner than later because it is very hard to do all the documentation in a extreme time crunch when you don't have source documents that are needed to create the uh deliverables to the FDA. And if you have any help with this, this is what we do at Blue goat cyber. We could do all these documentation, all these documents for you and take the learning curve off your shoulders, so feel free to contact us if you're interested in that as well. Trevor: Makes it a lot easier for us when we only do one thing, but we do it very well. Christian: Yes. I I can't imagine if I was a medical device manufacturer trying to figure out how to do all these things, plus everything else that goes into producing that product. It would it would be very overwhelming. Cool, thanks for tuning in to the Med device cyber podcast. We hope you found value in this podcast and be sure and reach out to us if you have any questions about the 18 deliverables that go into an FDA pre-market submission or if you just want any help in general with medical device cyber security. Hope to see you next time. Thanks.