How Should Hospitals Secure 85,000 Medical Devices With Microsegmentation?

What Medical Device Microsegmentation Actually Does

Medical device microsegmentation is a security method that limits which medical devices, clinical systems, and users can communicate with one another. Instead of placing thousands of devices on a shared internal network, a hospital defines policies that permit only required connections, such as an infusion pump reaching its monitoring server while blocking access to unrelated clinical applications. The practical objective is not simply better visibility; it is to reduce the number of paths an attacker or accidental misconfiguration can exploit. That distinction matters because a hospital may already own several security tools while still allowing an unmanaged device to reach far more systems than it needs.

Also worth reading: How does the FDA predetermined change control plan (PCCP) work for AI-enabled medical devices, and what are the compliance requirements? · How Should Hospitals Evaluate a Digital Twin Before Using It in Clinical Operations? · How Should Hospitals Integrate Infection Surveillance Software With EHRs in 2026?

The scale of the problem is illustrated by an Elisity deployment at St. Luke’s, which was reported to cover 85,000 medical devices and was completed in 46 days. This is a vendor-published case rather than an independent guarantee, but it offers a useful benchmark for what a well-scoped project can achieve. The same case associates the project with clinical innovation, suggesting that segmentation was treated as an enabler of controlled device access rather than only a defensive control. A separate HIMSS survey cited in the research context reported that 60% of health systems could not protect unmanaged medical devices, which helps explain why hospitals are moving from broad network controls toward device-specific policy enforcement.

Microsegmentation does not replace endpoint protection, firewalls, vulnerability management, patching, or clinical safety procedures. It adds a containment layer that can work even when a device cannot run a modern security agent. For Hygiea.tech’s audience, the relevant question is whether a hospital can connect this control layer with hygiene monitoring, compliance evidence, and safety-operations workflows without creating another dashboard that nobody owns. The answer depends on deployment scope, clinical ownership, and whether policies are maintained after the initial rollout.

How Microsegmentation Protects Connected Medical Devices

Most medical devices communicate through several layers: embedded firmware, an operating system or vendor-specific software, network protocols, management tools, and clinical applications. A policy engine can observe or define what each layer is permitted to reach, but it cannot assume that every device behaves like a corporate laptop. Many hospital devices are old, run with limited processing capacity, and may not support new agents. Network-based enforcement is therefore often more practical for this class of equipment, provided the solution understands device identity and application behavior rather than relying only on IP addresses.

A typical policy might allow a bedside monitor to send alerts to a specific clinical application, permit a clinician’s workstation to access the monitor’s required interface, and deny that workstation access to thousands of neighboring devices. Another policy might isolate a research infusion pump from production systems until security and biomedical engineering approve its move. These rules are valuable because they reduce lateral movement, shorten the time an exposed device can affect other assets, and make unauthorized communication easier to investigate. They also support clinical safety when a compromised device is prevented from interfering with unrelated equipment.

The technology is not automatically accurate or safe. Automated discovery can misclassify a device, a shared server may represent many clinical functions, and a badly written rule can interrupt care. A device that is discovered only as “printer” or “unknown IoT” is not useful for fine-grained policy design. Mature programs combine asset data, network-flow information, application dependencies, clinical context, and human validation from biomedical engineering, information security, networking, and care teams. The Armis Centrix integration described in the research context illustrates this direction: sharing asset intelligence can help an organization distinguish unmanaged medical equipment from ordinary IT assets before it writes enforcement rules.

The right mental model is controlled connectivity, not complete isolation. Hospitals rarely have the time to disconnect every legacy device, and clinical operations often depend on workflows that were never designed for strict least-privilege access. The target is a documented, monitored exception for every necessary relationship, with stronger controls around high-risk and internet-facing systems.

A Practical Six-Stage Implementation Plan

Begin with a bounded pilot rather than a promise to secure every connected asset in the first month. Select a representative clinical area, such as a single hospital unit with infusion pumps, bedside monitors, workstations, and a shared wireless network. Record the assets, owners, clinical functions, known maintenance constraints, and required communication paths. A pilot is useful only if it tests a meaningful part of the environment; a small office network with modern endpoints will not prove that legacy medical devices can be safely segmented.

Next, establish discovery and classification. Identify devices through passive network observation, switches, controllers, asset records, and vendor inventories, then validate the results with clinical and biomedical teams. Assign each device a role, risk tier, software state, and responsible owner. Track confidence levels as well as categories, because a “medical device” label without a function or owner is weak operational data. During this stage, avoid changing production access based solely on automated classification. Discovery should create evidence for policy design, not an unreviewed enforcement event.

The third stage is dependency mapping. Document the minimum connections needed for patient monitoring, alarms, device management, identity services, time synchronization, and clinical applications. Where a manufacturer supports only broad protocols or a shared server, record the exception and its compensating controls. Policies should initially be permissive enough to prevent disruption, while alerting teams when traffic falls outside the expected pattern. The fourth stage is limited enforcement, starting with low-risk, well-understood paths and expanding after observation periods and clinical sign-off.

The fifth stage is validation. Test normal operations, failure modes, vendor maintenance, wireless roaming, device replacement, and emergency workflows. A control that blocks urgent clinical access is not a successful security improvement. Track mean time to detect unusual device behavior, mean time to contain it, policy-change approval time, and the number of false positives. The sixth stage is lifecycle management: new devices should enter policy groups before clinical use, and retired devices should be removed promptly. A realistic program treats segmentation as an operating process with named owners and recurring reviews, not a one-time appliance installation.

Comparing the Main Deployment Options

There is no single “best” microsegmentation approach for healthcare. Network-based platforms are often attractive for hospitals with many unmanaged devices, while host-based controls provide deeper visibility where supported. Identity-aware tools can improve policy context, and manual firewall rules may be adequate for a small or highly stable environment. The following comparison uses general characteristics rather than vendor rankings or guaranteed product capabilities.

The comparison should inform a proof of concept, not a purchase by feature count. Ask vendors to demonstrate how their platform handles an actual hospital device population, including equipment without an agent, shared clinical servers, and manufacturer-specific protocols. Request evidence of rollback, policy simulation, maintenance-mode support, and integration with existing asset-management or security workflows. The St. Luke’s figure of 85,000 devices in 46 days is a useful question to ask vendors about scope, but it should not be treated as a universal implementation schedule.

Common Mistakes That Cause Clinical Disruption or Weak Security

The most damaging mistake is writing rules before the team understands how clinical care actually works. A device may communicate with a broader application set than expected because of alarms, time synchronization, printer workflows, or vendor maintenance. Blocking that path can create delays that appear in patient areas even when the underlying policy is technically correct. Biomedical engineering, nursing, the security team, and the application owner should review every high-impact rule. “The scanner says it is unused” is not a safe basis for disabling a clinical connection.

A second mistake is treating discovery accuracy as a solved problem. Asset inventories often contain stale records, duplicate addresses, and equipment that was added without formal onboarding. DHCP changes, mobile carts, third-party systems, and connected research equipment can all make an IP-based identity unreliable. Use confidence scoring, corroborate observations with multiple sources, and retain a process for resolving unknown devices. A platform that claims to classify 85,000 devices but cannot show why a device received a policy group gives the clinical and security teams limited assurance.

The third mistake is assuming microsegmentation is a substitute for basic cyber hygiene. Weak passwords, shared administrator accounts, unpatched servers, exposed remote-access services, and missing backups can still produce harm. Segmentation can contain some of these problems, but it cannot repair a compromised identity or restore a failed clinical system. Programs should track exposure age, unsupported software, privileged access, and backup coverage alongside network policy metrics. A lower lateral-movement score should not be presented as proof that the overall environment is safe.

The fourth mistake is measuring only the number of blocked connections. A high block count may mean that policies are working, or it may mean that discovery was wrong. Better measures include percentage of devices with validated owners, percentage of critical dependencies documented, time to revoke a departing user’s access, time to isolate a confirmed device, and percentage of policies tested after a clinical change. Keep exceptions visible and time-bounded; an emergency firewall rule should have an owner and expiry date rather than becoming permanent architecture.

When a Hospital Should Act, and When It Should Wait

A hospital should act when unmanaged medical devices can communicate broadly, when a vulnerability in one device could affect clinical systems, or when the organization cannot demonstrate which systems are exposed. Those conditions are common in heterogeneous clinical environments, but urgency should be assessed by patient-care impact and asset criticality. A connected infusion pump, patient monitor, imaging platform, or laboratory system deserves different treatment from a nonclinical building controller. Start with the assets whose compromise could affect diagnosis, treatment, privacy, or availability.

Timing also depends on organizational readiness. If device ownership is unknown, wireless and switch telemetry is incomplete, or emergency workflows have not been documented, a rapid enforcement deadline may be irresponsible. The organization can still make progress during preparation by improving inventories, separating production and research networks, reducing exposed remote access, and assigning owners. Waiting does not mean ignoring risk; it means choosing a deployment sequence that avoids preventable clinical disruption.

Several external conditions can justify moving sooner. A health system may be preparing for a compliance audit, consolidating facilities, onboarding a large medical device manufacturer, or responding to a security incident that exposed excessive lateral connectivity. Regulatory and customer pressure can accelerate procurement, but they should not eliminate technical validation. A 46-day deployment result should prompt a realistic question about scope and staffing, not an assumption that the same result will apply to every hospital.

Hygiene and safety-operations teams can contribute useful structure by tying segmentation exceptions to cleaning, maintenance, infection-control, and device-retirement procedures. A device that is removed from the network but remains in a patient room may still have safety and privacy obligations. Conversely, a segmentation platform can help identify unauthorized equipment that should enter a formal review process. The value comes from connecting cyber visibility with physical and clinical governance, not from presenting network alerts as safety incidents automatically.

Cost, Pricing, and Building a Defensible Business Case

Healthcare microsegmentation pricing is rarely a simple per-device figure. Vendors may charge according to protected devices, monitored interfaces, subnets, sites, workflows, or subscription tiers, while implementation costs include discovery, integration, policy design, testing, training, and ongoing support. Hospitals should ask for a three-year total-cost model that includes hardware, software, identity and asset-management integrations, network changes, and the internal labor required to maintain policies. Comparing only the first-year license can make a sophisticated platform appear more expensive than a manual project that later requires substantial staff time.

The business case should include avoided disruption, reduced investigation time, faster containment, and stronger audit evidence, while avoiding claims that segmentation prevents every incident. The research context cites legacy architecture and awareness gaps as barriers to healthcare adoption, so training and change management belong in the budget. A project that cannot assign policy owners may save money during rollout and consume it through stale rules and repeated exceptions. The St. Luke’s 46-day case is especially useful as a scope question: clarify whether the figure covered policy design, pilot testing, production enforcement, or only platform onboarding.

For Hygiea.tech and similar B2B healthcare technology providers, the best approach is to describe the operational connection rather than hard-sell a security product. Microsegmentation can supply trusted asset and connection data that supports hygiene compliance, device lifecycle governance, and risk-based maintenance workflows. The offering should remain credible by acknowledging that network controls do not determine whether a device is clean, properly maintained, or clinically safe. A useful evaluation combines technical signals with human ownership, documented procedures, and measurable service-level targets.

As of 25 September 2026, a reasonable target is not full isolation on an arbitrary date. It is a documented coverage plan, validated critical-device ownership, tested containment, and a sustainable review cadence. If a hospital can move from “we do not know what can reach our clinical systems” to “we can show and test the necessary paths,” the project has delivered practical risk reduction even if legacy exceptions remain.