Safeguarding stand-alone medical devices while navigating FDA’s evolving security standards

By Normand Martel, MedAcuity

In the highly competitive medical device industry, scientists and engineers are continually pushing boundaries to create innovative medical devices, including stand-alone devices.

The medtech security landscape is rapidly evolving as the FDA introduces changes in regulations that fundamentally redefine the perception and management of security for these devices.

This article aims to demystify the changes to the guidance and security standards. It seeks to empower professionals by providing invaluable insights, enabling you to successfully navigate the complex landscape of regulatory compliance, and fortify security measures when developing stand-alone medical devices.

The premise: Your FDA submission

Let’s say you’re developing a stand-alone medical device (e.g., an aesthetic laser) that is devoid of over-the-air updates or external ports, stores no patient data and authenticates consumables via RfID. Believing in its security due to the absence of a network, you submit a 510(k) package to the FDA, claiming no attack surface or need for a software bill of materials (SBOM) due to no off-the-shelf software.

FDA response

You’re shocked to receive a Refuse to Accept (RTA) letter from the FDA. The FDA contests your assertion in the cybersecurity documentation, challenging the presumption that absence of network connectivity equates to an absence of attack surface. How could the FDA dispute this? Your device, void of any networking, seems impervious to attack. Upon a closer review of the FDA’s correspondence, you uncover their insistence: “We need assurance that risks associated with foreseeable misuse are effectively mitigated.” They call for the development and documentation of a comprehensive threat model that anticipates unintended as well as malicious tampering by employees and clinicians, potentially jeopardizing safety controls within your system. They emphasize the need for a security risk assessment aligned with AAMI TIR57.

FDA-recognized standards and guidelines

The FDA has acknowledged and integrated essential industry standards like AAMI SW96:2023, AAMI TIR57:2016, and AAMI TIR97:2019 into their regulatory framework. These standards encapsulate crucial facets of cybersecurity in medical devices, outlining comprehensive guidelines for risk management across the product life cycle. Furthermore, the FDA released finalized documents, namely the “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” and “Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act.” These documents serve as pivotal guides for manufacturers regarding quality system considerations and submission content, emphasizing cybersecurity aspects in both premarket submissions and the refusal-to-accept policy.

Additionally, legislative initiatives — particularly Section 524B and related acts — mandate stringent requirements for premarket and postmarket security risk management plans and processes. This legislative shift places heightened emphasis on comprehensive risk mitigation strategies throughout a medical device’s life cycle. Additionally, an executive order compels critical infrastructure entities, including medical devices, to publicly disclose a comprehensive SBOM. This order aims to enhance transparency and accountability in ensuring the security of critical infrastructure, compelling manufacturers to disclose software components and dependencies.

FDA Cybersecurity Center of Excellence

The FDA’s establishment of a dedicated cybersecurity center of excellence signifies a committed focus on enhancing cybersecurity measures within medical devices, both stand-alone and connected. This initiative involves assigning cybersecurity reviewers to each submission. These reviewers meticulously assess submissions, scrutinizing adherence to security risk management best practices outlined in recognized standards.

Understanding and meeting FDA expectations

The FDA’s revised guidance emphasizes a comprehensive assessment covering the entire product life cycle  — from procurement and manufacturing to product use and eventual disposal. Notably, the FDA expects manufacturers to anticipate and address foreseeable misuse by both authorized and unauthorized users. The revised threat model necessitates evaluation across all internal assets of value, encompassing internal IO ports, including those in manufacturing and field service access. Additionally, the assessment must address potential risks from the use of off-brand or counterfeit consumables, recognizing the significant implications not only on company revenue but also on patient, operator and bystander safety.

Postmarket obligations and strategies

The FDA’s focus on postmarket surveillance demands a comprehensive strategy. Manufacturers must demonstrate active monitoring for cyber complaints and promptly address new vulnerability disclosures concerning the device’s software. Moreover, manufacturers need to develop a robust plan for timely software updates to mitigate emerging threats and vulnerabilities.

To ensure compliance and fortify the security measures, it’s imperative to conduct a meticulous evaluation of your quality management system (QMS). Develop and implement comprehensive premarket and postmarket security risk management processes, backed by detailed templates, work instructions and protocols.

Securing the development process

Implement a secure software development framework, ensuring adherence to best practices throughout the product development life cycle. Continuously train and update staff, oversee third-party supplier adherence to security requirements, and ensure regular updates of toolchains. Employ static analysis and automated testing throughout the development life cycle, including continuous penetration and fuzz testing of external interfaces to ensure ongoing security robustness.

Code integrity and security risk management

Safeguarding code is critical. Protect code signing keys, use self-signing certificates during development and testing phases, and ensure that the build server exclusively produces and signs release executables. Equally important is integrating mechanisms to promptly revoke compromised certificates/private keys and deploy new ones.

Execute your security risk management standard operating procedures and work instructions meticulously. Furnish objective evidence in your design history file (DHF) to substantiate the execution of procedures. Even for non-networked devices, excessively thin documentation is not acceptable. Every item marked “N/A” should be supported with a reasoned rationale.

Conclusion

While the security risk management artifacts for a stand-alone medical device will be thinner than a networked device, you need to execute your procedures and provide the evidence that leads to a conclusion that you include in your security risk management report.

Normand Martel, a solutions architect with MedAcuity, specializes in systems engineering, cybersecurity, low-power consumption, signal processing, and wireless portable medical devices.

How to submit a contribution to MDO

The opinions expressed in this blog post are the author’s only and do not necessarily reflect those of Medical Design & Outsourcing or its employees.