1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

How Cyber Security Requirements Can Throw your Medical Device Off Track

How Cyber Security Requirements Can Throw your Medical Device Off Track
Published by Mike Solinap
on December 12, 2018

In our last article we talked about the four steps your organization must go through when designing secure connected medical devices. With the increasing attention paid to product security in this era of connected medical devices, many companies are scrambling to keep up with recommended cyber security requirements. Cyber security is an area in which many R&D or Quality departments might lack expertise, or simply need additional resources. Delay in the 510(k) can potentially cost your organization hundreds of thousands or even millions of dollars, in addition to a delayed time to market.

New FDA guidelines released in October 2018 instituted a tiered approach for connected medical devices. The draft guidance created a two-tiered approach to approvals:

  • Tier 1 devices are connected devices, whether they connect to the Internet, a LAN or just another medical device. These devices are susceptible to cybersecurity issues.
  • Tier 2 devices are not connected devices and thus inherently secure.

The FDA is putting new connected devices under increased scrutiny due to the unique threats presented by cybersecurity breaches. Indeed, one of the most common reasons for delay or rejection is a failure to properly document cybersecurity measures.

What’s more, the FDA is looking to make yet another round of changes in response to growing outcry that the system for approving medical devices is inadequate. In short, the FDA has come under fire for approving new devices whose predicates are decades old, without the necessary cybersecurity features to secure them for the 21st Century. A documentary, The Bleeding Edge, popular on Netflix, has focused public ire on what many consider an outdated approvals process.

Documentation is of paramount importance, especially with regard to new cybersecurity guidelines. These guidelines are frequently evolving. Your organization must continually be abreast of the changing approvals landscape as it relates to cybersecurity — and so must any organization you partner with.

Documentation for cybersecurity must include all expected and relevant testing. “I promise” statements are no longer allowed. Risk management and assessment for cybersecurity threats must be documented throughout the entire process. Your documentation must include not just what the device does in painful detail, but also how you address any and all cybersecurity threats, both proven and anticipated.

If you don’t have information technology expertise within your R&D or Quality teams, this might be the time where you consider partnering with third party organizations. This can mean the difference between your device being approved and languishing in the FDA approvals process for months — robbing you of your competitive edge.

Our next article will be about the new MITRE document and how it applies to your organization.

Next Steps

Latest White Papers

Related Resources

Top 3 Tips To Protect Code For Developers

Top 3 Tips To Protect Code For Developers

When it comes to knowing how to protect code for developers, it’s as valuable as gold in an old safe. The risks are high as attackers becoming wiser, and that precious code is at risk from evolving technology too. That’s why in this article, we’ll share a...

Solving for the “Islands of Jenkins”

Solving for the “Islands of Jenkins”

In October 2022, I wrote a blog post entitled “Scaling Jenkins for the Enterprise”.  Within it, I described the “Islands of Jenkins” problem organizations face. Essentially, this problem stems from companies using an open-source Jenkins installation for each team, but...

Infrastructure as Code with Terraform

Infrastructure as Code with Terraform

Before we begin to talk in detail about this topic, we should clarify some definitions first.  The first term comes from the DevOps movement where IT Operations staff use the concept of revision history/version control by using the concept of infrastructure as code. ...