Ransomware and Medical Devices: What the FDA Expects

Ransomware is the attack hospitals fear most, and medical device makers often assume it is someone else's problem. The device is a closed system, the thinking goes, and the hospital owns the network. The FDA does not accept that framing.

The February 3, 2026 final guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," asks manufacturers to design for resilience. That includes how a device behaves when connected systems are unavailable or hostile.

Ransomware is the clearest real-world test of that expectation. A device that stops delivering therapy because a hospital file server was encrypted is a safety problem, not just an IT problem. This post explains how ransomware reaches devices and what a submission needs to show.

Why This Matters

Ransomware has already disrupted patient care at scale. In May 2017, WannaCry disrupted 81 of 236 NHS trusts in England, according to the UK National Audit Office, and some devices and diagnostic systems were taken offline. In February 2024, the ransomware attack on Change Healthcare exposed data on roughly 190 million people, according to the HHS Office for Civil Rights, and disrupted claims and pharmacy systems across the United States.

Neither attack was aimed at a specific device. Both show how device availability depends on the systems around it. That is why the FDA's February 3, 2026 guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," treats availability and resilience as security objectives alongside confidentiality and integrity.

Section 524B of the FD&C Act requires manufacturers of cyber devices to design, develop, and maintain processes that provide reasonable assurance the device and related systems are cybersecure. For a ransomware scenario, the standards that shape the evidence are AAMI TIR57 and ANSI/AAMI SW96 for security risk management, ISO 14971 for safety risk, and IEC 81001-5-1 for secure development activities. The FDA reviewer wants to see that ransomware was considered as a realistic threat, that its effect on patients was assessed, and that controls reduce the risk to an acceptable level.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B); CISA Cybersecurity Advisories (including ICS medical advisories).

How does ransomware reach a medical device?

Ransomware reaches devices through the paths they share with ordinary IT. The device is rarely the first system hit, but it is often collateral damage.

The common paths are:

• General-purpose operating systems. Imaging consoles, lab analyzers, and nurse stations often run Windows. They can be encrypted like any workstation.
• Flat hospital networks. When devices share a network segment with office computers, ransomware that spreads laterally can reach them.
• Back-end dependencies. A device that needs a server for worklists, drug libraries, or licensing can stop working when that server is encrypted, even if the device itself is untouched.
• Remote service access. Vendor remote access tools and shared service credentials give attackers a route in if they are not tightly controlled.
• Removable media and update paths. Unsigned update packages or open USB ports let malicious code arrive during servicing.

What does the FDA expect a submission to show about ransomware?

The FDA expects the submission to show that the manufacturer thought through a compromised environment and designed for it. Ransomware is not named as a mandatory section, but it is one of the clearest ways to show resilience.

In practice, reviewers look for this evidence in four places:

The full list of deliverables and where each one goes in eSTAR is in our FDA premarket cybersecurity deliverables and eSTAR map.

Which design controls limit ransomware harm?

The controls that limit ransomware harm reduce the ways it can arrive and keep essential functions running when it does. None of them removes the risk alone.

• Least functionality. Remove unused services, ports, and software, especially on general-purpose operating systems.
• Network segmentation support. Document the ports and protocols the device needs so hospitals can isolate it.
• Application allowlisting. On Windows-based devices, allow only approved executables to run.
• Signed and verified updates. Reject any update package that is not authenticated.
• Offline or degraded operation. Keep therapy delivery or core measurement working when servers are unreachable, with clear alerts.
• Tested recovery. Provide a documented way to restore a known-good image and configuration.

See also: SBOM for SaMD and Cloud Components: FDA Guide, What Is a Cyber Device Under FDA Section 524B?, and Home Use vs Hospital Device Cybersecurity Requirements.

A threat-model-driven medical device penetration test should try the same paths ransomware uses, including lateral movement and remote service access. Mostly manual, expert-led testing finds these paths more reliably than automated scanning alone.

How should labeling address ransomware recovery?

Labeling should tell hospitals what the device needs from the network and how to recover it after an incident. The FDA's guidance expects cybersecurity labeling that supports the customer's own risk management.

Useful labeling for a ransomware scenario includes the required ports and protocols, recommended network segmentation, how the device behaves when servers are unavailable, backup and restore steps, and a contact for coordinated vulnerability disclosure. A current MDS2 form helps hospital security teams plan. See our guide to medical device cybersecurity labeling for the full content set.

If you are preparing a submission now, a short scoping call can confirm whether your threat model already covers a compromised-network scenario. Talk to our team.

How Blue Goat Cyber Approaches This

We treat ransomware as a design scenario, not an afterthought. Our threat models start from the assumption that the hospital network is compromised, then trace what that means for each device function and for the patient. We map every dependency the device has on network services and document what happens when each one disappears.

Our penetration testing is mostly manual and expert-led, with AI-driven and automated tooling supporting it. Testers attempt lateral movement, remote service abuse, and update tampering the way a ransomware operator would. Findings feed back into the security risk assessment so the submission tells one consistent story.

Our US-based engineers have supported more than 275 device submissions. Learn more about our FDA premarket cybersecurity services. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

Related reading: M2M Communication Vulnerabilities in Medical Devices: Risks, Mitigations, & FDA Expectations (2026), Q-Day Isn't a Future Problem for Medical Devices. It's a Present-Day FDA Compliance Gap.

Frequently Asked Questions

Can ransomware infect a medical device directly?

Yes, when the device runs a general-purpose operating system such as Windows, or accepts unsigned software. Imaging consoles, lab analyzers, and device workstations are the most exposed. Embedded devices on real-time operating systems are harder to encrypt, but they can still stop working if a server or gateway they depend on is encrypted. Both cases belong in the threat model.

Does the FDA require a ransomware section in a premarket submission?

No. The FDA does not require a section titled "ransomware." It expects the threat model, security risk assessment, and architecture views to account for a compromised environment, and ransomware is the most common real example of one. Showing how the device behaves when connected systems are unavailable or hostile answers the question reviewers are asking.

Isn't ransomware the hospital's responsibility?

Partly, and this is a common misconception. Hospitals own their networks, but Section 524B makes manufacturers responsible for the cybersecurity of the device and related systems. The manufacturer must design the device to limit harm in a hostile network and must give hospitals the information they need to protect and restore it. Responsibility is shared, not handed off.

What should a device do when its server is encrypted?

It should keep essential clinical functions working where that is safe, alert the user clearly, and avoid failing in a way that harms the patient. For some devices that means a local offline mode. For others it means a safe stop with a clear message. The right behavior comes from the safety risk analysis under ISO 14971.

How does penetration testing help with ransomware risk?

A penetration test shows whether the paths ransomware uses actually work against your device. Testers try lateral movement from the hospital network, abuse of remote service tools, weak credentials, and update tampering. The findings give reviewers evidence that the controls in your risk assessment hold up in practice.

CTA

If you want to know whether your threat model would hold up against a ransomware scenario, we can review it with you. We will show where a compromised network could affect patients and what evidence closes the gap. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Schedule a discovery call.

---

About the author. Christian Espinosa, MBA, is the founder and CEO of Blue Goat Cyber and a graduate of the US Air Force Academy. He has spent his career in offensive security, including testing aircraft systems, and now leads a team focused only on medical device cybersecurity. Read more about Christian.