I'm Marianne Kovac-McGee, Executive Editor at Information Security Media Group. Today I'm speaking with Jessica Wilkerson, who is Senior Cyber Policy Advisor and Medical Device Cybersecurity Team Lead within the Food and Drug Administration's Center for Devices and Radiological Health. We're going to be speaking about newly released final guidance from the FDA pertaining to the cybersecurity of premarket medical devices. The release of the new guidance coincides with the FDA's refuse-to-accept policy, which is slated to go into full effect on October 1st.
Under the policy, the FDA can automatically reject premarket medical device submissions that don't include specific cybersecurity details required by the agency as spelled out under a new law that went into effect at the end of last year. The refuse-to-accept policy, which has long been used by the FDA for certain other products, actually has been on the books since March for medical device cybersecurity, but the FDA provided some grace time to give medical device makers an on-ramp to better prepare for what they need to submit to the agency. And the FDA, over the last several months, has been working interactively with medical device manufacturers to help them better understand what's required. Welcome, Jessica.
Thank you. Very happy to be here. The FDA's new premarket guidance finalizes draft guidance that was issued in April 2022. So what's the most significant changes between the draft guidance and the final guidance?
So there are three big buckets. One is an expanded scope to include some of the CBER, Center for Biologics submission types, included some considerations for combination products. And we added elements associated with requirements under those new authorities that you have been mentioning, section 534B of the Food, Drug, and Cosmetic Act related to ensuring cybersecurity of devices. There were also certain structure changes.
We added new subsections in the security risk management section to clarify documentation deliverables. And we also added appendix 4 to further clarify premarket submission documentation recommendations. And lastly, one area that we know is of significant interest, not least of which because we received many comments on the April 2022 draft, is the software bill of materials section. So we added further clarifications into that section, strengthening our pointing to and alignment with the 2021 NTA SBOM framing documents.
And also clarified that supporting materials can be separate from the SBOM. The FDA has been working with medical device makers during the refuse to accept grace period, if you want to call it that. What sorts of issues did the FDA most often find the device makers struggling with when it does come to cybersecurity of their products and the information that they are able to provide to the FDA? Sure, I think one of the big areas is that software bill of materials issue.
And this is not necessarily due to anything specific to the manufacturers or what the agency is asking for, but software bill of materials in many ways is still a maturing and evolving concept. And so we are one of the first federal agencies to be explicitly requiring software bill of materials as part of our regulatory process. And so we are all of us evolving and learning and growing when it comes to how best to approach the software bill of materials, what that then implies and includes related to vulnerability management. If software bill of materials is revealing known vulnerabilities or other issues within a device's software supply chain.
So I think that has been one of the biggest issues that we have been working with manufacturers on throughout this process. So when it comes to the software bill of materials, when you sort of drill down, what sort of difficulties do they have? The manufacturers, is it, you know, getting the information that's needed from, you know, the component makers that they deal with or the software developers that perhaps they're working with, you know, everyone's sort of being transparent enough so that the device maker can be transparent then to the FDA in terms of the information that is contained in the software bill of materials. Yeah, there are several different areas that have been growing opportunities and learning opportunities when it comes to software bill of materials.
One of which is what you were saying related to getting the information from the upstream suppliers. And it may in certain circumstances be less related to a lack of transparency and more that even once you get the information in other areas of cybersecurity and standards, we have standardized ways of presenting information. For example, the common vulnerabilities and exposures program standardized how to label vulnerabilities so that everyone could speak the same language. We don't necessarily have that in terms of some elements of software bill of materials like component naming.
So one manufacturer could say that a company is component is company X, a different manufacturer might capture that information as component X, Inc. And so these differences seem very small, but when you're operating at a very large scale with a number of software components that may come in with the software bill of materials, these kinds of little issues like lack of consistent naming can become bigger issues. The other one that we typically see is going back to that issue around vulnerability management because of course we're not asking for software bill of materials information just to ask for it. We are asking for it so that we can use it.
And we use it by cross-referencing software bill of materials information with other known information, such as known vulnerabilities. And so what it starts to reveal is this question of, well, what vulnerabilities need to be addressed? What vulnerabilities may be addressable later? And how do I prioritize all of these different things?
And then I think the last major one that we see is related to depth or what is typically referred to as hops. How many hops back or up in my supply chain do I have to go in order to have a complete SBOM? So if I'm using component X, but component X itself uses component Y and component Y uses component Z, you know, how many different hop back do I as a medical device manufacturer have to go? And so this is where we point to, for all of these issues, this is where we point to the consensus work that is being done with SIRT and NTA and FZ to help answer some of these questions.
So Jessica, with that said, how should medical device makers use this new final guidance? How might it help them prepare for complying with the FDA's expectations for cybersecurity in their pre-market submissions and the information that, you know, these vendors provide to the FDA? The guidance is incredibly robust. I think a final count, it is 57 total pages, inclusive of all cover pages and all of that.
So there is a significant amount of detail in the guidance. It is broken down into very specific subsections that go into even further detail on things like threat modeling, software bill of materials, labeling, and so on. And so, you know, we say it all the time, but we really cannot stress enough reading the cybersecurity guidance and becoming familiar with what it contains, with the details that it has, is the, is one of the most effective ways that organizations and medical device manufacturers can prepare themselves for a submission. We also say we are a very open team.
And so we frequently work with stakeholders through established FDA processes to answer questions and provide clarifications on the guidances. And so if there are questions on the guidances, you know, we welcome stakeholders coming to us so that we can have those conversations and assist with a successful submission process. When the FDA sort of reviews these submissions for medical device cybersecurity, what are they looking at? Is it more sort of like a checklist or do they kind of drill down and look at the actual information in terms of how robust, for instance, you know, a cybersecurity practice might be, or, you know, if it sees something on a software bill of materials that might be a big red flag.
Oh gosh, this vendor hasn't been supporting this component for years. Why are they including it in a new device? You know, that sort of thing, or what is it that you're going to be looking at? We look at several things in a submission, and I do want to stress that it is not a checklist exercise.
It is very much an in-depth review of the documentation. Because what we're looking for is not a yes, no answer of does this medical device have a certain cybersecurity capability or a certain cybersecurity control? We are looking for, in total, is this medical device resilience to cyber threats? In the language of the statute, does this medical device provide a reasonable assurance that the device and related systems are cybersecurity?
So that's not something that can be done in a checklist fashion. That's something that has to be taken in total from the different characteristics of the device, including things like its threat model, including things like its update capability, its software supply chain, and some of these other things. And the reviewers look at all of this information. They are specially trained to do this kind of review, and they look for, as you said, red flags of things that may suggest that the medical device does not fully provide that reasonable assurance that the device and related systems are cybersecurity, in which case we can work with the manufacturer to address any potential shortcomings.
So the FDA over the last several months has been working sort of interactively with device makers sort of, you know, as an on-ramp to when this refuse to accept grace period, if you want to call it that, what should medical device makers expect, you know, when this policy is officially kicked off here, if they, for instance, if they get a submission rejected, you know, what do they do? Do they get a chance to reapply? How many chances do they get? Does the FDA tell them exactly what it is that they need to do in order to make it a sufficient submission?
You know, what should the medical device makers expect in the process? I think one thing that's very important to understand in the context of the RTA policy as it applies to cybersecurity, the FDA has always had a very collaborative approach with the medical device manufacturer community when it comes to making sure that submissions are attempting to make sure that submissions are successful. So the can do minimum level of the cybersecurity reviews where systems may be especially complex or complicated areas of cybersecurity may arise, they can consult the cybersecurity focal points, these more especially trained focal points, to get assistance with the full review. But all of our reviewers are trained to be able to do this kind of review, and we do have that very robust team across the entirety of the agency.
And in terms of the reviews and, you know, the robustness of the reviews, do any of the products get tested for cybersecurity? Or is it, you know, a matter of sort of drilling down to see if everything sort of makes sense with what the vendor is presenting? FDA does not perform testing of devices. This is not just in cybersecurity, but for device reviews generally.
That is not something that the agency does. Instead, cybersecurity testing is part of the cybersecurity guidance. You can see there's an entire cybersecurity section that we recommend or require depending on what type of device it is and whether it falls into the statutory authority. Cybersecurity testing to be done by the manufacturer.
And then they must present that information to us as part of their submission. So if they get penetration testing performed or static or dynamic code testing is done, that documentation of that test and its results comes in as part of the submission. And then the FDA will review that submission and that testing documentation to make a determination as part of the overall finding of reasonable assurance that the device and related systems are cybersecurity. And the guidance also had noted that the FDA will continue to work collaboratively with vendors that have applications already in the process prior to the publication of the guidance and then also initially after this guidance came out.
How much time does that mean? I know the rule is the policy kicks in on October 1st, but like how much kind of leeway do they have to really expect to have to see sort of this enhanced review and enforcement of the refuse to accept? Absolutely. The key thing to keep in mind when we think about timing of reviews and when some of these more stringent processes may kick in is the FDA's process is targeted at ensuring that patients have the care that they need when they need it.
And in this case, for us, that means that devices are available that have the capabilities and treatment functionality that patients need. And so the reason that I bring this up as we're talking about cybersecurity reviews is part of the work that FDA does and the reason that we're so collaborative is we want to see advanced device capabilities get out into the market that will improve patient quality of life and patient care. And so with the taking into account the RTA policy, the new guidance, the new authorities, our goal hasn't changed, which is that we work with the medical device manufacturing community to be as collaborative as possible to ensure that patients have access to these timely treatments and these greater and more advanced treatments. And so in that sense, we're going to continue to do that.
And we will always continue to do that. It's just going to be a matter of what are the cybersecurity concerns and cyber capabilities that are coming in as part of these submissions and how can we work together with the manufacturing community and other parts of the community like patients, like hospitals, to ensure that the devices have that reasonable assurance that the device and related systems are cybersecurity. What's next for the FDA in its cyber efforts around medical devices? Are there other pieces of guidance you're working on?
Are there policies? What's next? As we say very frequently, cybersecurity is never done. Cybersecurity is not static.
And so there will always be more for us and for the sector to do in raising the bar in medical device cybersecurity. One area of major interest that we remain focused on is the issue of legacy. And so legacy devices are defined internationally as devices that cannot be reasonably protected against current cyber threats. And there are a lot of legacy devices and a lot of legacy technologies out in the healthcare environments that can place patient safety at risk because they really were not designed or built to withstand modern cyber threats.
And so we have worked and continue to work with the community to figure out how do we address that kind of risk. We also are looking at things like vulnerability communications. We know that patients can be very frustrated or frightened about medical device cybersecurity and that it can be very difficult to give patients cybersecurity information in a way that provides them the information they need without alarming them. And so there continues to be significant work on how do we talk about vulnerabilities and how do we talk about medical device cybersecurity in a way that is informative but does not unnecessarily introduce fear into patients and in the environment.
You bring up a very important part of this just going about the patient safety, but we spoke a lot about the medical device makers and what they can expect with this new refuse to accept policy, you know, so on and so forth. Bottom line, what should healthcare delivery organizations that use these devices expect sort of in the near term and the long term when it comes to the enhancement of FDA's authority and its impact? We are extremely excited and really cannot overstate the value that we see in the authorities that we received. We think this is going to represent an incredible strengthening of FDA's ability to enforce medical device cybersecurity.
And we think that that benefit is going to flow to the rest of the sector, to the hospitals, to patients, because we can use this authority and will use this authority to ensure that medical devices do have that reasonable assurance that the device and related systems are cybersecurity, not only at the time that we see the device and that it comes in as part of the submission, but throughout its entire life cycle. The statute requires that devices be updatable and patchable and that the controls associated with these kinds of medical device cybersecurity considerations remain throughout the life cycle. And so we are very excited to be able to take this next step using these new authorities that will allow us to strengthen our review program and very much expect that those benefits will flow to the rest of the sector as well. Well, thank you so much, Jessica.
I've been speaking to Jessica Wilkerson of the FDA. I'm Mary Ann Kolbesak-McGee of Information Security Media Group. Thanks for joining us.