By Ira Owens, Medcrypt Director of Cybersecurity

In Medcrypt’s Stock Deficiency blog series, learn how receing a deficiency letter affects all roles in your organization from product engineers, to regulatory affairs professionals, to the c-suite. Missed part 1 of the blog? Read it here.

Why do product engineers care about stock deficiencies?

MDMs are tenaciously seeking to build devices that solve real world health problems and ailments. Increasingly, these devices are connected to other devices or to the internet (directly or indirectly). In this climate, R&D staff, software engineers, developers, and managers are not just tasked with creating new and innovative medical devices, but also make sure they meet cybersecurity recommendations and/or requirements. Failure to meet the minimal cybersecurity requirements when submitting to the FDA, often leads to a stock deficiency, or worse, an FDA rejection letter (e.g., Not Substantially Equivalent (NSE) for 510(k), or Not Approvable (NOAP) for PMA). Section 524B of the FD&C Act requires that MDMs establish and maintain a comprehensive cybersecurity risk management program, therefore failure to provide a risk management plan will lead to a deficiency as this information is now mandatory for cyber devices! It is imperative that the software engineering and development staff at MDMs understand the cybersecurity architecture and risk management considerations when building medical devices. These concerns are not just for new devices, but should be considered for legacy devices as well.

What engineers need to do to avoid stock deficiencies:

To ensure FDA submissions are not levied stock deficiencies or worse rejected (device cannot be sold in the United States), engineers need to design medical devices with cybersecurity considerations in mind from the project’s inception. Failure to design a device without cybersecurity considerations could lead to significant schedule and business implications for MDMs. Engineers should be designing devices that meet defined FDA cybersecurity requirements. In addition, engineers shall utilize threat modeling to identify device threats, risks, vulnerabilities, and mitigations in both pre and post market risk assessments.

While assessing the device’s potential risk exposure, there should be significant emphasis placed upon the device’s interoperability considerations as well as third-party software components. Documenting how a device communicates with other devices, systems, and accessories is a critical component to securing the healthcare infrastructure (e.g., network, Electronic Medical Records, medical imaging systems). Commonly used technologies like Bluetooth should be intimately assessed to verify if additional security controls are necessary to ensure the safety and quality of the device is not compromised. Third-party software components shall receive the same (if not more) level of assessment and be captured in a machine readable Software Bill of Materials (SBOM). A comprehensive SBOM provides a mechanism to identify vulnerabilities in software components throughout a device/product’s life cycle (development, design, and after it has been placed in the field/market). A robust SBOM shall include, but is not limited to the following:

• Device Manufacturer Developed Components
• Third-Party Components
• Purchased Licensed Software
• Open-Source Software
• Upstream Software Dependencies (Required/Depended Upon by Proprietary, Purchased/Licensed, and Open-Source Software)

Aside from the interoperability and third-party software component considerations, MDMs and their engineers/developers shall conduct cybersecurity testing of their medical devices. The cybersecurity testing shall test the resilience and exploitability of the cybersecurity controls designed into the device with the findings documented. Things like device authentication, authorization, event detection/logging, and updateability/patchability shall be included in the design of the device. Engineers shall capture these activities and document the following:

• Scope of Testing (including testers)
• Duration of Testing
• Testing Methods
• Test Results, Findings, and Observations

Cybersecurity testing should be conducted along the development lifecycle and can be completed by product security, engineers, dedicated testers, or a third-party. Testing for vulnerabilities at the various development and integration stages enables the assessment and mitigation of risks.

MDMs shall also consider how they plan to monitor, identify, and address vulnerabilities in their devices once they are market-released. This is completed by creating a Cybersecurity Management Plan. These plans shall specifically address intake methods, intake sources (NVD, CISA, software manufacturers, etc.), timeline to develop patches, and communication methods for patches. The Cybersecurity Management Plan should be a prescriptive document that clearly outlines the steps MDMs and their engineers will take to address newly identified vulnerabilites.

Engineers at MDMs have a great deal of responsibility when it comes to designing cyber secure medical devices. The FDA is exercising their new authority and levying cybersecurity related stock deficiencies at an increased rate. In order to prevent device delays or rejections, MDMs should partner with companies like Medcrypt to provide stewardship throughout this process to simplify implementing secure by design practices, plans, and procedures for your software engineer, developer, and R&D teams.

Medcrypt offers reviews of premarket submissions before you submit to FDA through our FDA Audit. If you have already received a deficiency letter, Medcrypt can support you through your deficiency response. We’re happy to be your FDA cybersecurity partner to ensure that your filings are clear and complete.

Interested in learning more about how Medcrypt helps medical device manufacturers meet regulatory requirements? Contact us at info@medcrypt.com and visit us at medcrypt.com to discover our full suite of medical device cybersecurity products and services.

‍