Compliance only works if your enemy is the compliance auditor. Compliance has proven time and time again to be an ineffective approach to security. Consider an analogy from elsewhere in the healthcare industry: HIPAA has become the de facto security standard in the industry, yet it misses the mark, focusing only on patient privacy and not adequately considering patient health. Yet, because healthcare organizations must comply, they allocate most or all of their security resources to ensuring they are not in violation of HIPAA, and can’t or won’t allocate additional resources to focus on the much more important mission: protecting patient health.

Given all of that, guidance documents could still be simply ignored. However, even if some organizations ignore it, such guidance nevertheless continues to be useful for the industry overall, in that it helps align the various stakeholders — including device manufacturers, hospitals, patients, and the government — as to what is important. It provides a common language around which the discussion of security can be centered. This fosters productive dialogue that empowers the purchasers of medical devices to ask the right questions and make well-informed purchasing decisions accordingly.

However, this only works if the guidance itself is useful, practical, and valid. The importance of this condition cannot be overstated, and warrants a follow-up analysis of the effectiveness of the guidance itself. Although that analysis is beyond the scope of this article, a crucial takeaway is that the FDA post-market guidance is not inherently revolutionary; much of it focuses on already well-established security paradigms, now framed in a medical device context. It is from this perspective that it is critical to note that in many cases, the security challenges inherent with connected medical devices do not pertain to a new defense paradigm, but rather to the (in)effective implementation of an existing, well-documented, well-understood paradigm. Better adherence to secure design principles — the collection of well-established, universally accepted truths about how to build systems resilient against attack — would be very effective in reducing risk associated with connected medical devices. The primary challenge in the status quo is in fact attributable to the success or failure of adherence to those principles, and not to the lack of existence of an effective paradigm.

There is a common misperception in healthcare overall and in the medical device community in particular that the software elements of a medical device cannot be modified without going through a new lengthy and expensive FDA approval process, often slated at over 7–10 years. That is not true. FDA allows for updates to the software elements for the very use case of patching for security updates. This empowers medical device manufacturers and the healthcare systems who deploy them to adapt over time as adversary techniques evolve, new attack techniques are invented, and previously unknown flaws with operating systems are discovered.

Overall, the publication of the FDA’s guidance is a good thing. It is getting the industry talking about a very real problem that is going to require a substantial amount of effort and time to address. However, the industry is very far away from a point where end users can be fully relaxed and confident in the security posture of medical devices.

I am optimistic that this will improve over time, but only with the continual commitment to pursuing this mission by all stakeholders across the industry. Device makers should build security into their own devices, perform regular security assessment, and should ensure they are utilizing a sufficiently rigorous methodology in the pursuit of those assessments. Device makers must consider their devices with the same mindset as malicious adversaries do. Hospitals also have a role in this, as medical device security is a shared problem. Hospitals need to invest resources, understand their own threat model, properly segment networks, have a firm inventory of devices they manage, and must be vigilant in managing user provisioning while also implementing least privilege. The FDA’s role should be to require device manufacturers to build security into the solution and ensure that they can articulate how they’ve done so and that it is sufficiently adequate; but the FDA’s role should not to prescribe the specific controls manufacturers should deploy nor develop regulation that manufacturers must comply with.

If medical device manufacturers and healthcare systems can together tackle this shared security challenge, they will be well on the way to creating a safer environment for patients, with or without guidance from the FDA. Which is to say, whether or not FDA guidelines are enforceable should be immaterial; if the root problem is proactively addressed in the design, implementation, and ongoing maintenance phases of medical device roll out, patients will be well safeguarded, and both medical device manufacturers and hospitals will be well positioned to pursue their respective security missions.

PS — For further reading, CSO Magazine recently wrote a compelling analysis on this topic, for which I provided one of the expert opinions. Read the article here.