How to choose a medical device security company: a buyer's checklist for hospitals

Why this decision is harder than it looks

Connected medical devices are now the largest and least-defended part of a hospital's attack surface. Infusion pumps, patient monitors, imaging controllers, and lab analyzers all sit on the network, and most of them cannot run a security agent, because they use closed or unsupported operating systems that a hospital is not permitted to modify. Claroty's 2025 research found that 99% of healthcare organizations have connected devices affected by known exploited vulnerabilities, and that a meaningful share of those devices are both internet-exposed and tied to insecure connections. That is the problem every medical device security company claims to solve.

The trouble is that most of them solve only the first half of it. They are very good at telling you what you have and how exposed it is. They are far less consistent at doing anything about it when an attacker is actually inside. For a buyer, that gap is the whole decision, because a risk report does not keep a hospital running when a device becomes an entry point at two in the morning.

Start with the question that actually matters

Before you compare feature lists, fix the frame. The point of IoMT security is not to produce a cleaner inventory. It is to make sure that when a connected device is compromised, the attack stops there and care continues. Every criterion below rolls up to that single test. If a vendor cannot answer the question "what happens, automatically, in the first minute after one of our infusion pumps starts behaving like an attacker," then whatever else they do well, they have not solved your real problem.

We say this as a vendor in the category, not despite being one. We would rather a hospital buy the right capability from anyone than buy a dashboard from us or from a competitor and discover its limits during an incident. So here is the checklist we would use if we were sitting in your chair.

1. Agentless coverage is non-negotiable

The first filter removes most of the confusion. Ask directly: can you protect a device that cannot have any software installed on it. Endpoint detection and antivirus both require an agent on the device, and research has found that while roughly half of IoMT devices run a version of Windows, only about 10% carry active anti-malware protection. The rest are structurally invisible to agent-based tools. A medical device security company that leans on endpoint agents is, by definition, blind to the majority of your device fleet.

What you want instead is protection enforced at the network layer, where no device cooperation is required. That is the only approach that covers an unpatchable imaging system or a decade-old pump as well as it covers a modern workstation. Treat agentless, network-level enforcement as a pass/fail gate, not a nice-to-have.

2. Discovery and classification accuracy

You cannot protect what you cannot see, so discovery is table stakes, but accuracy varies enormously. A good vendor finds every connected device, including the unmanaged ones that never made it onto a spreadsheet, and classifies them correctly: this is a ventilator, that is a CT controller, this one is a building-management sensor that has no business talking to the clinical network. Poor classification produces noise, and noise is how real signals get missed.

Push on the edges during evaluation. Ask how the vendor handles a device it has never seen before, how it avoids misclassifying a critical device as benign, and how often its library is updated. Discovery that is 95% accurate sounds impressive until you remember that the missing 5% in a large hospital is hundreds of devices, and an attacker only needs one.

3. Does it only report risk, or actually contain a threat?

This is the criterion that separates the category. A large share of medical device security products are, at their core, visibility and risk-scoring tools. They discover devices, flag vulnerabilities, and hand your team a prioritized list. That is genuinely useful for reducing exposure over time. It does nothing in the moment an attack is underway, because a list is not a response.

Ask every vendor to demonstrate what happens automatically when a device is confirmed compromised, in real time, with no human in the loop yet. If the answer is a higher-priority alert, you are buying a reporting tool. If the answer is an action that isolates the device and cuts off the attacker, you are buying protection. The 2017 WannaCry outbreak, which disrupted the NHS and spread partly through networked and connected equipment, and the 2024 attacks across the UK and US that forced hospitals onto paper, all shared the same lesson: the organizations that limited the damage were the ones that could contain spread quickly, not the ones with the best after-the-fact reports.

4. Is containment safe for patient care?

Here is the subtle trap. Containment that is not care-aware can be as dangerous as the attack. If a vendor's idea of containing a compromised device is to shut it down or kill its network entirely, and that device is a monitor attached to a patient or a pump mid-infusion, you have turned a security event into a patient-safety event. A medical device security company that understands healthcare quarantines a device at the network layer, cutting the attacker's access while the device stays powered and clinically functional, and it holds any action that could affect care for one-click human approval.

This is a question you must ask explicitly, because it rarely comes up in a standard demo. "When you contain a compromised infusion pump, does the pump stop infusing?" The right answer is no. The containment should isolate the threat, not the patient.

5. Recovery that does not depend on paying a ransom

Prevention and containment reduce the odds, but you have to plan for the attack that gets through. The question for a buyer is what recovery looks like, and specifically whether it depends on backups an attacker cannot have reached. Modern ransomware groups delete or encrypt ordinary backups first, precisely so the victim's only path back is to pay. A serious vendor keeps recovery independent of the production environment, using verified, immutable, air-gapped copies, and restores systems in clinical priority order rather than all at once.

Change Healthcare's 2024 attack, which disrupted care and billing across the US healthcare system and exposed data on an estimated 190 million-plus people, and the reported ransom paid in its aftermath, is the cautionary tale. Recovery capability is what removes the leverage that makes paying a ransom feel like the only option. Ask any medical device security company how a hospital gets back to normal if an attack succeeds, and whether that answer involves negotiating with the attacker.

6. Deployment and data residency

Finally, match the deployment model to your regulatory reality. A US hospital has HIPAA obligations; a UK trust answers to the NHS Data Security and Protection Toolkit and UK GDPR; a Gulf provider faces in-country data-residency rules under frameworks like ADHICS or the Saudi NCA controls. A medical device security company that can only run as a cloud service, routing device and patient telemetry offshore, may simply be a non-starter for you regardless of how good its detection is.

Ask whether the product can run on-premises, including its analysis engine, and whether an air-gapped deployment is possible. The ability to keep sensitive data inside your own environment is not a luxury feature, it is often a compliance requirement, and it should be settled early rather than discovered late.

Questions to bring to every demo

Reduce the whole evaluation to a short list you can put in front of any vendor. If a medical device security company answers these cleanly, it belongs on your shortlist. If it deflects, you have learned something important.

• Show me what happens automatically in the first 60 seconds after a device is confirmed compromised.
• When you contain a device attached to a patient, does the device keep working?
• How do we recover if an attack succeeds, and does that plan ever involve paying a ransom?
• Can this run entirely on-premises, with no patient or device data leaving our environment?
• What percentage of our device types can you protect without installing anything on the device?
• Do you only report risk, or do you take action during an active attack?

Where we fit

We built Immune around the half of the problem the category tends to skip. We protect connected medical devices agentlessly at the network boundary, contain a confirmed threat in seconds with care-impacting actions gated for one-click approval, and self-heal critical systems from immutable, air-gapped backups so recovery never depends on paying. It runs on-premises when data residency demands it. For the full technical picture, see our medical device security guide, and if you want to see the containment and recovery steps live rather than read about them, request a demo.

Whatever you choose, choose on the real test. A medical device security company earns its place not by showing you the cleanest risk dashboard, but by proving it can keep a device-heavy hospital running through an attack. Make every vendor prove it.