Hospitals can’t address every medical device vulnerability at once, making clear ownership of the priority list—and HTM’s role in shaping it—critical.
By Shankar Somasundaram is the CEO of Asimily
When a vulnerability report comes in, there might be a few hundred threats flagged “critical.” There’s no path to resolving most of them this quarter (nor the one after it). No one in clinical engineering needs that scenario explained to them. Particularly as AI-accelerated vulnerabilities increase the stakes and the velocity, what can hospitals do?
Connected device/equipment security in hospitals has always been trickier than that of most other industries. A workstation might get patched overnight and rebooted before first shift, while an infusion pump running firmware that the manufacturer walked away from years ago does not. Or, a CT scanner with a vulnerability that should otherwise be pulled offline keeps on scanning because radiology is already running behind. Scale complicates things, and with the average hospital now operating a couple dozen connected devices per patient bed, a large healthcare system can have hundreds of thousands of networked assets live at a time. All this while hospital cybersecurity draws somewhere between 4% and 7% of hospital IT budgets.
Then there’s the question of who turns the proverbial wrench. Most medical equipment sits under manufacturer service agreements and regulatory constraints that keep IT from pushing updates on its own, so when fixes exist, applying them generally lands with clinical engineering. Often, healthcare technology management (HTM) absorbs the consequences of the priority order whether or not HTM had a hand in setting it.
The change needs to come with vulnerability prioritization. Prioritization is the work, not the fallback position. Healthcare systems need to figure out who makes the call and understand what they know the moment they make it.
How That Call Gets Made Today
We recently surveyed North American hospital CISOs about decision-making around connected device vulnerability remediation. Twenty-two percent described some blend of vendor alerts, CVSS scoring (which is a whole other issue), and whatever they happen to know about how a device gets used. Another 18% run a manual review. Fifteen percent said they have no clear process in place (I credit them for the honesty because the real figure is almost certainly higher). Put those last two groups together and roughly a third of hospital security programs run without a repeatable way to decide what gets touched first.
The problem with vendor alerts is they often arrive late—and usually by design. There is a “patient zero” hospital out there somewhere well before a manufacturer issues their broader notification, and your facility may have been sitting inside that window for months. CVSS scores, meanwhile, put numbers to a severity in the abstract, with no awareness of your network whatsoever: A 9.8 on a device behind real isolation can be all but irrelevant in practice, while a 6.1 on a workstation with a clean path into your imaging archive probably deserves somebody’s attention, right now.
Two Halves of One Decision
A truly defensible risk prioritization strategy requires two kinds of knowledge, and neither clinical engineering nor security holds both. Clinical engineering generally understands which devices are load-bearing for care delivery and which are effectively spares, where a device physically travels, what a two-hour outage does to the schedule, and which vendor is supposed to show up when you call. Security must know where a flaw is reachable from where the equipment sits, what the device genuinely communicates with, and how far somebody could move laterally after landing on it.
Nicholas Dybvig, assistant vice president of information security at Ardent Health, put it to me as, “A list built from either side alone is a guess dressed up as a priority order. Clinical engineering knows what the device is and what happens to patient care if a device goes down. Security knows what happens to the network if it’s compromised. If you leave either one out of the room, the priority order isn’t representing true risk.”
When You Cannot Patch, You Contain
Most of the fleet will never be patched on a normal cadence. That puts the weight on a containment strategy, and thus clear network segmentation becomes critical. In no hospital should a compromised cardiac monitor have a network route into the EMR. No HVAC controller should reach anything financial. But without network segmentation, this is exactly what happens.
Segmentation projects stall anyway, but the reasons have very little to do with networking skill. Traditional access control reduces a device to an IP address and a MAC address, which reveals next-to-nothing about what the equipment is or what it needs to reach in order to do its job. Without that context, broad policies are written where nothing “breaks,” but not much risk goes away either.
I see the same split showing up in network policy structure, where a policy that looks conservative on a whiteboard can still strand a device in the middle of a procedure, and the person who sees that coming is the biomed who supports it.
This (fixable) industry gap in segmentation orchestration is where we have put much of our effort at Asimily. Device intelligence that gets translated into policy can be pushed into a hospital’s existing network access control, so what gets enforced reflects observed behavior instead of a best guess. Whether any of it survives contact with the floor still comes down to people, though, and specifically to clinical engineering reviewing a proposed policy before it goes live.
Don’t Fumble the Handoff
Even with the right technology strategy, the handoff can make or break success. Ownership of connected equipment tends to get passed informally between departments until it lands with somebody who lacks the authority to act on it, or acts incompletely. Then you might get a third-party technician reconfiguring a machine during a service call without telling anyone. Weeks later, security finds out secondhand or via an audit, if at all.
Closing the gap requires a live picture of the fleet that both groups are willing to work from. A spreadsheet accurate on the day somebody built it simply does not get you there. Once security and HTM read the same inventory and the same risk ranking, the handoff is no longer contingent on whether anyone remembered to send an email.
HTM teams get described as a stakeholder in these conversations, someone security ought to consult. I’d argue that framing sells the position short, and it lets clinical engineering leaders off the hook a little as well. You are the one scheduling the downtime and sitting on hold with the manufacturer (and, least appealing of all, explaining to a department head why their equipment is unavailable at the moment). The list becomes your problem the moment it lands, which is reason enough to be in the room where it gets built, well before it does.
About the author: Shankar Somasundaram is the CEO of Asimily, a cyber asset and exposure management platform. Previously, he worked on IoT analytics and security solutions at Symantec, where he helped lead the company’s enterprise IoT product management.
ID 49998455 | Lab © Sudok1 | Dreamstime.com
