Cyber-Safety: Practical Strategies for 524B Compliance

As part of our webinar series “Cyber-Safety: Practical Strategies for 524B Compliance,” I presented on the topic of “Navigating Section 524B: What You Need to Know About Ensuring Cybersecurity in Medical Devices.” During that engaging session, we ran out of time to field all questions, so this post covers the responses to those questions, and reiterates some of the content and questions we covered in the live webinar.

If you missed the live webinar, the session was recorded and you can catch it here.

In the second part of our series, my colleague Robert Krantz will discuss “Open-Source Strategies for 524B Cyber-Success” on September 21. You can register for that webinar here.

Here are highlights from our earlier session Q&A:

Now that the US Food and Drug Administration has passed the Food, Drug, and Cosmetic (FD&C) Act that includes Section 524B, how does this updated impact me? Our device does not directly connect to the Internet but has a USB port used to transfer data/files from the internet to the device. Should we anticipate that the FDA would consider this a cyber device?

Devices that do not directly connect to the internet may still contain vulnerabilities. There can be chain-connectivity among the devices. The device of interest may not directly connect to the internet, but it may connect to another device that connects to the internet, and you have a spectrum of cyber security risk exposure of these devices.

We look forward to the final version of the guidance to provide better clarity whether such a case fits the cyber device definition. Our best recommendation is to seek advice from the FDA if you are unsure, and address cybersecurity questions comprehensively in your pre-market application regardless of whether your device is going to be a cyber device or not.
 

Does this update apply to existing products in the market?

Section 524B puts requirements on the premarket application. Products already in the market are not affected in general.

However, a product already in the market may need to resubmit the pre-market notification or approval when significant changes or modification in design are made to the existing product.
FDA has two pieces of guidance to help determine when modifications require a new 510(k):
Deciding When to Submit a 510(k) for a Change to an Existing Device (General Modifications guidance), and Deciding When to Submit a 510(k) for a Software Change to an Existing Device (Software Modifications guidance).

What is an RTA letter? Will I receive an RTA letter if the new requirements are not met?

RTA stands for “Refuse to Accept.” For premarket submissions submitted for cyber devices before October 1, 2023, FDA generally intends not to issue “refuse to accept” (RTA) decisions based solely on information required by section 524B of the FD&C Act. Instead, FDA intends to work collaboratively with sponsors of such premarket submissions as part of the interactive and/or deficiency review process.

Beginning October 1, 2023, FDA expects that sponsors of cyber devices will have had sufficient time to prepare premarket submissions that contain information required by section 524B of the FD&C Act, and FDA may RTA premarket submissions that do not.

Please refer to this document “Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act” for details. It is available on the FDA website for download. 

You talked about the Vendor Qualification Summary (VQS). What is it and how can it help?

The VQS are documentation packages that help manufacturers address the key questions in their FDA applications. There are exact answers to questions related to Wind River products that you can use in your documentation. There are suggestions on how to answer questions from the manufacturers’ perspective if Wind River is not in a position to answer those questions. There are also training and support materials.

Wind River products are a subset of all software used in a medical device. The VQS won’t be able to substitute for all the documentation the manufacturers need to submit to FDA, but it does save some preparation time for you.

My device is not a high-risk product, and it was not asked to provide a SBOM (software bill of materials) in the past. Do I now need to provide a SBOM?

The practices changed a bit here. In the past, only the devices under certain conditions were required to submit a SBOM, for example, if the SBOM will be provided as labeling to customers. 

Moving forward, all devices qualified as cyber devices need to submit a SBOM. By its definition provided by “Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act, a “cyber device” means a device that—

(1) includes software validated, installed, or authorized by the sponsor as a device or in a device;

(2) has the ability to connect to the internet; and

(3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

What is included in a SBOM?  Does the SBOM have to show only the open-source software, or does it have to include everything? 

The SBOM is a standardized listing of all software components included in a medical device, and it can be a powerful way to mitigate the damage caused by cybersecurity intrusions. The SBOM – also referred to as a cybersecurity bill of materials (CBOM) – is much more than a paper record of components. It can be used in concert with a software analysis tool to automatically scan for open-source software vulnerabilities and versions.
 

A complete SBOM for each component should include:

• Component name
• Version
• Software manufacturer
• Level of support provided by software manufacturer
• End-of-support date
• Any known vulnerabilities

Examples of information that should be included in a SBOM can be found in Appendix G (page 44) of the Medical Device and Health IT Joint Security Plan.

And yes, it is going to be the entire software stack that needs the SBOM. It includes both open-source software and proprietary software, and it includes the software developed by the manufacturers and the third-party software developed by the software vendors.

How do you envision the impact of generative AI on software development in relation to upholding a robust security posture, in the context of healthcare cybersecurity?

Generative AI is artificial intelligence capable of creating content such as images, music, text, and videos. More than just a chatbot, generative AI can be used in drug discovery, disease diagnosis, personalized patient treatment plans, and medical research.

Generative AI, while holding great promise, also faces several challenges that must be addressed to enable its responsible and ethical use. For example,

• Data privacy: Generative AI models require large amounts of data for training. Handling sensitive and private data raises data privacy concerns.
• Ethical concerns: Generative AI has the potential to create highly realistic fake content, such as deeply fake videos and images, that can be exploited to spread misinformation, fraud, or malicious intent.
• Bias and fairness: Generative AI models can inherit biases in the training data, leading to biased outputs.
• Model robustness: Generative AI models can be vulnerable to adversarial attacks, where slight perturbations in the input data lead to erroneous outputs.

In the context of cybersecurity, generative AI can be a security concern when it is used by hackers to write AI-powered personalized phishing emails, innovate password guessing, or generate deep fake data for identity theft and financial fraud.

In many cases, a large language model (LLM) behind the generative AI has to be deployed on the cloud due to the high computer and memory requirements. Medical devices need Internet connection to reach the LLM and request responses. Such connectivity qualifies the medical devices as cyber devices which we discussed extensively in the webinar.

About the author

Ryan Zheng is an Industry Solutions Leader for Industrial Marketing at Wind River.