Compliance & Regulation

5 Updates Pending to the FDA’s Cybersecurity for Premarket Submissions

By |

This is a guest post from Velentium, which provides assistance throughout all stages of medical device development. Velentium is a partner of Jama Software, and this post originally appeared on the company’s blog. 

On October 18th, 2018, the FDA released a draft guidance named “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.” Even though most of the activities and deliverables in the 2018 guidance had been the FDA’s expectations for the previous 12 to 18 months, they were not publicly documented and available to the industry until that time.

(For a complete breakdown of the 2018 Guidance, download our white paper).

The FDA has been working steadily to update the 2018 guidance, taking into account industry feedback as well as input from subject matter experts in medical device cybersecurity, including Velentium’s own Christopher Gates. The estimated final release date for these updates is the end of 2019 but bear in mind, the published draft does reflect the FDA’s current expectations for submissions!

In this post, we offer insight into anticipated changes coming in the official update. Chris’ vantage point within the industry, involvement with special interest groups, and regular contact with regulatory bodies provide us a high degree of confidence about these changes. Even so, they should not be taken as “gospel truth” until we have official FDA confirmation in the form of a published revision to the guidance.

That said, here are five (5) changes we look forward to seeing in the official update.

1. Removed: References to “Likelihood”

We view this as an extremely positive change because, as we’ve written before, “Likelihood” really has no bearing in cybersecurity. This is one place where cybersecurity management diverges sharply from quality management: when you’re mitigating patient risk due to failures, there is no malicious intent at work trying to cause any particular subsystem to fail; therefore, the likelihood that it might fail is useful to know. But as soon as malicious intent enters the picture, likelihood ceases to be relevant because there’s no way to predict whether a given vulnerability will be discovered and attacked by a malicious actor.

Even if it were possible to estimate the probability that a given attack vector will be utilized or a given system vulnerability discovered and exploited, it wouldn’t be practical information to have. Demonstrating device security to regulators is about mitigating vulnerabilities, period. It is not about arguing, based on some trumped-up metric of “likelihood,” that you don’t need to mitigate certain vulnerabilities because no-one will ever find them.

(Note that “Likelihood” of attack is not the same thing as “Difficulty” of attack, which is useful to know and part of all industry-accepted vulnerability scoring systems).

2. Replaced: the CBOM Requirement is Now an SBOM Requirement

In other words, the hardware element of the Component Bill of Materials (CBOM) will not be required, but the software element still will be. As a quick refresher, this means:

“A list of commercial, open-source, and off-the-shelf software components to enable device users (including patients, providers, and healthcare delivery organizations (HDOs)) to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the device (and the connected system), and to deploy countermeasures to maintain the device’s essential performance.”

(Source: FDA 2018 Cybersecurity Guidance)

Depending on the system, the SBOM will include all third-party software components (libraries, operating systems), and will also need to be machine-readable. Finally, the SBOM needs to be cross-referenced to a vulnerability database, such as the NVD, as a manufacturer will want to show that currently there are no known vulnerabilities. Failing to include this will almost certainly result in a pre-market submission rejection.

3. Replaced: 2018’s 1-2 Tier Structure

Not much is known yet about the pending overhaul of 2018’s security risk rating system for scaling and assigning a metric to a device, but we do know that it will not be tied to Device Risk Rating (I/II/III), or to Software Classification (A/B/C), which are based on user risk. Rather, it will be based on something else, still to-be-announced. Keep an eye on our blog — we’ll post more when we know more!

4. Revised: Guidance on Investigational Device Exemption Submissions

In the 2018 draft, a footnote on page 5 indicated that manufacturers “may… consider” applying the principles described in the Cybersecurity Guidance to Investigational Device Exemption submissions. This language will be clarified to reflect that the FDA does not consider good cybersecurity development practice “optional,” either for Investigational Device Exemption submissions or Institutional Review Board submissions.

The takeaway here is straightforward: if you plan to deploy or utilize your device at any stage of development in any way that requires first securing approval, you must demonstrate that you have taken all appropriate measures to secure your device.

At Velentium, we practice and highly recommend the secure development lifecycle. Our approach, in which security is fully integrated into the project lifecycle from Phase 0, not only ensures that your device will be compliant and that you will have generated all the artifacts needed for submission well in advance, but also that you will have identified and mitigated any threats to your business model that could stem from the project. Contact us to learn more.

5. Reformatted: the Entire Guidance.

Finally, expect a format overhaul of the PDF itself. The 2018 draft attempted to follow the layout from FDA’s initial cybersecurity guidance (originally issued in 2014), but this has proved to be a suboptimal way to organize the new content.

If your current project includes documentation that you are tracing to the structure of the guidance, you may want to hit “pause” on populating that trace matrix (unless you expect to submit those documents before the update is published). Other than that, the reformatting should have a minimal impact except to make the guidance content easier to understand.

Latest posts by Velentium (see all)