Conducting a Medical Device Security Risk Assessment

The FDA released their updated guidance on Cybersecurity in medical devices: Quality System Considerations and content for Premarket submissions at the end of June in 2025. In this guidance the FDA emphasizes the expectation that cybersecurity risks and vulnerabilities be addressed in a threat model. Cybersecurity procedures to support products from initial design to end of life must be implemented. Adequate cybersecurity protections must be addressed in the design inputs during development and not “bolted on” after development is completed.

If you are a developer or manufacturer that is or will be responsible for a connected medical device, the cybersecurity process is something you need to invest effort in now. 

There are multiple standards such as ANSI/AAMI SW96:2023 and IEC 81001-5-1: 2021 that are widely recognized in the US and in the EU that detail what activities and deliverables should be addressed relative to cybersecurity risk assessment for medical device software. This short article is focused on how to perform the analysis which is the core part of the cybersecurity threat model. The objective for this article is to provide insight on conducting security risk analysis that is impactful for the whole life of a medical device or medical device software.

Device cybersecurity planning

From a pre-market perspective, the key elements to a security analysis are as follows:

_{Figure 1 – Cybersecurity steps in risk analysis}

In addition to planning for cybersecurity medical device companies now need to implement a chosen framework in their quality system. To catch up to a point of compliance some companies are making the mistake of addressing compliance by investing in a one-tool-does-all software option, but this may likely miss the true needs to address cybersecurity in your organization. The wholistic solution is an application of a Secure Product Development Framework that addressed the activities and tasks throughout the total product lifecycle (TPLC). Commissioning resources to develop and update processes and SOP’s is needed but the core of having a solid process is to establish an effective and efficient risk assessment method. The risk assessment method is represented as the Security Risk Assessment in the analysis section of figure 1. 

Focus on Assets in Security Analysis Table

The Security Risk Assessment is used to identify potential security risk controls and identify vulnerabilities. Two tables should be established, a Risk Assessment table that identifies and maintains the security risk controls and the ongoing vulnerabilities table tracking the current vulnerabilities. The two analysis tables can be in separate tabs on a simple spreadsheet as they have filtering and sorting capabilities to allow for long term management of the tables. The content for the Risk Assessment Table is reflected in Table 1 addressing the Security Controls.

_{Table 1 – Security Risk Assessment analysis table}

The focus of the Security Risk Assessment should be the assets defined in the security architecture and how threats may exploit vulnerabilities to compromise the assets.

The assets are elements that are of value to the user, patient, user organization and business that are relevant to security. Assets might generally include:

• Data handled and stored on the product (e.g., Logs, customer or operational data, configuration data)
• Data of personal nature (e.g., Protected Health Information/PHI)
• Credential information (e.g., passwords, credentials, keys)
• Software/firmware of the product
• Third party services (e.g., cloud services, open source libraries, API’s).

The analysis should include reasonably practical threats to each of the assets. The STRIDE model can be applied to identify the potential threat in each analysis row. The standards STRIDE model, and the desired security property is provided in Table 2 below.

_{Table 2 – Stride definitions}

Vulnerability identification

In addition to the Security Risk Assessment the separate ongoing vulnerabilities table should be maintained, as mentioned previously.  This table contains the known vulnerabilities that have been identified in the device. Vulnerabilities are flaws or weaknesses that could be exploited by the potential threat-sources. Vulnerabilities can be identified through:

• Identifying vulnerabilities in the Security Risk Assessment
• cybersecurity penetration analysis and testing of the product
• through static analysis scanning of internally developed software with SAST (Static Application Security Testing) tool
• through a dynamic analysis scanning with DAST (Dynamic Application Security Testing) tool
• reviewing existing catalogs like the Common Vulnerabilities and Exposure List, the National Vulnerability Database (NVD), the National Health ISAC, and release notes of SOUP/COTS.
• identified through vulnerability scanning using a SCA (Software Composition Analysis) tool for OTS or open-source components.

The evaluation of known vulnerabilities is necessary prior to any product release and maintained until the product is retired. As vulnerabilities are identified and addressed, they may be removed from the ongoing vulnerabilities analysis table. Actions on the vulnerabilities are driven by a severity determination of the vulnerability and the CVSS score. The CVSS scoring model identifies six base items in its matrix for each of the identified vulnerabilities: Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S) and Impact (CIA) measuring confidentiality, integrity and availability loss.

Determine impact of threats

In safety risk analysis we know that risk is the combination of severity and probability of harm (Risk = P x S).  However, for security risk analysis the FDA recommends considering the exploitability of a potential vulnerability versus the use of probability of an attack occurring with success. Exploitability should be based on how vulnerable a system is to being compromised. The better the security controls the lower the risk. The acceptability evaluation of threats to assets and vulnerabilities should be driven by a table matrix like to one in Table 3, driven by severity of harm and exploitability. 

_{Table 3 – Security exploitability and severity decision table}

Higher risks would require documented risk controls in the Security Risk Assessment table to reduce their exploitability and overall risk. Risk controls should then drive requirements in the design and are subsequently verified as effective during design verification.

Conclusion

The security analysis of risks and vulnerabilities should be maintained in two tables, as one is needed to identify and maintain the security risks and the other is an ongoing list of vulnerabilities that require periodic updates after release. These two analysis tables are to be updated periodically and the ongoing vulnerability list drive patch and customer notification during product maintenance. 

Whether your company may be just starting out or at a higher point in the cybersecurity maturity spectrum of achieving a robust and efficient cybersecurity framework, a focus on the format and analysis core practices as a priority and will lead to better decisions on tools and improvements in the process efficiency and competency. 

Photo: Traitov, Getty Images

This post appears through the MedCity Influencers program. Anyone can publish their perspective on business and innovation in healthcare on MedCity News through MedCity Influencers. Click here to find out how.