Healthcare Asset Inventory: The Devices Nobody Knew Were There

Do you know everything connected to your network right now?

I ask healthcare IT leaders that question often, and almost nobody says yes. What I usually get is a number followed by a qualifier. Roughly this many endpoints, plus whatever biomed has, plus whatever facilities installed, plus the vendor equipment nobody logged.

That is not a knock on anyone. It is the honest condition of a modern healthcare network. And why an uncommon approach to OT and IoT is a critical capability for these environments.

What's actually connected to a healthcare network

Infusion pumps. Imaging systems. Nurse call. Building controls. Bed sensors. Badge readers. A lot of it was bought by clinical or facilities teams rather than IT, and much of it cannot run an agent at all.

Which creates an odd split. You are answerable for everything on that network. Your tools only report on the part of it that will accept your software.

Common security is built that way on purpose. Install the agent, get the visibility, treat the rest as somebody else's category. In most industries that leaves a manageable gap. In healthcare the leftover is a large share of the network, and a good deal of it is attached to patients.

ECRI, the independent nonprofit that has been evaluating medical devices for more than fifty years, publishes an annual list of the ten biggest technology hazards to patient safety. Number eight for 2026 is "Cybersecurity Risks from Legacy Medical Devices." As they put it, legacy devices "provide an opening that malicious actors can exploit." Number two is unpreparedness for a "digital darkness" event, which they define to include cyberattacks, natural disasters, vendor outages and internal system failures.

That is a patient safety list, not a security list. Connected device risk is on it twice.

Customer one: more devices than anyone expected

We brought on two new healthcare clients this year. Both are the kind of organization we work with most, carrying enterprise-grade risk with an operator-sized team.

On the first network, discovery returned considerably more devices than the client expected, and showed that EDR and vulnerability management coverage did not reach all of them.

Finding devices you did not know about is not a diligence failure. In our experience OT and IoT can account for up to half the connections in an environment, and no agent-based tool will ever report on something it was not installed on. The client was not missing things. Their tools were.

So we extended coverage across everything discovery found and gave them one picture instead of several partial ones. Then we built detections against the conditions their environment actually presented rather than generic ones.

The part they valued most came last, and it surprised me a little. We started enriching the inventory with business context, tagging critical assets, subnets, and device classes by what they do and what data they touch. That is what turns a list of devices into something you can hand to a compliance team. When somebody asks which systems touch PHI and what protects them, the answer is already assembled.

Customer two: the call is coming from inside the house

On the second network, discovery surfaced a critical active risk at the very outset of our deployment: Malware, sitting on an IoT device. No agent on it, no EDR on it, so nothing had ever reported it. Earlier reviews had missed it entirely. We removed it, and the client was glad we looked. So were we.

For a sense of how far these dependencies now run, look at what happened to Stryker in March. Attackers got into Stryker's own corporate systems and wiped data from a very large number of company devices. No hospital network was touched. Hospitals still felt it.

Two ways. Clinicians in Maryland lost the Stryker bed sensors and hands-free communication they use during shifts, and went back to radios and talking to each other. And because Stryker manufactures patient-specific orthopedic implants, built to order for an individual patient, the shutdown of its manufacturing and shipping meant some hospitals could not get the implants their scheduled surgeries were designed around. Those procedures had to be postponed.

Nothing on those hospital networks was compromised. The dependency was the exposure, and it arrived through a supplier rather than an attacker on the network. ECRI lists vendor outages in its digital darkness scenario for exactly this reason. Our Uncommon value is the ability to see everything and evaluate for risk – this is essential in a healthcare environment.

Now add AI to a network you cannot fully see

ECRI's number one hazard for 2026 is the misuse of AI chatbots in healthcare.

I wrote in May that clinical staff are already experimenting with public AI tools to summarize notes, draft communications and accelerate research, often without clear guidance on what is safe to share. That has not slowed down. AI now arrives through clinical applications, administrative tools, vendor products, and whatever people have on their phones, and very little of it announces itself on a network diagram.

The useful question is not whether to allow AI. It is whether you can see where it already is. If an AI-connected system carries a risk rating on the same scale as an infusion pump or a domain controller, you can prioritize it against everything else and act accordingly. If it is invisible, you are governing something you cannot find. Again, this is an uncommon security capability that will only increase in importance as AI use multiplies.

What I take from both of these

Neither client had a discipline problem. Both had a visibility problem, and visibility problems are quiet. They sit there until something on the uncounted part of the network gets used against you.

The uncomfortable part is that you cannot audit your way out of this one. You cannot write a policy for a device you have not counted, segment a subnet you have not mapped, or patch a system nobody knows is running. Every good practice in security assumes an accurate inventory underneath it, and in healthcare that assumption is usually wrong. What’s needed is an uncommon security solution for an increasingly common problem.

Which is why I keep pushing on the whole environment rather than the part of it that happens to run our software. In May I wrote that healthcare providers keep coming to us with the same three needs: complete visibility, expert capacity they cannot hire for, and an AI strategy that keeps pace with how their teams already work. This is what the first of those looked like on two of their networks.

If you want to know what is actually on yours, we can show you in days. Contact us today.