HEALTHCARE MICROSEGMENTATION

How Do You Secure IoMT and Medical Devices Without Installing Agents?

Infusion pumps, MRI scanners, patient monitors: the devices hospitals depend on most are the ones that cannot run an endpoint agent. This guide explains agentless IoMT security by device type, and shows how discovery data from Armis or Claroty Medigate becomes enforceable segmentation policy. It is one chapter of our healthcare microsegmentation guide.

Quick Answer

Hospitals secure IoMT and medical devices without installing agents by classifying every device by identity and enforcing least-privilege segmentation policy through the network hardware they already own. Agentless microsegmentation is a device-security control and a segmentation architecture at once. St. Luke’s University Health Network deployed identity-based microsegmentation across 15 hospitals and roughly 85,000 production devices in about 46 days.[1]

TL;DR

  • Agentless microsegmentation protects medical devices by enforcing identity-based policy through the network hardware a hospital already owns, on any data plane, with nothing installed on the device.
  • St. Luke’s University Health Network deployed identity-based microsegmentation across 15 hospitals and roughly 85,000 production devices in about 46 days.[1]
  • 59% of healthcare respondents cite patient monitoring systems as the devices presenting the greatest segmentation challenges, followed by IoMT devices at 55% (Omdia, N=176).[2]
  • NIST’s SP 1800-8 practice guide covers wireless infusion pumps only; the device table in this guide extends segmentation constraints and approaches to MRI, CT, patient monitors, and lab analyzers.[3]
  • Most of the market pairs agentless discovery with agent-based or NAC enforcement. Agentless enforcement is the difference, and it is what makes unpatchable clinical devices protectable.

How do you protect IoMT devices in a healthcare environment without installing agents?

You protect IoMT devices without agents by moving the security control off the device and into the network. Agentless microsegmentation discovers and classifies every device by identity, then enforces least-privilege policy through existing network hardware. The device runs nothing new, the clinical workflow never pauses, and segmentation reaches equipment that endpoint tools cannot touch.

Two phrases describe this control, and the industry treats them as different categories. “Agentless device security” names what gets protected: the pump, the scanner, the monitor at the bedside. “Agentless segmentation” names how the protection works: identity-based policy deciding which conversations each device may have. They are the same control seen from two angles. Hospitals that treat them as separate purchases tend to buy discovery twice and enforcement never.

Watch how the market uses the word agentless and a pattern shows up. Discovery is agentless almost everywhere now. Enforcement usually is not. The moment a product needs to block traffic, it reaches for an endpoint agent or an 802.1X supplicant, which is precisely what an infusion pump or a ten-year-old imaging workstation cannot provide. Identity-based microsegmentation closes that gap by enforcing policy through existing switching infrastructure and wireless hardware, over any data plane. That is the approach behind the St. Luke’s University Health Network deployment, finished two weeks ahead of the commitment the health system had made.[1]

Diagram of agentless IoMT security: discovery data feeds identity-based policy enforced by existing network hardware
Agentless IoMT security pairs discovery data with identity-based segmentation policy enforced through the network hardware hospitals already own, so nothing installs on clinical devices.
Agentless, agent-based, and NAC enforcement for medical device security compared
Criterion Agentless enforcement Agent-based NAC (802.1X)
What installs on the device Nothing A software agent on every endpoint A supplicant, or a MAC exception per device
Unmanaged and legacy medical devices Covered; identity comes from the network Excluded; most clinical devices cannot host an agent Partial; exceptions accumulate and weaken the model
Clinical downtime and change windows None; policy is simulated before enforcement Reboots and maintenance windows per device Port-level changes with re-authentication and outage risk
Policy granularity Least privilege per device identity and clinical role Fine-grained, but only on devices that run the agent Coarse; VLAN or port level
Operational overhead Central policy; no endpoint lifecycle to manage Agent updates, compatibility testing, exception lists Certificate and exception management at scale

Aaron Weismann, who runs security at Main Line Health, puts the outcome in clinical terms:

“Elisity provides technical distancing between devices to stop the spread and progression of a cyberattack. For impacted toxic assets, it also lets us excise them with surgical precision to preserve safe and effective technology-supported care continuity.”

Aaron Weismann, CISO, Main Line Health[6]

How do I segment medical devices like MRI, CT, and infusion pumps?

Segment medical devices by clinical identity and function, not by VLAN or physical location. Each modality gets a policy group that defines exactly what it may talk to: an MRI suite needs PACS and vendor service paths, an infusion pump needs its drug library server, and little else. Simulate the policy against observed traffic first, then enforce it.

The struggle is not evenly distributed. 59% of healthcare respondents cite patient monitoring systems as the devices presenting the greatest segmentation challenges, followed by IoMT devices at 55% (Omdia, N=176).[2] Monitors sit in the worst spot: always on, always streaming to a central station, never available for the maintenance window a network redesign would demand.

Public guidance is thinner than the problem deserves. The strongest federal reference, NIST’s NCCoE practice guide SP 1800-8, covers exactly one device class, wireless infusion pumps, and was published in 2018.[3] Imaging, monitoring, and laboratory equipment are left as an exercise for the reader. The table below extends the same segmentation discipline across the five device types hospital security teams ask about most.

Segmentation constraints and agentless approaches by medical device type
Device type Segmentation constraint Agentless approach
MRI Vendor-managed systems; service contracts prohibit third-party software; imaging must not be interrupted One policy group per imaging suite; allow PACS, DICOM, and vendor remote-service paths only
CT Same vendor lock as MRI, plus emergency department availability around the clock Simulate policy against observed traffic; enforce at the access layer without touching the scanner
Infusion pumps Thousands of mobile units roaming on Wi-Fi; no agent or supplicant support Classify by device identity, not location; restrict to drug library and gateway servers
Patient monitors Continuous telemetry to central stations; any interruption is a patient safety event Keep telemetry paths explicit in policy; tighten everything else around them
Lab analyzers Legacy operating systems; middleware traffic patterns vendors rarely document Baseline observed flows, then permit LIS and middleware destinations only
Diagram mapping MRI, CT, infusion pumps, patient monitors, and lab analyzers to identity-based segmentation policy groups
Each medical device type carries its own segmentation constraint; identity-based policy groups apply least privilege per modality, from MRI suites to lab analyzers.

Regulators are moving in the same direction. HHS has proposed making network segmentation a required implementation specification in the HIPAA Security Rule NPRM published January 6, 2025, though the rule is not final and no compliance clock is running.[5] Policy groups like the ones above become the evidence trail an auditor reads. For the phased build, see our roadmap to HIPAA segmentation expectations for medical devices.

How do I secure legacy devices in healthcare?

Secure legacy devices in healthcare by wrapping enforcement around what cannot be patched. A legacy medical device usually cannot take an operating system upgrade, cannot run security software, and cannot be replaced without a capital request. Agentless segmentation accepts all three constraints: it learns each device’s identity from its behavior and restricts it to the flows its clinical role requires.

Regulation won’t close the gap for you. The FDA’s premarket cybersecurity guidance raised expectations for new device submissions, and it does nothing retroactive for equipment already installed.[4] A scanner cleared in 2014 answers to 2014 expectations for the rest of its service life, which in healthcare can mean another decade on the network. The compensating control has to live in the network, because it cannot live on the device.

You’re not working blind, either. Manufacturers publish MDS2 forms, security worksheets that state what each model supports, and those documents translate directly into policy inputs. Our guide to using MDS2 data for medical device segmentation walks through the translation. Pair the paperwork with observed traffic and the unpatchable device becomes one of the easiest things on the network to constrain, because its legitimate behavior is so narrow.

That is the quiet irony of the agentless story. The devices least able to defend themselves end up with the strongest protection, precisely because nobody has to touch them.

How do I turn Armis or Medigate device data into segmentation policy?

Treat Armis or Claroty Medigate as the source of device truth, then hand their classifications to an identity-based policy engine. The discovery platform answers what each device is. The segmentation platform decides what each device may do, and it enforces that decision through existing network hardware. The bridge between the two is an API integration, not a replacement project.

In practice the bridge has four steps:

  1. Sync device attributes. Type, model, clinical role, and risk score flow from the discovery platform into the policy engine.
  2. Map attributes to policy groups. An attribute such as “infusion pump” resolves to a policy group with a defined set of permitted destinations.
  3. Simulate. Run the policy against live traffic in monitor mode and review what would have been blocked before anything is.
  4. Enforce. Promote the policy to the switching infrastructure and wireless hardware, one site or department at a time.

Elisity ships this as a supported integration, documented in the Elisity Armis integration guide. The pattern holds up in production: Main Line Health earned a CIO 100 Award for 2025 for its cybersecurity implementation using the Armis and Elisity platforms.[7] The lesson is the argument of this whole page: discovery data becomes valuable the day something enforces on it.

For product specifics, the Elisity IoMT security platform page covers discovery, classification, and enforcement in clinical environments.

See identity-based microsegmentation in a clinical network

Walk through how hospitals discover, classify, and segment every device without agents or downtime.

Explore the healthcare solution

Frequently asked questions about IoMT security

What is IoMT security?

IoMT security is the practice of protecting the Internet of Medical Things: connected clinical devices such as infusion pumps, imaging systems, patient monitors, and lab analyzers. Because most of these devices cannot run endpoint software, IoMT security depends on device identity, network-level policy, and segmentation rather than agents installed on the equipment itself.

How do you secure medical devices that cannot run antivirus software?

Move the control into the network. A device that cannot run antivirus can still be discovered, classified by identity, and held to least-privilege policy that permits only the traffic its clinical role requires. Enforcement happens on the switching infrastructure and wireless hardware already in place, so nothing installs on the device and its validated configuration never changes.

What is the difference between agentless discovery and agentless enforcement?

Agentless discovery identifies and profiles devices without installing software, and most platforms now offer it. Agentless enforcement goes further: it applies segmentation policy through existing network hardware, so blocking a threat also requires nothing on the device. Many products remain agent-based or NAC-based at the enforcement step, which excludes exactly the medical devices that need protection most.

Does agentless microsegmentation require new network hardware?

No. Identity-based microsegmentation enforces policy through the network hardware a hospital already owns, wired or wireless, across any data plane. There are no inline appliances to rack, no re-cabling projects, and no forklift upgrade, which is how deployments stay out of the clinical change-window queue.

Does HIPAA require hospitals to segment medical devices?

Not as a finalized rule. HHS has proposed making network segmentation a required implementation specification for the HIPAA Security Rule, and that proposal has not been finalized, so no compliance deadline is in force today. Separately, the voluntary HHS 405(d) practices already recommend segmentation, and cyber insurers increasingly ask about it at renewal.

Can you isolate a compromised medical device without taking it offline?

Yes, when policy is identity-based. A device showing signs of compromise can have its policy tightened to sever lateral paths while the specific flows that keep it clinically safe stay open. Main Line Health describes this as excising impacted assets with surgical precision while care delivery continues.

Sources and citations

  1. Elisity, “Healthcare Microsegmentation at 15 Hospitals: The St. Luke’s Story from the Gartner Security and Risk Management Summit,” June 3, 2026. Source.
  2. Elisity, “Microsegmentation in Healthcare: Omdia Survey Findings,” reporting Omdia’s 2025 survey of 352 cybersecurity decision makers across healthcare and manufacturing, June 26, 2026. Source.
  3. NIST National Cybersecurity Center of Excellence, SP 1800-8, “Securing Wireless Infusion Pumps in Healthcare Delivery Organizations,” August 2018. Source.
  4. U.S. Food and Drug Administration, “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions,” final guidance, June 27, 2025. Source.
  5. U.S. Department of Health and Human Services, HIPAA Security Rule notice of proposed rulemaking, 90 FR 898, Federal Register, January 6, 2025. Source.
  6. Elisity, “Case Study: Main Line Health,” October 2024. Source.
  7. Elisity, “Main Line Health Secures CIO 100 Honors Through Deployment of the Elisity-Armis Integration,” April 23, 2025. Source.