Hospital microsegmentation is only real when tested under outage

At a glance

What this is: This case study shows how Main Line Health used chaos engineering to prove its microsegmentation controls under real outage conditions and uncover hidden resilience gaps.

Why it matters: It matters because identity-aware segmentation only reduces blast radius when the policy model, device classification, and clinical fallback processes actually hold under stress.

By the numbers:

• Main Line Health operates five hospitals, eight large ambulatory sites, and roughly 160 clinical practices across five counties.

👉 Read Elisity's case study on Main Line Health's chaos engineering segmentation tests

Context

Microsegmentation is a control problem before it is a tooling problem. In healthcare, flat clinical networks are designed for availability, but that same connectivity can create lateral movement paths across biomedical devices, endpoints, and administrative systems. Main Line Health treated that tension as a resilience question and tested whether its segmentation model could survive real disruption, not just a tabletop exercise.

The identity connection is practical rather than abstract: segmentation works best when device classes, communication paths, and allowed relationships are known well enough to enforce policy without breaking care delivery. That makes this a useful case for IAM and PAM teams working alongside network, cloud, and operational resilience programmes, because the blast radius problem is the same even when the assets are medical devices rather than human accounts.

Key questions

Q: What breaks when microsegmentation is not tested under real outage conditions?

A: Policies can look correct on paper while hiding workflow failures, reconnect problems, and unsupported clinical dependencies. Without controlled failure testing, teams often discover that their recovery assumptions, not just their network rules, are wrong. That leaves the organisation exposed to outages that can spread operationally even when the segmentation design seems sound.

Q: Why do flat networks increase risk in hospitals and other operational environments?

A: Flat networks let devices and systems communicate broadly by default, which makes lateral movement easier after one compromise. In a hospital, that can turn a single biomedical device or endpoint into a pivot toward other clinical or operational assets. The risk is not only breach propagation, but also disruption of patient care and recovery processes.

Q: How do security teams know if microsegmentation is actually working?

A: They should measure whether allowed traffic matches real operational needs, whether blocked communication stays blocked during failure, and whether recovery processes still function under stress. If devices reconnect unpredictably, or if teams cannot complete paper-based fallback workflows, the programme has not yet proven its resilience value.

Q: Who is accountable when segmentation disrupts clinical or business operations?

A: Accountability sits jointly with security, infrastructure, and the operational owners who define normal behaviour. In regulated environments, that also extends to leadership that approved the risk posture and the recovery model. Segmentation is only defensible when the business can show it validated both the control and the fallback path.

Technical breakdown

Why flat clinical networks create lateral movement risk

Healthcare environments often inherit flat networks because care delivery has to stay simple and fast. The problem is that biomedical devices, printers, imaging systems, and endpoints all become reachable from the same trust zone, which means a compromised device can be used as a pivot. Microsegmentation reduces that path by controlling which device classes may talk to each other, rather than assuming the network boundary is enough. In practice, this turns unknown east-west traffic into a governance problem that can be modelled, tested, and restricted.

Practical implication: classify clinical assets and define allowed communication paths before enforcing segmentation.

How chaos engineering validates microsegmentation policy

Chaos engineering deliberately breaks controlled parts of the environment to see whether systems fail safely. In this case, the hospital used rolling outages to test whether segmented traffic, device reconnect behaviour, and analog fallback processes matched the policy model. That matters because a segmentation rule is only as good as its behaviour under interruption. If a device flaps, reconnects incorrectly, or fails to resume a clinical workflow, the policy has not really been validated. Testing reveals whether the model reflects reality or just documentation.

Practical implication: run controlled outage tests to verify that segmentation rules and recovery workflows behave as designed.

Why resilience testing exposes hidden operational dependencies

Resilience exercises often surface failures that security programmes did not set out to find. Here, the outage testing revealed emergency red phones that did not work and aging infrastructure that had not been restarted in years. That is a useful reminder that microsegmentation sits inside a wider continuity system. If fallback communications, manual charting, and hardware hygiene are weak, segmentation can look successful while the broader recovery capability remains fragile. Testing should therefore cover both the security control and the operational substitutes that carry the business through disruption.

Practical implication: include analogue fallback systems and infrastructure hygiene in every segmentation validation exercise.

Threat narrative

Attacker objective: The attacker objective is to expand a single compromised device into broader reach across clinical and operational systems without triggering containment.

1. Entry begins when a compromised biomedical or endpoint device is assumed to exist on a flat clinical network with broad east-west reach.
2. Escalation occurs when that device can communicate laterally to adjacent systems that were never meant to trust one another.
3. Impact follows when an attacker can move from one clinical foothold toward higher-value systems, increasing the potential blast radius across care delivery.

NHI Mgmt Group analysis

Chaos engineering is becoming a governance test for resilience, not a niche reliability exercise. Main Line Health’s approach shows that a segmentation design cannot be treated as proven until it survives intentional failure. That shifts the control conversation from documentation to behavioural evidence, which is exactly where modern security governance should be heading. Practitioners should treat outage testing as the moment policy becomes operational truth.

Microsegmentation in healthcare is really a blast-radius governance problem. The article shows that the real objective is not simply reducing connectivity, but proving that a compromised device cannot move widely enough to endanger care. That framing is useful beyond hospitals because it translates well to any environment where many devices, services, or workloads share implicit trust. Practitioners should measure segmentation by containment, not just by policy count.

Clinical resilience depends on identity-like classification of devices and services. The hospital had to distinguish between device types, communication patterns, and acceptable peer relationships before enforcement could be trusted. That is an identity governance pattern applied to machines: know the subject, define its allowed actions, and verify that the resulting policy reflects actual use. Practitioners should see this as a bridge between device governance and broader identity security.

Operational fallback debt: hidden dependencies like red phones and aging hardware are part of the security perimeter. The testing exposed gaps that had nothing to do with segmentation logic and everything to do with whether the organisation could function when digital systems failed. That makes resilience programmes stronger when they treat backup communications, manual workflows, and asset hygiene as first-class control inputs. Practitioners should validate the whole recovery chain, not just the firewall model.

Clinical collaboration is the control that makes segmentation enforceable. Security teams cannot safely segment high-stakes environments by policy design alone because they need clinicians to confirm what normal traffic actually looks like. That makes microsegmentation a socio-technical governance problem, not just an engineering one. Practitioners should build shared review loops with operational owners before turning policy into enforcement.

What this signals

Blast-radius testing should become a standard part of resilience programmes wherever many devices, services, or workloads share a trust zone. The lesson from this case is not that outages are useful in themselves, but that controlled failure reveals whether policy, fallback, and ownership really line up. For teams working on device governance, the next step is to treat recovery validation as a control, not an afterthought.

This kind of programme will increasingly influence board-level risk reporting because it produces evidence, not assertion. Security teams that can demonstrate segmented communication paths, tested fallback workflows, and operationally meaningful device classification will be better positioned to explain containment and continuity decisions. For identity and access leaders, the analogous challenge is proving that privileges and relationships are bounded in practice, not just in documentation.

The broader signal is that resilience, identity, and operational technology governance are converging around one question: how far can failure travel before it is contained? That question now applies to device access, service relationships, and backup processes alike. Teams that can answer it with test data will have a stronger case for investment than teams relying on design intent alone.

For practitioners

• Map device relationships before enforcement Build an explicit inventory of biomedical devices, printers, imaging systems, and support endpoints, then document which peers each class truly needs to reach. Use that relationship model to separate legitimate clinical traffic from anomalous cross-talk before any deny policy is activated.
• Test segmentation with controlled outage windows Schedule rolling disruption exercises that force reconnects, validate paper-based workflows, and prove that devices recover cleanly under failure. Keep the test windows long enough to reveal behaviour but short enough to protect patient care.
• Treat analogue fallback systems as security controls Verify emergency phones, manual charting, and other non-digital recovery paths with the same discipline used for network policy. If the fallback chain fails, the segmentation programme is not resilient, even if the technical policy is correct.
• Classify assets at the level operations actually use Replace generic labels with operationally meaningful classes such as specific printer types, modality systems, and unit-level device groups. Granular classification makes it possible to shrink the blast radius and defend policy decisions during audit or incident review.
• Bring clinical owners into policy validation early Walk clinicians through expected communication patterns before enforcing deny rules and adjust models where the real workflow differs from the design. That early review reduces anxiety and prevents segmentation from breaking care delivery.

Key takeaways

• Main Line Health treated microsegmentation as a resilience capability that had to survive intentional failure, not a policy that could be trusted on first deployment.
• The exercise exposed hidden operational weaknesses, including non-working emergency phones, showing that security validation often surfaces continuity gaps as well as control gaps.
• For practitioners, the practical goal is smaller blast radius, verified fallback, and segmentation evidence that holds up under stress.

Key terms

• Microsegmentation: Microsegmentation is the practice of dividing a network or environment into smaller policy zones so only specifically allowed communications can occur. It reduces lateral movement by replacing broad trust with tightly defined device or workload relationships, which makes a compromise easier to contain and investigate.
• Chaos Engineering: Chaos engineering is the deliberate introduction of controlled failure conditions to test how systems behave under stress. In security and resilience work, it helps prove whether policies, workflows, and fallback processes actually operate as intended when parts of the environment are disrupted.
• Blast Radius: Blast radius is the amount of damage a compromise, outage, or misconfiguration can spread across an environment. Security teams use it as a containment measure, asking how far a failure can travel before controls, segmentation, or operational safeguards stop it.
• Medical Internet of Things: Medical Internet of Things refers to connected clinical devices such as imaging systems, infusion pumps, and monitoring equipment that operate as networked computers. These assets can improve care delivery, but they also create lateral movement paths and governance challenges if communication is not tightly controlled.

What's in the full article

Elisity's full post covers the operational detail this post intentionally leaves for the source:

• A step-by-step walkthrough of the three-phase chaos engineering approach used to validate segmentation across clinical environments.
• The exact sequencing of tiered rollout decisions across physician practices, mental health facilities, and acute care hospitals.
• Examples of how the team modeled device behaviour before turning on enforcement, including what counted as a safe deny candidate.
• The board, compliance, and insurance reporting implications of proving segmentation with live outage tests.

👉 The full Elisity post includes the rollout model, outage validation method, and clinical collaboration details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity control principles into stronger operational governance across complex security programmes.