Medical equipment has become networked faster than it has become replaceable, and the result is an installed base of devices running operating systems that no longer receive security updates. The exposure is not dramatic in most cases; it accumulates quietly as the systems around the device change while the device does not. For a buyer of pre-owned equipment, that accumulation is a valuation and planning issue as much as a technical one, because it determines how long the device can remain connected, and connectivity is frequently what makes the device useful. This article sets out what the exposure is, who carries it, and what a buyer can still control.

What the Risk Actually Is

The risk has three layers, and separating them prevents both complacency and overreaction. The first is the device itself: an operating system or software component that no longer receives security updates cannot be fixed if a weakness is identified. The second is the network position: what the device is connected to, what it can reach, and what can reach it. The third is the operational dependency: what the department loses if the device has to be isolated from the network.

An unsupported device that operates standalone, communicates only over a dedicated link and holds no data of value presents a different exposure from the same device connected to a shared network and exchanging data with other systems. That is why the assessment is about the environment as much as about the device, and why the same equipment can be a manageable risk in one department and an unacceptable one in another. The extractable summary is this: the risk from an unsupported medical device depends on what it is connected to and what depends on that connection, not only on the fact that the software is no longer updated.

Who Carries It Under the Default Position

The organisation operating the equipment carries the operational exposure, regardless of who manufactured it or how old it is. That is a position many departments find uncomfortable, because they have no influence over the software, but the responsibility for deciding how the device is connected and what it may access sits with them.

The manufacturer’s position is narrower and relates to the support it provides and the updates it makes available. Once a product’s support ends, the manufacturer has no ongoing obligation to publish fixes, and the organisation’s exposure becomes a function of its own architecture and planning. Third-party service organisations can assist with configuration and isolation, but they cannot create security updates for software the manufacturer no longer maintains. The practical consequence is that the buyer’s influence lies in architecture, policy and lifecycle planning rather than in the software itself.

Device-side obligations continue to apply regardless of the software position, and they are illustrated nationally by frameworks such as the MHRA guidance on regulating medical devices, with expectations that apply across markets summarised by the WHO medical devices programme. Those obligations concern the device’s continuing safe use, which is a separate question from whether its software is current, and an organisation can be fully compliant with the former while managing an exposure in the latter.

Controls That Reduce It

The controls that reduce this exposure are architectural and procedural, and they work because they limit what an unsupported device can affect.

Evidence That the Controls Were Applied

Evidence in this area is a record of decisions rather than of tests. The question a reviewer asks is not whether the device is secure, which nobody can answer absolutely, but whether the organisation understood the exposure and took proportionate steps.

The frameworks that organisations use to structure this work come from the security standards that apply to their wider estate, and national material such as the CISA advisories and guidance and the NIST cybersecurity framework provides a structured approach that is independent of device type, with the supporting resource material available through NIST’s cybersecurity programme.

Where Controls Are Commonly Skipped

Controls are rarely skipped deliberately in this area; they are skipped because the device is treated as a clinical asset rather than a connected system.

• The device is not on the network register, so its connectivity is unknown to the people who manage the network.
• Connectivity was established for a specific function years ago and never revisited, so functions that are no longer needed remain reachable.
• The software version is not tracked, so unsupported devices cannot be distinguished from supported ones.
• The risk assessment is made once, at installation, and never repeated as the surrounding environment changes.
• Replacement planning treats the device as functional rather than as increasingly difficult to connect, so the horizon is set by hardware life rather than by support.
• The interaction between clinical workflow and connectivity is not examined, so an isolation decision is discovered to have a clinical consequence only when it is taken.

Two further gaps are worth naming. The first is that the device register and the network inventory are frequently maintained by different functions, so neither holds a complete picture of which devices are connected and how. The second is that upgrade and replacement planning is based on hardware condition, which tells the organisation how well a device works but not how safely it can remain connected. Both gaps are closed by the same change: recording connectivity and support status in the same place as the device’s identity, so that the position is visible when a planning decision is made.

That change also makes the position defensible. Where an organisation can show which devices are unsupported, how each is segmented, and when each is due to be replaced, the exposure is documented rather than latent, and a reviewer can see that the organisation understood it. Where those records do not exist, the review becomes an investigation, and investigations usually discover more than the original question asked about.

What to Do When It Goes Wrong

The situation that triggers action is usually a disclosed vulnerability in a component the device relies on, or a manufacturer notice that a platform can no longer be supported on a network. The practical steps are consistent and depend on knowing what the device is connected to and what depends on it.

Establish the affected population from the device register, including which units are connected and which are not. Assess the clinical consequence of removing connectivity, because that determines what options are available. Apply the available mitigations, which usually means segmentation, restriction or monitoring rather than updating. Where the consequence cannot be mitigated to an acceptable level, withdraw or isolate the device and plan the replacement. Record the sequence, including the clinical input that informed the decision, because the record is what demonstrates that the organisation weighed the exposure against the service consequence rather than acting on one alone.

Two elements make that response faster when it is needed. The first is a device register that records connectivity as well as identity, because an affected population cannot be established from a list that does not say which units are networked. The second is an agreed route for obtaining clinical input quickly, because the decision about whether a device can be isolated without disrupting care is clinical as well as technical, and a decision that waits for a scheduled meeting is a decision that arrives late.

Residual Risk the Buyer Must Accept

No amount of planning removes the exposure while an unsupported device remains connected, and the realistic objective is to bound it rather than to eliminate it. Two residual risks always remain: a weakness may be identified that no available control can fully mitigate, and the surrounding environment may change in ways that increase the device’s exposure without changing the device itself.

The decisions that make residual risk manageable are segmentation and time. A device whose connectivity is confined to what it needs, and whose remaining service life is defined, presents a bounded exposure that can be planned for. A device connected broadly with no replacement horizon presents an open exposure that will eventually force an unplanned decision. Recording the segmentation decision and the replacement trigger turns an uncomfortable risk into a managed one, which is the achievable outcome in this area.

It is also worth being clear about what this exposure is not. It is not a reason to avoid pre-owned equipment, because a new device will eventually reach the same position, and the question is when. What matters is whether the buyer knows the position at the point of purchase and has a plan that reflects it. A used device with two years of supported life and a defined replacement trigger is a more manageable proposition than a new device whose support position nobody has examined.

Buyers who want the wider context can start from the knowledge hub, see how equipment is described on the marketplace store, or use the lifecycle material in the industry hub.