Conducting a Medical Device Safety Risk Assessment

Conducting a Medical Device Safety Risk Assessment

The FDA released its updated guidance on Cybersecurity in Medical Devices: Content and Quality System Considerations for Premarket Submissions in late June 2025. In this guidance, the FDA emphasizes the expectation that cybersecurity risks and vulnerabilities be addressed in a threat model. Cybersecurity procedures must be implemented to support products from initial design to end of life. Appropriate cybersecurity protections should be addressed in design input during development and not “added on” after development is completed.

If you are a developer or manufacturer who is or will be responsible for a connected medical device, the cybersecurity process is something you should invest efforts in now.

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

Device cybersecurity planning

From a pre-market perspective, the key elements for a safety analysis are:

Figure 1 – Cybersecurity steps in risk analysis

In addition to planning for cybersecurity, medical device companies now need to implement a chosen framework into their quality system. To reach a point of compliance, some companies are making the mistake of addressing compliance by investing in a single-tool software option, but this can likely overlook the true needs of addressing cybersecurity in their organization. The end-to-end solution is an application of a secure product development framework that addressed activities and tasks across the total product life cycle (TPLC). Resources need to be committed to developing and updating processes and SOPs, but the essence of having a solid process is to establish an effective and efficient risk assessment method. The risk assessment method is represented as 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 must be established, a Risk Assessment table that identifies and maintains security risk controls and the ongoing vulnerabilities table that tracks current vulnerabilities. The two analysis tables can be on separate tabs in a simple spreadsheet as they have filtering and sorting capabilities to allow for long-term management of the tables. The content of the Risk Assessment Table is reflected in Table 1 which addresses 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 can exploit vulnerabilities to compromise the assets.

Assets are items that are of value to the user, the patient, the user organization, and the business that are relevant to safety. Assets can generally include:

  • Data handled and stored in the product (e.g. logs, operational or customer data, configuration data)
  • Data of a personal nature (e.g., protected health information/PHI)
  • Credential information (e.g., passwords, credentials, keys)
  • Product software/firmware
  • Third party services (e.g. cloud services, open source libraries, APIs).

The analysis must 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 standard STRIDE model and desired safety property are provided in Table 2 below.

Table 2 – Stride definitions

Vulnerability identification

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

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

Assessment of known vulnerabilities is required before the release of any product and continues until the product is retired. As vulnerabilities are identified and addressed, they may be removed from the ongoing vulnerability scan table. Actions on vulnerabilities are driven by a determination of the severity of the vulnerability and the cvss score. The CVSS scoring model identifies six basic elements 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), which measure the loss of confidentiality, integrity and availability.

Determine the impact of threats.

In security 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 using the probability of an attack successfully occurring. Exploitability should be based on how vulnerable a system is to being compromised. The better the security controls, the lower the risk. Assessment of the acceptability of threats to assets and vulnerabilities should be based on a matrix of tables such as the one in Table 3, based on damage severity and exploitability.

Table 3 – Security Severity and Exploitability Decision Table

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

Conclusion

Security analysis of risks and vulnerabilities should be maintained in two tables, as one is necessary to identify and maintain security risks and the other is an ongoing list of vulnerabilities that require regular updates after release. These two scan tables must be updated periodically and the list of ongoing vulnerabilities drives patching and customer notification during product maintenance.

Whether your company is just starting out or higher on the cybersecurity maturity spectrum to achieve a robust and efficient cybersecurity framework, focusing on the format and analysis of core practices as a priority will lead to better tooling decisions and improvements in process efficiency and proficiency.

Photo: Traitov, Getty Images


Bob Barrettvice president of systems engineering at Full spectrumis an experienced engineering leader and team builder with a focus on results. He has technical strengths gained over 30+ years in medical device systems engineering, systems and software validation, security risk analysis, quality management and project management. Bob spent 15 years in Baxter’s Medication Management division, where he led the systems engineering group. Bob has the role of player coach at Full Spectrum, leading the systems engineering team and bringing his deep knowledge directly to clients. Bob is a big believer in cadence-driven project management techniques. Your ability to be hands-on or lead cross-functional teams accelerates clients’ medical development programs from concept to market launch.

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

Leave a Reply

Your email address will not be published. Required fields are marked *