Walk through any clinic and you’ll pass a dozen computers that nobody thinks of as computers. The infusion pump is a computer. So is the vitals monitor, the ultrasound cart, the lab analyzer, and the imaging workstation in the back. Each one runs software, connects to your network, and often holds or touches patient data. And here is the uncomfortable part: a large share of them are running operating systems that went out of support years ago — and that the manufacturer won’t let you patch even if you wanted to.
Medical device security is the risk we most often find unowned when we start working with a healthcare practice. The clinical staff assume IT is handling it. IT assumes the device vendor is handling it. The vendor considers it the practice’s network. So the connected MRI running a decade-old OS sits on the same flat network as the scheduling workstations and the EHR, quietly, until the day it becomes the way in.
The blind spot in clinical IT
Traditional IT security assumes you can do the basics: inventory your machines, patch them on a schedule, run security software on them, and replace them when they age out. Medical devices break every one of those assumptions. They’re purchased by clinical departments, not IT. They’re commissioned by a vendor and then largely left alone. They’re expensive enough that they stay in service for ten or fifteen years — long past the support life of the software inside them. And because they’re medical equipment, you often legally can’t modify them without voiding certification.
The result is a population of networked computers that nobody patches, nobody scans, and frequently nobody has even written down. You can’t defend what you don’t know you have — and in our experience, the device inventory is almost always the first thing that’s missing.
Why these devices are different
- They were built for function, not security. The design priority was clinical accuracy and reliability. Network hardening was an afterthought, or simply wasn’t a concern when the device was designed.
- They run outdated, unpatchable software. Embedded operating systems that are years past end-of-support are the norm, and the manufacturer’s certification often forbids you from updating them yourself.
- You can’t just unplug them. A vulnerable workstation can be quarantined in minutes. A device in the middle of a patient’s care cannot — taking it offline has clinical consequences, which is exactly the leverage an attacker counts on.
- They’re a foothold and a target at once. A device is both a soft entry point onto your network and, frequently, a store of the protected health information that makes you a target in the first place.
Two kinds of damage: data and patient safety
Most security conversations stop at the data breach, and that risk is real — a compromised device can expose protected health information, which under HIPAA means breach notification, an HHS investigation, potential penalties, and the reputational damage that follows a public disclosure. For a practice, the cost of that aftermath routinely dwarfs the cost of having prevented it.
But healthcare carries a second category that other industries don’t: patient safety. When ransomware sweeps a hospital network and clinical devices go dark, procedures get cancelled, monitoring is lost, and care is disrupted in ways that genuinely endanger people. The device that can’t be taken offline for a patch is the same device whose sudden failure mid-care is a clinical emergency. That dual stake is why this deserves real attention rather than a line in a checklist.
Segment what you cannot patch
If you take one thing from this article, take this: the single most effective control for medical devices is network segmentation. Put the devices on their own isolated network segment — a clinical VLAN — walled off by a firewall from your general office network, your EHR, and the open internet. Each device is then allowed to talk only to the specific systems it genuinely needs, and nothing else.
Done well, segmentation changes the whole calculus. An attacker who compromises an unpatchable ultrasound cart finds themselves on a tiny, locked-down island — unable to move laterally to the records, unable to reach out for instructions, unable to spread. The device is still unpatched, and that’s fine, because it can no longer be used as a bridge to anything that matters. You’ve replaced “impossible to fix” with “contained.”
A practical playbook
- Inventory every connected device. Build the list IT almost never has: every networked medical device, its make and model, the software it runs, what data it touches, and what it needs to communicate with. This is the unglamorous foundation everything else stands on.
- Assess each device’s real risk. What OS is it on? Is it supported? Does it hold PHI? Can it reach the internet today? Rank by exposure, not by how new the equipment looks.
- Segment and apply least-privilege networking. Move devices onto an isolated VLAN behind a firewall, and write rules that permit only the connections each device truly requires. Default-deny everything else.
- Monitor what you can’t patch. If a device can’t run security software, watch its network behavior instead. A device that suddenly tries to scan the network or call an unfamiliar server is the early warning you’ll wish you had.
- Budget for end-of-life. Some devices are simply too dangerous to keep on any network. Track their obsolescence and plan replacement deliberately — it’s a capital decision, and it shouldn’t arrive as a surprise during an incident.
- Lock down access and keep vendor contacts current.Restrict administrative access to the few people who need it, and keep a live list of vendor security and support contacts — you do not want to be hunting for them at 2 a.m. during a problem.
Who actually owns this
The reason medical device security falls through the cracks is that it sits exactly between clinical operations, the device manufacturers, and IT — and so it ends up belonging to no one. The fix is to make it explicitly someone’s job. Whether that’s an internal lead or a managed partner, somebody has to own the inventory, the segmentation, the monitoring, and the replacement roadmap, and keep them true as equipment comes and goes.
This is core work for our healthcare practice: we discover and inventory the connected devices, design and implement the clinical VLAN and firewall rules, stand up behavior monitoring for the equipment that can’t be patched, and fold it all into the documentation an HHS audit expects to see. If you’re not certain what’s on your clinical network — and most practices aren’t — we’ll run a device-security assessment with you and hand back a written inventory, a risk ranking, and a segmentation plan. No disruption to patient care; just the map you’ve been missing.