Conduct a medical device security risk assessment

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

If you are a developer or manufacturer who is or will be responsible for a connected medical device, the cybersecurity process is an area where you need to invest effort now.

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

Device Cybersecurity Planning

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

_{Figure 1 – Cybersecurity Steps in Risk Analysis}

In addition to planning for cybersecurity, medical device companies must now implement a chosen framework into their quality system. To make up some compliance ground, some companies make the mistake of approaching compliance by investing in a single-tool software option, but this likely fails to address the true cybersecurity needs in your organization. The overall solution is an application of a secure product development framework that addresses activities and tasks throughout the total product life cycle (TPLC). It is necessary to mobilize resources to develop and update processes and SOPs, but the key to having a robust process is to establish an effective and efficient risk assessment method. The risk assessment method is represented by the security risk assessment in the analysis section of Figure 1.

Focus on assets in the security analysis table

Security risk assessment is used to identify potential security risk controls and identify vulnerabilities. Two tables should be established, a Risk Assessment table which identifies and maintains security risk controls and the Continuing Vulnerabilities table which tracks current vulnerabilities. The two analysis tables can be in separate tabs on a simple spreadsheet because they have filtering and sorting capabilities to enable long-term management of the tables. The contents of the risk assessment table are reflected in Table 1 dealing with security controls.

_{Table 1 – Security Risk Assessment Analysis Table}

The security risk assessment should focus on the assets defined in the security architecture and how threats can exploit vulnerabilities to compromise the assets.

Assets are elements that have value for the user, the patient, the user organization and the company and are relevant for security. Assets can generally include:

• Data processed and stored on the product (e.g. logs, customer or operational data, configuration data)
• Personal data (e.g. protected health information/PHI)
• Credentials (e.g. passwords, credentials, keys)
• Product software/firmware
• Third-party services (e.g. cloud services, open source libraries, APIs).

The analysis should include reasonably practical threats to each asset. The STRIDE model can be applied to identify the potential threat in each line of analysis. The standard STRIDE model and desired security property are provided in Table 2 below.

_{Table 2 – Stride definition}

Identification of vulnerabilities

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

• Identify vulnerabilities in security risk assessment
• cybersecurity penetration analysis and product testing
• thanks to the static analysis of software developed internally with the SAST (Static Application Security Testing) tool
• thanks to dynamic analysis with the DAST (Dynamic Application Security Testing) tool
• review existing catalogs such as the Common Vulnerabilities and Exposures List, National Vulnerabilities Database (NVD), National Health ISAC, and SOUP/COTS Release Notes.
• identified through vulnerability analysis using a Software Composition Analysis (SCA) tool for OTS or open source components.

Assessment of known vulnerabilities is necessary before any product release and maintained until the product is decommissioned. As vulnerabilities are identified and fixed, they can be removed from the current vulnerability scan table. Actions on vulnerabilities are driven by a determination of vulnerability severity and 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), required privileges (PR), user interaction (UI), scope (S) and impact (CIA) measuring confidentiality, integrity and loss of availability.

Determine the impact of threats

In security risk analysis, we know that risk is the combination of severity and likelihood of harm (Risk = P x S). However, for security risk analysis, the FDA recommends considering the exploitability of a potential vulnerability rather than using the probability that an attack will occur successfully. Exploitability should be based on the vulnerability of a system to being compromised. The more effective the security controls, the lower the risk. The assessment of acceptability of threats to assets and vulnerabilities should be driven by a table matrix similar to that in Table 3, based on harm severity and exploitability.

_{Table 3 – Security Exploitability and Severity Decision Table}

Higher risks would require risk controls documented in the Security Risk Assessment Table to reduce their exploitability and overall risk. Risk controls should then determine the design requirements and their effectiveness is then verified during design verification.

Conclusion

The security analysis of risks and vulnerabilities should be kept in two tables because one is necessary to identify and maintain security risks and the other is a rolling list of vulnerabilities that require periodic updates after they are released. These two analysis tables should be updated periodically and the list of current vulnerabilities results in patches and notifications to customers during product maintenance.

Whether your business is just starting out or at a more advanced stage of the cybersecurity maturity spectrum to achieve a robust and effective cybersecurity framework, a focus on the format and analysis of core practices is a priority and will lead to better decisions on tools and improvements in process efficiencies and skills.

Photo: Traitov, Getty Images

Bob Barrett, Vice President of Systems Engineering at Full Spectrum, is an experienced engineering leader and results-oriented team builder. He has technical strengths acquired over more than 30 years of experience in medical device systems engineering, system and software validation, security risk analysis, quality management and project management. Bob spent 15 years in Baxter’s drug delivery division, where he led the systems engineering group. Bob serves as a Player Coach at Full Spectrum, leading the Systems Engineering team, while providing his in-depth knowledge directly to clients. Bob is a firm believer in cadence-based project management techniques. His ability to be hands-on or lead cross-functional teams accelerates clients’ medical development programs from concept to commercialization.

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