A Closer Look at FDA's Premarket Cybersecurity Guidance for 2023

In the ever-evolving landscape of medical device cybersecurity, one document that stands above the rest is the newly released FDA’s Premarket Cybersecurity Guidance for 2023.

Pivoting away from the status quo, this guidance falls in line with other federal agencies that demand more responsibility be put on medical device manufacturers and suppliers to keep their devices secure and patients informed. It also further entangles quality and security, preferring to eliminate vulnerabilities over mitigating them, ensure interoperability, and strongly suggests that resources provided by other agencies, such as CISAs known vulnerability database, be utilized.

Up until now, the FDA’s April 2022 PMA Guidelines were the go-to source of truth for preparing a device for market approval to the agency. As of September 2023, that document has changed. 

While much remains the same since the April 2022 draft, we’ve outlined 5 changes that product security teams need to be aware of.

The Key Differences in FDA’S Cybersecurity Guidance For 2023

The guidance now emphasizes that medical device manufacturers should design their products to “eliminate or mitigate known vulnerabilities.” We believe that this subtle but significant change in wording means that companies must consider which components will be used and weigh the benefits vs. the vulnerability it brings. This shift from simply mitigating vulnerabilities is in line with CISA’s approach to compiling a Type 1, or ‘Design’ Software Bill of Materials (SBOM). The goal is to identify and eradicate vulnerabilities at the source, reducing the risk posed by poorly secured components.

Why this matters

• This new emphasis on elimination promotes a proactive approach to cybersecurity.
• It underscores the importance of assessing vulnerabilities at the component level from the earliest stages of development.

Interoperability is a completely new section that requires companies to look at periphery cybersecurity challenges that may arise in the field– one of them the basic methods of communication between new devices and those already in the field.

The guidance recognizes the growing importance of interoperability in medical devices, highlighting potential cybersecurity considerations when devices interact with other medical devices, healthcare infrastructure, or general-purpose computing platforms. It highlights the need to assess security controls for common technology and communication protocols, ensuring the safety and effectiveness of the device.

“As part of a medical device system, a device may have cybersecurity considerations from

interoperable functionality, including but not limited to interfaces with:

• Other medical devices and accessories;
• ‘Other functions’ as identified in the FDA’s premarket cybersecurity guidance “Multiple Function Device Products: Policy and Considerations;”
• Interoperability with healthcare infrastructure (e.g., network, Electronic Medical Records, medical imaging systems); and
• General purpose computing platforms.”

It also adds,  “When common technology and communication protocols are used to enable interoperability (e.g., Bluetooth, Bluetooth Low Energy, network protocols), device manufacturers should assess whether added security controls beneath such communication are needed to ensure the safety and effectiveness of the device (e.g., added security controls beneath Bluetooth Low Energy to protect against risks if vulnerabilities in the Bluetooth Low Energy protocol or supporting technology are discovered).”

Why this matters

• It acknowledges the potential introduction of new attack surfaces due to interoperability configurations between older and newer devices.
• Calls for testing components for interoperability and adding security layers when necessary.

The 2023 guidance allows device manufacturers more flexibility regarding source code access. While the previous version advocated custodial control of source code, the new guidance recognizes that manufacturers may face challenges related to licensing restrictions or supplier agreements. In addition, manufacturers are now encouraged to include plans for updating or replacing third-party software components.

“Manufacturers may not have control of source code due to licensing restrictions, terms of supplier agreements, or other challenges. While source code is not required to be provided in premarket submissions, manufacturers should include plans for how third-party software components could be updated or replaced if support ends or other software issues arise in premarket submissions.”

Why this matters

• Reflects the FDA’s commitment to holding vendors accountable, in line with the White House Cybersecurity Strategy.
• Adapts to real-world challenges faced by manufacturers in managing source code.

Manufacturers are now requested to identify all known vulnerabilities associated with their devices, including those listed in CISA’s Known Exploited Vulnerabilities Catalog. This shows greater communication between federal agencies who are working towards a common goal of better securing America’s infrastructure.

“As part of the premarket submission, manufacturers should also identify all known vulnerabilities associated with the device and the software components, including those identified in CISA’s Known Exploited Vulnerabilities Catalog.”

Why it matters

• Provides a specific catalog for comparison.
• Vulnerability assessment to include all known vulnerabilities.
• Highlights the importance of referencing the CISA catalog as a baseline.

The guidance emphasizes the connection between security and quality by stating that cybersecurity management plans can support security risk management processes described in the Quality System (QS) regulation. It even suggests the use of a Secure Product Development Framework (SPDF) to satisfy QS regulation with regards to cybersecurity then goes on to break down what it wants to see in terms of threat modeling and resiliency– all as a part of greater quality.

The document states “A Secure Product Development Framework (SPDF) may be one way to satisfy the QS regulation”

Why it matters

• Aligns product security with product quality.
• Reflects a growing trend in various industries to connect safety and security considerations.
• Addresses industry concerns about regulations being perceived as burdensome.

For many product security professionals, these changes don’t set off alarm bells– and for many, they bring a feeling of relief.

While there is work to be done, these guidelines give clearer guidance on what is the baseline. For companies who are already managing SBOMs and automating their vulnerability detection and prioritization activities from a single centralized location, this allows them to pin what they’ve implemented against a benchmark. 

For those who are still on their journey towards a more mature product security operations this benchmark presents an opportunity. It allows for operations to be realigned in one location instead of a patchwork of tools so the full product security journey can be conducted harmoniously and automatically. This allows for teams to sharpen communication with end users, boost product security, ensure quality, check interoperability capabilities, and manage a device’s full lifecycle.