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

This episode of The Med Device Cyber Podcast unravels the often-misunderstood requirements for FDA cybersecurity premarket submissions. Hosts Christian Espinosa and Trevor Lynch demystify the 18 essential deliverables that map to the 13 sections of EAR 6.0, emphasizing that documentation requirements remain consistent across all device types and risk profiles, with complexity scaling based on the device. The discussion delves into critical elements such as the Risk Management Report, which encompasses threat modeling (using frameworks like STRIDE), cybersecurity risk assessment, and the Software Bill of Materials (SBOM) along with its supporting material. The hosts highlight the nuances of cybersecurity assessment of unresolved anomalies, the forward-looking approach to cybersecurity metrics, and the importance of robust security controls and architecture views. A significant portion of the conversation is dedicated to the Cybersecurity Management Plan for postmarket activities and the detailed aspects of cybersecurity testing, including SAST, test plans, and reports. Finally, the episode covers cybersecurity labeling, distinguishing between JSP2, MDS2, and interoperability considerations. This episode is a must-listen for product security teams, regulatory leads, and engineers navigating the intricate landscape of medical device cybersecurity compliance and aiming for efficient premarket submissions.

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. Okay. And why the 18 deliverables mapping to the 13 sections of EAR 6.0? 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. The areas where we do a many-to-one mapping is with the SBOM, with our cybersecurity testing, and with our cybersecurity labeling. For the SBOM, the FDA requires the software bill of materials itself. We prepare that in industry-recognized formats with NTIA specifications and we submit that. In addition to the SBOM, 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 are some parts where we can roll it directly into the SBOM, but we like to go above and beyond as well and provide any strategies for ongoing monitoring and maintenance around the SBOM, specifically since this can be a very sensitive area. So, we have the SBOM itself that maps to the SBOM heading an EAR and then we have all the supporting material that also maps to the SBOM heading in EAR. 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 SBOM 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's and insurers 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, 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 EAR. All right, very thorough and well-thought-out explanation. I like the many-to-one mapping, which is exactly what it is. So let's 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 are four things under it: a threat model, the actual cybersecurity risk assessment, the SBOM, and the SBOM supporting material. So let's just start with the overarching document, the risk management report, and maybe you can explain that a little bit, then we'll go down each of the subsections of four. 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 TR57, which is starting to shift more towards AAMI SW96 for a little bit more of a modernized and all-encompassing cybersecurity risk management framework. But regardless of the standard, it is essentially an outcome, an outcome summary talking about the activities that went into the risk assessment and the conclusion of the risk assessment. Now moving into those 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 those sub-items you mentioned, the threat model, cybersecurity risk assessment, SBOM and SBOM supporting material. We talked a little bit about those last two and how they're mapping to a single heading under EAR, 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? 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. 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 spoof something? Can we tamper with that? There's a little more granularity or specificity than just what can go wrong, right? We're looking through the specific lens of STRIDE. Exactly. Yep. And there are a few different threat modeling frameworks that can be applicable: STRIDE, DREAD, MITRE ATT&CK, some of the more popular ones. We prefer STRIDE since it covers a lot of ground. 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. And I would say acceptance on the market is, I mean there's PASTA and DREAD and everything else, but STRIDE is probably the most accepted and best practice I would say. Yep. Yeah. It's pretty commonplace, especially in this industry, 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. Cool. So do we discuss threat models in enough detail, you think, for people to get a concept of them, I guess, through the lens of the MITRE framework, MITRE playbook? At the high level and under the context of what we're talking about within our risk management process, any of this threat modeling acts as input and helps with our design 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 what 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 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. 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, often post-production activities and postmarket vulnerabilities will have different factors in play than pre-market vulnerabilities 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. Okay, awesome. I think we covered that one. The risk assessment pretty decently. You hit on exploitability, threat models as input, testing helps inform the realization of that input if we can actually do what's on the threat model. And then the next item was SBOM, the Software Bill of Materials, which is really all the third-party components that make up the software that the manufacturer has developed. And there could be vulnerabilities with those third-party libraries. And this provides that traceability which is a big push by the FDA. So we have complete visibility and traceability into all the items that make up our software. The fourth item we have on here is a Software Bill of Material supporting material, which you alluded to this before, 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? Just about. We're looking at what components are actively supported. So these are components where the original engineer or manufacturer working on them is still pushing out security patches for the component or regular updates for the system. 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 it's a situation that happens all the time, a lot of these are just passion projects. 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 SBOM are properly and safely mitigated. Cool. So, we covered the risk management report, which had the four subsections: threat model, cybersecurity risk assessment, the SBOM, and SBOM supporting material. Let's go to the next deliverable, which is the cybersecurity assessment of unresolved anomalies, which there's a lot of confusion on this one. Maybe you can provide some clarity. 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 we have no idea why the software is misbehaving. But whatever it is, it is something that is 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 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. And the FDA also wants to see that we're mapping this to the CWE category. So the CWE category is Common Weaknesses Enumeration, I believe, and that is essentially mapping a specific problem to a category of problems. So you might say that this vulnerability is relating to sensitive information disclosure in a web header. There's a CWE category for that. This vulnerability is rating or this anomaly is relating to insufficient logging mechanisms. There's a CWE that maps to that. So that way we 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. Good explanation. Let's move on to the next one, which we have cybersecurity metrics, which includes measures and metrics. I think we have it called cybersecurity metrics that maps to EAR. So this one is a challenging one too, from my experience with our clients, because we're sort of looking at things we may measure in the future. So what is your explanation on this one? 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 the timeline for deployment in fielded devices. These items are things that you should track for fielded devices 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 cybersecurity guidance and so we're dealing with a lot of manufacturers submitting their first product. 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. An additional area that the cybersecurity metrics deliverable captures is talking about the total product lifecycle 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 cybersecurity metrics deliverable is essentially trying to capture data from your vulnerability posture in your device and talk about how you're capturing that data. Awesome. All right, let's go to the next one, which is the cybersecurity 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 cybersecurity lens. 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 ensuring 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. Right, or to say that this control is not really relevant to the way we've implemented our product as well. Exactly. So let's go to the next one, which is security architecture views. 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. Awesome. That brings us to the next one, which is really the plan for postmarket management, called the cybersecurity management plan. 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? So the cybersecurity management plan talks about a lot of active responsibility for fielded 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 SBOM tracking against non-exploited 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 fielded. 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. Cool. So, let's go to the next one, which is one of those many-to-one mappings. The cybersecurity 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 overarching category of cybersecurity testing. SAST is 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 SAST report. And I will note that's pretty much the only reason why this is a separate deliverable. There are a lot of different types of cybersecurity testing that we go through, but the SAST is done with separate tooling, separate targets, and separate processes, similar to our SBOM risk assessment, which is captured as part of SBOM 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 NIST 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. And I've 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. 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: they passed or failed. 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. Okay, so let's go to the next overarching category, the many-to-one mapping, which is cybersecurity labeling, which has three subcomponents to that: the JSP2, MDS2, and interoperability. So you want to explain, I mean from a labeling perspective, we're trying to show some transparency to whoever is purchasing our device, like what the risks are, how to use a device, various scenarios it should be used in, various environments it should be used in, and what the risk is, but what else is really going into these three documents, the JSP2 and MDS2, and interoperability? 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 is very different from a surgical robot set up in an O-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 in 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. Now, 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 specifically for 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. And so they can make an informed decision on even if they want to use a device from a cybersecurity perspective as well. Exactly. Yeah. A 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. Yeah. Like if I'm going to buy a defibrillator and it's got some disclosed risk that every 6 months it's going to randomly shock me, maybe I don't want to purchase that particular brand of defibrillator. That might be the worst-case scenario with a defibrillator. Just random surprise shock. I would probably not buy that one. I'd prefer the one that doesn't have 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. 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 if they were hiding that, then I'd be pretty upset if I bought this phone and it exploded. That is not being transparent, which is what we're pushing for. All right. Well, the last one is the interoperability risk assessment. So for this one, we can actually bundle in the interoperability labeling into this category as well since these are often, 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 this 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. Awesome. So we've covered them all. I'll do a quick review of the list here. We've got the risk management report, which consists of the threat model, the cybersecurity risk assessment, the SBOM, and SBOM supporting material. We have the cybersecurity assessment of unresolved anomalies, cybersecurity metrics, which includes the measures, security controls, security architecture views, 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. Then finally, we have the interoperability risk assessment. So, we covered all 18 deliverables that map to the 13 sections of EAR 6.0. Anything else we should discuss in terms of this topic here, Trevor? Yeah, I think that covers about everything. The one thing I do want to note is this, these list of deliverables are expected for new submissions or expected for submissions where there's a material cybersecurity 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. Before we wrap up, last minute words of wisdom or final thoughts here. I think start with the deliverables at the end in mind. This is a common situation that comes up not just with cybersecurity but even with general regulatory problems is we go through all these activities, rush in to make a product, are really excited to get it out the door, and then we open up that FDA submission filing and they require 100 deliverables and we didn't even know what you're going to have to prepare and just start getting ready for it. You're going to have to prepare all these deliverables. 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. I agree with that. And we've been talking about the 18 deliverables, but the reality is, from our experience, 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's very hard to do all the odd documentation in an extreme time crunch when you don't have source documents that are needed to create the deliverables to the FDA. And if you ever need 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. Makes it a lot easier for us when we only do one thing, but we do it very well. Yes. 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 a product. It would be very, 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 cybersecurity. Hope to see you next time. Thanks. [music]