Cybersecurity Risk Management In Medical Devices: Practical Implementation Of FDA's 2025 Final Guidance

By Jayet Moon

The U.S. Food and Drug Administration (FDA) has issued its much-anticipated final guidance on cybersecurity risk management in medical devices, effective June 2025. This document, titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," marks a major milestone in aligning medical device cybersecurity with regulatory expectations, emphasizing safety, effectiveness, and life cycle security.

Defining A "Cyber Device"

Everything in this guidance applies to “cyber devices.” There is some confusion on what exactly this means. Let’s clarify that in FDA’s own words:

FD&C Act defines a “cyber device” as a device that:

1. includes software validated, installed, or authorized by the sponsor as a device or in a device;
2. has the ability to connect to the internet; and
3. contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats

Informed in part by the definitions recognized by NIST for the term “software,” the FDA considers a “cyber device” to include devices that are or contain software, including software that is firmware or programmable logic.

FDA also considers the “ability to connect to the internet” to include devices that are able to connect to the internet, whether intentionally or unintentionally, through any means (including at any point identified in the evaluation of the threat surface of the device and the environment of use). This means that even if a device was not intended by the manufacturer to be connected to the internet, but it potentially can be, by virtue of its hardware or software via unintended use or misuse — the device can be a “cyber device” subject to cybersecurity requirements.

FDA considers devices that include any of the following features to have the ability to connect to the internet:

• Network, server, or cloud service provider connections;
• Radio-frequency communications (e.g., Wi-Fi, cellular, Bluetooth, Bluetooth Low Energy);
• Magnetic inductive communications; and
• Hardware connectors capable of connecting to the internet (e.g., USB, ethernet, serial port).

Secure Product Development Framework

One of the cornerstone concepts in the 2025 guidance is the Secure Product Development Framework (SPDF). This structured process aims to reduce both the number and severity of cybersecurity vulnerabilities throughout the product life cycle. In short, it’s a product development framework that focusses on ensuring ‘security by design’. SPDF is not a standalone initiative but should integrate into a manufacturer’s existing processes, including quality systems, risk management, and software development life cycles.

This corresponds to Secure Software Product Development Lifecycle (SSDLC) which, instead of focusing on traditional waterfall product development process, stresses “Security by Design” that is accomplished by starting with security requirements, risk assessments and threat modelling to inform secure design inputs, then as development progresses focuses on security testing and code review to deliver a secure configuration that is routinely scanned for vulnerabilities and tested for penetration.

FDA asserts that integrating SPDF early in the design phase helps avoid costly redesigns when vulnerabilities or connectivity features are discovered later. The SPDF encompasses everything from initial design to decommissioning, including secure coding, architecture reviews, patchability, and incident response planning. An SPDF can be integrated with existing processes for product and software development, risk management, and supporting the quality system at large.

Cybersecurity Objectives

Many readers might be familiar with the C.I.A trio — confidentiality, integrity and availability — championed by NIST. The FDA identifies these and expands these foundational objectives as follows:

• Authenticity (including integrity): Ensuring the device functions as intended without unauthorized modifications.
• Authorization: Limiting access and control to authenticated users and systems.
• Availability: Keeping device functionality uninterrupted.
• Confidentiality: Protecting sensitive patient or system data from unauthorized access.
• Secure Updatability: Supporting timely and safe software and firmware updates.

Figure 1: FDA’s expanded security objectives

When these objectives are not met anytime in the life cycle of the device, risks emerge. For example, TR24971: 2020 identifies Loss of Data Integrity, Loss of Confidentiality and Loss of Availability as hazards in Table F1.

Threat Modeling

FDA recommends that threat modeling be performed to inform and support the risk analysis activities and to identify appropriate security risks and controls for the medical device system.

According to FDA, threat modeling includes a process for identifying security objectives, risks and vulnerabilities across the medical device system and then defining countermeasures to prevent, mitigate, monitor or respond to the effects of threats to the medical device system throughout its life cycle. Few things to note here are that FDA thinks:

1. Threat modeling is an integral part of risk assessment
2. Threat modeling should be performed as part of the design process
3. Threat modeling should be inclusive of all design elements
4. Threat modeling not only provides a great starting point for risk identification, but also for assignation of risk controls
5. Threat modeling should identify medical device system risks and mitigations, as well as inform the pre- and post-mitigation risks considered as part of the cybersecurity risk assessment
6. Threat modeling exercise should state any assumptions about the medical device system or environment of use (e.g., hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets)

The FDA recommends that premarket submissions include threat modeling documentation to demonstrate how the medical device system has been analyzed to identify potential security risks that could impact safety and effectiveness.

While FDA concedes there are a number of methodologies and/or combinations of methods for threat modeling that manufacturers may choose to use, it allows for the rationale supporting the methodology or methodologies selected to be provided alongside other threat modeling documentation.

Threat models start with a data flow diagram. The version we will use here is called DFD3, popularized by Adam Shostack. You can learn more about it in this video.

Figure 2: A simple threat model

This data flow diagram (DFD) in Figure 2 illustrates a basic web application architecture where a user device communicates with a web server via secure HTTPS requests and responses. The web server processes the request, interacts with an internal SQL database through SQL queries, and returns the query result to the user. A red dashed "Trust Boundary" separates external (untrusted) components, like the user device, from internal (trusted) components, such as the web server and database. This boundary highlights the critical interface where cybersecurity risks—such as injection attacks, spoofing, and unauthorized access — must be mitigated through proper controls like encryption, input validation, and authentication.

FDA also mentions in the guidance that:

To fully account for cybersecurity risks in medical device systems, the safety and security risks of each device should be assessed within the context of the larger system in which the device operates. What this means is that manufacturers have to consider the ecosystem within which the device operates whether it be within a hospital or at the home of the patient. This includes assessing the impact of network elements in these locations as they interface with the device and potentially act as threat surfaces for cyber risks.

DFDs are especially useful in accomplishing this, as they allow the whole ecosystem of the device to be mapped.

Once the DFD is completed, risks need to be identified at minimum at every interface and, at most, at every element. This can be done a variety of ways, and I recommend using STRIDE, which is elaborated in Table 1.

Table 1: STRIDE Model

Now comes the time to document the risks in a cybersecurity risk assessment.

Cybersecurity Risk Management

According to the guidance:

For completeness in performing risk analyses under 21 CFR 820.30(g), FDA recommends that device manufacturers conduct both a safety risk assessment and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety risks.

The content of this cybersecurity risk assessment that is distinct from safety risk assessment can vary in terms of parameters analyzed, but it should be informed by your threat model.

FDA goes on to say:

Performing security risk management is distinct from performing safety risk management as described in ISO 14971. The distinction in the performance of these processes is due to the fact that in the security context versus the safety context, the scope of possible harm and the risk assessment factors may be different. Also, while safety risk management focuses on physical injury, damage to property or the environment, or delay and/or denial of care due to device or system unavailability, security risk management may include risks that can result in indirect or direct patient harm. Additionally, risks that are outside of FDA’s assessment of safety and effectiveness, such as those related to business or reputational risks, may also exist.

The first objective of a security risk management process as an integral part of SPDF is to expose how threats, through vulnerabilities, can lead to impact, i.e. manifest patient harm and other potential risks. The second objective is to ensure that risk control measures are applied to prevent these impacts and that control measures for one type of risk assessment do not inadvertently introduce new risks in the other. The impacts may or may not be patient related.

I recommend that in the cybersecurity risk assessment, the following four things are essential to be identified in the risk identification phase:

1. Asset
2. Threat
3. Vulnerability
4. Impact

An “asset” can be an element in the DFD, “threats” can be parsed using STRIDE (as shown in Figure 2), “vulnerabilities” are flaws in the design that the software which cyber teams will need to brainstorm by asking: how can the threat exploit a current design weakness in the software? Finally, “impact” is the potential outcome of the cybersecurity risk.

Once this information is documented, we need to prioritize it.

FDA notes:

cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling (also known as a “probabilistic manner”). This non-probabilistic approach is not the fundamental approach performed in safety risk management under ISO 14971 and further underscores why safety and security risk management are distinct but connected processes. Instead, security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system.

CVSS scoring is fast becoming the standard for cybersecurity risk assessments as it allows for the use of curated risk parameters to determine exploitability and impact. CVSS scoring is also referenced in the 2016 FDA guidance Postmarket Management of Cybersecurity in Medical Devices. See more here for CVSS.

See Table 2 for a basic cybersecurity risk assessment. Now comes the important part: assignation of risk controls.

Security Risk Controls

The threat modeling exercise should provide a good set of initial risk controls. In the threat model in Figure 2, let’s analyze the interaction of “HTTPS request.” A sample output of Microsoft Threat Modeler can be as shown in Figure 3.

Figure 3: Output of Threat Modeling Exercise

Effective cybersecurity relies upon security being “built in” to a device, and not “bolted on” after the device is designed. This is security by design.

FDA recommends that device manufacturers’ design processes include design inputs for cybersecurity controls. Security controls allow manufacturers to achieve the security objectives outlined earlier.

FDA recommends that an adequate set of security controls should include, but not necessarily be limited to, controls from the following categories:

• Authentication;
• Authorization;
• Cryptography;
• Code, Data, and Execution Integrity;
• Confidentiality;
• Event Detection and Logging;
• Resiliency and Recovery; and
• Updatability and Patchability.

Implementation of security controls should be applied across the system architecture using risk-based determinations associated with the subject connections and devices. Without adequate security controls across the medical device system, which include management, technical, and operational controls, there is no reasonable assurance of safety and effectiveness. Additionally, deficiencies in the design of selected security controls or the implementation of those controls can have dramatic impacts on a device’s ability to demonstrate or maintain its safety and effectiveness.

Manufacturers should submit documentation in their premarket submissions demonstrating that the security controls for the categories above have:

1. been implemented, and
2. been tested in order to validate that they were effectively implemented.

Cybersecurity Risk Assessment – Bringing It All Together

Table 2 shows a basic cybersecurity risk assessment that brings all the elements we discussed together. It easily accepts input from the threat model and lends itself to CVSS scoring for prioritization. Depending on the context of operation, additional fields can be added onto this assessment, such as residual score, environmental score, causes, verification of implementation and effectiveness, etc.

Table 2: Basic Cybersecurity Risk Assessment

A potential cybersecurity risk can have an impact on safety. AAMITIR57:2016/R2019 clarifies visually in Figure 4 in that Technical Report that security risks with potential safety impacts need to evaluated as safety risks through the safety risk management workflow. Not only that, the report further clarifies that any security controls affected safety should be analyzed and evaluated as safety risks and vice versa.

Cybersecurity Testing

As with other areas of product development, testing is used to demonstrate the effectiveness of design controls. Cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context, therefore demonstrating that the device has a reasonable assurance of safety and effectiveness.

FDA recommends verification and validation include sufficient testing performed by the manufacturer on the cybersecurity of the medical device system through which the manufacturer verifies and validates their inputs and outputs, as appropriate. Security testing documentation and any associated reports or assessments should be included in the premarket submission and be documented in the Cybersecurity Risk Assessment in appropriate columns.

In addition to standard verification testing, FDA recommends that the following types of testing, among others, be considered for inclusion in the submission:

Table 3: Types of cybersecurity testing

In some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups, such that vulnerabilities or other issues revealed during testing are appropriately addressed. For any third-party test reports, manufacturers should provide the original third-party report. For all testing, manufacturers should provide their assessment of any findings, including rationales for not implementing or deferring any findings to future releases. Vulnerabilities and anomalies identified during testing should be assessed for their security impacts as part of the security risk management process.

Labeling Recommendations for Devices with Cybersecurity Risks

For devices with cybersecurity risks, informing users of relevant security information may be an effective way to comply with labeling requirements relating to such risks. FDA also believes that informing users of security information through labeling may be an important part of design and development activities to help mitigate cybersecurity risks and help ensure the continued safety and effectiveness of the device. Any risks transferred to the user should be detailed and considered for inclusion as tasks during usability testing (e.g., human factors testing) to ensure that the type of user has the capability to take appropriate actions to manage those risks.

Conclusion

The FDA's 2025 final guidance represents a significant formal step in evolution in how cybersecurity is managed and regulated in medical devices. While the content has no major surprises, it does make FDA expectations clear by defining expectations for SPDF integration, cybersecurity risk management, threat modeling, life cycle monitoring and robust documentation.

Manufacturers must act now to align their development and quality systems with this guidance to ensure regulatory compliance and protect patients from cyber-related harm in an increasingly connected healthcare ecosystem.

About The Author

Jayet Moon earned a master’s degree in biomedical engineering from Drexel University in Philadelphia and is a Project Management Institute (PMI)-Certified Risk Management Professional (PMI-RMP). Jayet is also a Chartered Quality Professional in the UK (CQP-MCQI). He is also an Enterprise Risk Management Certified Professional (ERMCP) and a Risk Management Society (RIMS)-Certified Risk Management Professional (RIMS-CRMP). He is a Fellow of the International Institute of Risk & Safety Management. His new book, Foundations of Quality Risk Management, was recently released by ASQ Quality Press. He holds ASQ CQE, CQSP, and CQIA certifications.