Navigating FDA Cybersecurity Requirements for Medical Devices – A Case Study

This case study describes the experience of a multinational medical device manufacturer meeting the FDA cybersecurity requirements. The company is operating in the MedTech sector developing a class 2/IIb device consisting of hardware and software.

The company spent about 2 years working on the security risk management of the device. In addition, they also embarked in the journey of being UL 2900 certified, which meant adding new QMS process for cybersecurity. Penetration tests were done regularly after every major development update.

Here's their story of navigating the cybersecurity requirements:

We decided to use a hybrid NIST/OWASP model with 3 parameters:

1. Impact
2. Likelihood of Threat event initiation
3. Likelihood of threat event resulting in adverse impact

With the overall likelihood as a combination of the former two (similar to the classic SxP1xP2 for safety).

Each risk was assessed for potential safety impact; if it had one, a new risk item was entered in the software safety risk analysis, to ensure it was acceptable for both security and safety. Traces between the two were in place.

We had a SBOM (Software Bill of Materials) in place which also included firmware embedded in off-the-shelf components (e.g. smart batteries, wireless modules), although the details of this code were rarely available. We selected critical components (e.g. Operating systems) that were IEC 62304 compliant and had good track records, published bug list and vulnerabilities reported in the NVD. The software team went through the list of vulnerabilities for an initial screening (there were hundreds, all documented), selecting only the ones applicable to our specific version. These were entered in our risk analysis document and assessed accordingly.

All traces were duly documented in a separate, endless excel file.

At 510k submission time, we felt more than ready.

A few months later we were abruptly awaken by the FDA response. We realized that our documentation was created “for filing” rather than “for reviewing”, so the FDA got lost in it and pushed back.

This is a list of the main learnings:

1. CVSS rules. NIST, OWASP and all others are ok, but the FDA forced us to revert to CVSS. This did not make much sense to me initially, especially when dealing with potential vulnerabilities in our own code. Things like temporal scores (back with CVSS 3.1) were not easy to evaluate for our code. It all became clearer when we received the first post-launch notification of a new vulnerability of a component. It came with its own CVSS base score, and all we had to do was to add our assessment for the Environmental score values and that was it, we easily justified the continued use of the software “as is”.
2. Excel is not good. The FDA wants only PDF files in a submission, and Excel exports large tables like a dog. Yes, it’s user friendly and you can copy-and-paste large amount of data, but if a document can’t be reviewed then you have a problem.
3. Traces in Excel are not good. We already knew that traces in Excel had to be done manually and were prone to human error, but the FDA also made us realize that having a nice, tidy (and incredibly long) trace file is impossible to review. A reviewer or auditor wants to have all the information in the same table, from cause to risk to control to verification, end-to-end. They do not want to jump through 3 or 4 different tables.
4. In hindsight, given the size of the project, we should have used a risk management tool from the start. Yes it may have slowed down things initially (see copy-and-paste) but it would have been a lifesaver at later stages and post-launch. The software tools available in the company were either too old or not adequate, the lack of a table view was a dealbreaker for the day-to-day activities. To help with the support of the software we ended up uploading traces in a database and re-exporting them for the DHF, basically duplicating the work.

With the SoftComply Risk Manager Plus app on Jira Cloud we can track the risks in a familiar table format, link applicable data to build traceability, and keep central list of software components in one place. It is easy to assess new vulnerabilities and apply the CVSS score for each of them and handle them based on the criticality.

???Try out the Risk Manager Plus for free for 30 days?–?https://marketplace.atlassian.com/apps/1219692/softcomply-risk-manager-plus-top-risk-management-in-jira?hosting=cloud&tab=overview

???Schedule a product demo?to learn more about managing information security risks in Jira –?https://calendly.com/softcomply/softcomply-risk-manager-demo