How Can Medtechs Prepare for the FDA’s Shift Left Strategy on Cybersecurity

How Can Medtechs Prepare for the FDA’s Shift Left Strategy on Cybersecurity Erez Kaminski

The recent FDA guidance on security marks good and bad news for the industry. In short, the FDA can now refuse submissions from medical device manufacturers if they can’t demonstrate that they have comprehensive cybersecurity processes and detailed information on the composition of their software in place. This is good news for the public and healthcare industry in general.

While the FDA has published a number of plans to address medical device problems post-market, its plans and processes for addressing cybersecurity issues have been woefully inadequate. Regulators have become increasingly concerned about the potential for medical devices to become a vector for spreading malware attacks across hospital networks, resulting in untold patient harm and billions of dollars globally.

As far back as 2012, in the popular drama “Homeland,” the main character helps hack the Vice President’s pacemaker, causing the Vice President to have a heart attack and die. This episode illustrates the potential real-life weaknesses in medical implant surgery. A 2018 report from the US Department of Health and Human Services’ Office of the Inspector General said the FDA was not adequately protecting devices from getting hacked. Indeed, as AI and the Internet of Things have revolutionized healthcare by making it more accessible and delivering better outcomes to patients, it’s provided more devices and ways from which a hacker can launch an attack. Everything from mobile apps to insulin pumps to remote patient monitoring, while lifesaving, can also be vulnerable to compromise.

So, what’s the good news in all this?  Again, the FDA is taking these threats very seriously by requiring manufacturers to specifically:

• Demonstrate they have a cybersecurity plan
• Execute vulnerability scanning on a regular basis
• Submit a Software Bill of Materials (SBOM) accounting for SOUP (Software of Unknown Provenance) and other third-party software

The bad news for Medtechs is that the FDA is “shifting left” to placing the burden squarely on the manufacturers to document this critical information. Not all companies will be ready to comply with this “shift left” strategy and will either delay submissions or could go out of business entirely. Here’s why:

• As most medical device manufacturers may know, SOUP, or Software of Unknown Provenance, is not a warm bowl of chicken goodness.
• Rather, SOUP refers to the off-the-shelf software items that are already developed and generally available, although not developed for the purpose of being incorporated into a medical device.
• The advantage to SOUP is it can accelerate development times. There is no reason to reinvent the wheel when using complex software components that take time and effort that may not be available on the medical development team.
• Because SOUP can impact the performance of medical device software without direct control from a developer, Medtechs have always had to provide a risk analysis of SOUP and justification for its use.
• With this latest guidance, the FDA is acknowledging the possibility that without understanding what is in the device’s SOUP components, a medical device could be vulnerable to compromise.
• Thus, while the FDA has required function/performance requirements for every SOUP, the threat of denying any submission that doesn’t have a detailed SBOM, including SOUP, puts some teeth in the process.

Again, the bad news is that manufacturers have struggled with FDA compliance regulations for years with the result that they’re not able to bring new innovations to market in a safety-critical environment. And with physician shortages and higher life expectancies it’s even more important to make good quality healthcare available to remote and aging populations. This latest guidance, while making devices safer, could also radically slow the pace of much-needed innovation and deter new software companies from entering the market.

What to do?  New software approaches make it easier to assemble and document SOUP and other software dependencies while identifying potential risks and vulnerabilities from the beginning of the development process. Best-in-class tools will also alert on new software supply chain risk through connected systems, such as email, Teams/Slack, and project management tools like Jira. Consolidating this information into a single dashboard makes it easier to identify risks while continuously monitoring them from a Quality standpoint and ultimately preparing FDA-ready documentation. Post-market these documents and dashboards will make it easier to isolate any issues as well as maintain an effective change management process.

Photo: Traitov, Getty Images