What do healthcare teams get wrong about protecting older medical devices and legacy systems?

Why older medical devices are usually a network problem, not a standalone asset problem

Healthcare teams often miss that legacy devices remain dangerous because they are still embedded in clinical workflows, connected VLANs, and vendor support paths. The issue is not simply that a device is old, but that it can still influence authentication, remote access, imaging, prescription, monitoring, or downstream hospital systems. That is why inventory and network context matter as much as the device label itself.

Legacy equipment also tends to accumulate exceptions. Teams may know the model, but not the firmware state, owner, business criticality, or which interfaces are exposed to broader clinical networks. When that happens, the organisation cannot reliably distinguish a low-value retired asset from a live pathway into patient-care systems.

Healthcare teams also underestimate how often these devices create hidden dependencies. A device may be clinically essential, but still depend on obsolete operating systems, unsupported middleware, or a vendor remote-service path that widens the trust boundary. The right question is not “is it still working?”, but “what else does it touch, and what inherits its risk?”

What controls matter most when patching is slow or impossible

For older devices, the practical control stack is usually inventory, segmentation, patch prioritisation, compensating controls, and retirement planning. That is the only sequence that scales when a device cannot be patched quickly, or when patching would create clinical downtime that the hospital cannot absorb. Treating every exposed device as equally urgent often produces noise, not risk reduction.

Segmentation is especially important because many legacy devices fail safely only inside a constrained environment. Limiting what they can reach, and what can reach them, reduces the blast radius if the device is vulnerable or cannot be updated. For a broader operating model, the Medical Device Security Guide is the most direct reference for device inventory, postmarket controls, SBOMs, and clinical downtime trade-offs.

When patching is delayed, teams should shift from “fix first” thinking to “bound exposure first” thinking. That usually means restricting admin access, disabling unnecessary services, tightening vendor connectivity, and documenting the exception with an expiry date. The point is to reduce practical exploitability while the longer remediation path is being executed.

Device lifecycle management also matters. If equipment is so old that it cannot be defended to an acceptable level, retirement or isolation is the security decision, not a last resort. The Operating System End of Life and Extended Support Guide is useful where the real issue is unsupported platform exposure rather than the medical function alone.

Why legacy technology can affect patient safety as well as cyber risk

Older medical devices are not just susceptible to compromise, they can also distort clinical operations when security teams try to protect them badly. A rushed patch, a bad network change, or an overbroad isolation control can interrupt monitoring, delay workflows, or disable a device that clinicians still depend on. That is why security and clinical safety have to be planned together.

Legacy systems also create a false sense of stability. Because they are familiar and already in production, teams may assume they are low priority. In reality, unsupported equipment often has the least visibility, the weakest update path, and the longest dwell time if compromise occurs. For manufacturers and operators who need a deeper lifecycle view, the IEC 81001-5-1 Health Software Security Lifecycle Guide helps explain why lifecycle controls matter long after initial deployment.

Risk becomes higher when these devices sit on shared clinical networks or depend on legacy remote support channels. That combination can turn a single weak endpoint into a route toward imaging systems, admin consoles, or hospital core services. The safer approach is to treat the device as part of a connected clinical ecosystem, not as a one-off hardware exception.

Risk and Threat Considerations

Older medical devices are attractive to attackers because they often combine weak patchability, broad internal connectivity, and long service life. The most common failure mode is not a dramatic device takeover, but a quiet foothold that can be used for lateral movement, disruption, or persistence inside a clinical network.

Failure mechanism: An unpatched or unsupported device remains reachable from networks it should not touch, or retains vendor access and weak segmentation that lets an attacker pivot beyond the device itself.

Impact: The result can be clinical downtime, exposure of connected systems, and increased patient-safety risk if the compromised device or its dependencies support active care delivery.

Practitioner Guidance

What to prioritise: Start with devices that are internet-reachable, vendor-remotely-accessible, or attached to flat clinical networks. Those are the assets most likely to create immediate blast-radius problems if they are compromised.

What to verify: For each legacy device, confirm owner, support status, network path, patch state, compensating controls, and whether retirement is already scheduled. If any of those are unknown, the control is not mature enough to trust.

What good looks like: Security and clinical engineering share a current inventory, exceptions expire, segmentation is enforced in practice, and older devices are either supported, isolated, or actively removed from service.

Practitioner takeaway: The goal is not to make every old device “secure enough” in the abstract, but to reduce its reachable attack surface, document the exception honestly, and retire anything that cannot be bounded to an acceptable clinical risk.

Related resources from NHI Mgmt Group

• What do security teams get wrong about protecting connected medical devices?
• What do healthcare organisations get wrong about service accounts on medical devices and clinical platforms?
• What do organisations get wrong about bcrypt in legacy systems?
• What do organisations get wrong about protecting personal data inside ERP systems?