What happens when a hospital cannot patch a vulnerable medical device right away?

What to do when patching must wait

A hospital should treat the device as an unpatched exposure, not as a deferred maintenance task. The practical response is to narrow who and what can reach it, reduce the attack surface around it, and decide which clinical workflows can tolerate continued use under tighter compensating controls. For device-heavy environments, the Medical Device Security Guide is the clearest starting point for segmentation, inventory, and clinical downtime planning.

The right question is not only whether the patch exists, but whether the device is exposed in ways that make exploitation useful to an attacker. If it is reachable from broader hospital networks, remote management paths, or systems that hold credentials and patient data, the interim risk is usually higher than the original vulnerability description suggests.

In practice, hospitals should preserve safety first, then reduce reachability second. That often means isolating the device on a dedicated network segment, limiting administrative access, disabling unnecessary services, and restricting cross-zone traffic to only the minimum required clinical and support functions.

How compensating controls reduce the window of exposure

Compensating controls work by making exploitation harder, noisier, or less useful while the patch window remains open. The most effective controls are the ones that change the attacker’s path: segmentation, least-privilege access, stronger monitoring, and application-specific allowlisting where the device and workflow permit it.

For devices that support only limited hardening, the control objective shifts to surrounding systems. Monitoring should focus on unusual connections to the device, unexpected administrative activity, and traffic patterns that suggest probing, lateral movement, or command-and-control behavior rather than routine clinical use. Hospitals that need a broader triage model for active vulnerabilities can use the CISA Known Exploited Vulnerabilities Catalog to confirm whether the issue is already being exploited in the wild.

Prioritization should be exposure-driven, not calendar-driven. A device that is internet-facing, shared across wards, or reachable from flat internal segments deserves faster containment than an equally vulnerable asset that is tightly isolated and rarely touched.

When hospitals need to compare exposure levels across many vulnerabilities, FIRST EPSS can help rank which flaws are more likely to be exploited before patching becomes available.

What must be checked before the device goes back to normal access

Once patching or mitigation is in place, the hospital should not assume the device was untouched during the delay. The key operational question is whether the vulnerable system was merely exposed or whether it was already used as an entry point. That means reviewing logs, alerts, and adjacent systems for signs of unauthorized access, new accounts or sessions, unusual outbound traffic, and movement into other clinical or back-end environments.

If the device stores or transmits credentials, tokens, or service access material, those secrets may need rotation even when the patch is applied cleanly. The real issue is blast radius: an attacker who reached the device may have used it to access something more valuable than the device itself.

Hospitals that want a broader baseline for detecting and containing follow-on activity can align the response with the MITRE ATT&CK Enterprise Matrix, especially for credential access and lateral movement patterns that often follow device compromise.

Risk and Threat Considerations

Delayed patching keeps a known weakness alive inside an environment that is often highly connected, operationally sensitive, and difficult to take offline. The main risk is not just exploitation of the medical device itself, but the device becoming a bridge into broader clinical or enterprise systems.

Failure mechanism: Attackers exploit the unpatched device directly, or use it as a foothold to pivot into adjacent systems that trust its network position or data flows. If segmentation and monitoring are weak, the vulnerability can remain quietly reachable long enough for abuse, persistence, or lateral movement.

Impact: The hospital can face clinical disruption, data exposure, loss of trust in the device environment, and a much larger recovery effort than a simple patch job would have required. In the worst case, the device becomes part of a broader compromise path rather than an isolated technical issue.

Practitioner Guidance

What to prioritise: First confirm whether the device can be isolated without affecting patient care, then narrow access around it before waiting on a clean remediation path. If the device cannot be segmented, treat the exception as a higher-risk condition rather than a normal operating state.

What to verify: Verify that the compensating controls are real in traffic terms, not just documented on paper. A useful test is whether the vulnerable device can still be reached from broader user, server, or vendor paths that do not directly support the clinical workflow.

Practitioner takeaway: The goal is not to keep the device merely online, but to keep it clinically usable while making compromise materially harder and materially less useful.

Related resources from NHI Mgmt Group

• What happens when a medical device cannot verify software and firmware updates?
• How should security teams handle critical vulnerabilities when patching cannot happen right away?
• What happens when a vulnerable dependency cannot be remediated without changing version ranges?
• What happens when a hospital network is breached without effective segmentation around connected medical devices?