Healthcare2 min read

The Clinical Equipment You Are Not Allowed to Patch

Imaging, lab and monitoring devices routinely run operating systems years past support, on the same network as everything else, under contracts that forbid you touching them.

Somewhere in your practice there is a piece of equipment running an operating system that stopped receiving security updates several years ago. You know about it. You have probably raised it. And the answer from the manufacturer was that patching the embedded computer voids support, or invalidates the validation, or is simply not permitted under the service agreement.

So it sits there, unpatched, on the network, and everybody has quietly agreed not to think about it.

The exposure is not the device, it is the neighbourhood

The device itself is rarely the target. It is a route and a casualty.

A route, because an unpatched system reachable from the general network is a foothold, and a foothold on the same flat network as your EHR workstations and your file shares is the beginning of the incident.

A casualty, because when ransomware sweeps a flat network it takes the imaging workstation with it, and now you are cancelling appointments while the manufacturer schedules an engineer.

Either way the answer is the same and it is not "patch it," because you cannot.

What you can do instead

Find them all first. Most practices do not have a current inventory of connected clinical devices. Start with what plugs into the network, including the things procured by clinical departments without IT involvement, which is most of them.

Put them where a compromise cannot reach. Network separation is the substitute for patching. The device keeps running its old operating system; it simply cannot be reached from the part of the network that receives email, and it cannot reach the part of the network that holds records.

Control the vendor's access. Manufacturers frequently hold standing remote connections for support, established at installation, outside your identity system, sometimes shared across their customer base. Those should be on-demand, logged, and attributable to a person.

Write the risk down and have somebody accept it. Some of this cannot be fully remediated, and that is a legitimate position. What is not legitimate is leaving it undocumented. A risk formally accepted by a named person, with a review date, is a governance position. The same risk unrecorded is a finding waiting for an auditor.

The procurement fix that prevents the next one

Every one of these devices arrived through a purchase, and the purchase is where the leverage was.

Adding three questions to clinical equipment procurement changes the position over time: what operating system does it run and what is its support horizon, what is your patching and vulnerability commitment for the life of the contract, and what network access does it require. Vendors answer these routinely for larger customers, and they answer them when asked.

That will not fix the estate you have. It stops it growing.

What this has to do with HIPAA and your insurer

Two practical connections worth making.

The security rule expects a risk analysis that reflects your actual environment and is kept current. An unpatchable device that is inventoried, segmented, documented and reviewed is evidence of a functioning process. The same device unmentioned is evidence of the opposite.

Your cyber insurer will ask about patching and segmentation on the application. An honest answer that describes compensating controls is defensible. An unqualified yes that a claim investigation contradicts is not.