5 Network Segmentation Strategies for Healthcare IT

One flat hospital network can turn one hacked device into a system-wide problem. In healthcare, that can put ePHI, clinical apps, medical devices, and patient care at risk.

Here’s the short version: I’d focus on five moves to cut lateral movement and tighten access:

• Split EHR and clinical apps by function so web, app, and database systems don’t sit together
• Place medical devices in separate zones based on risk and use
• Use microsegmentation to limit device-to-device and workload-to-workload traffic
• Add Zero Trust checks for users, devices, and service accounts
• Validate rules on a set schedule so policies match actual traffic

The urgency is clear. In the first half of 2025, large healthcare breaches reported to HHS affected nearly 30 million people. And in 2024, the average healthcare breach cost hit $10.93 million. That’s why segmentation is no longer just an IT project; it is a critical component of managing enterprise risk. It helps limit spread, protect care systems, and support HIPAA control requirements.

Quick Comparison

If you want a simple takeaway, it’s this: block by default, allow only what care delivery needs, and test those rules often.

sbb-itb-535baee

Why Network Segmentation Matters in Healthcare

U.S. hospitals run legacy EHRs, cloud-connected clinical apps, medical devices, and vendor links around the clock. That mix is hard enough to manage on its own. In a flat network, it gets riskier fast, because one breach can move across the environment with few internal roadblocks.

The numbers make that clear. Healthcare data breaches cost an average of $10.93 million per incident in 2024, the highest of any industry ^[4]. Lateral movement shows up in over 70% of successful healthcare breaches, and attackers can remain hidden for months before anyone spots them ^[4].

Legacy medical devices add another weak spot. Infusion pumps, ventilators, and patient monitors often run outdated software that can't support modern security agents or frequent patching. On an unsegmented network, those devices sit exposed to the rest of the environment. Hospitals also give remote access to biomedical engineers, third-party vendors, and managed service providers. Without segmentation, those connections can turn into paths into the broader internal network. Segmentation limits that traffic and helps shield devices that can't protect themselves.

The rules are shifting too. In January 2025, HHS proposed updates to the HIPAA Security Rule that would move network segmentation from an "addressable" specification to a mandatory requirement ^[6]. The estimated first-year cost of compliance across the U.S. healthcare sector is about $9.3 billion ^[6].

That's why the first priority is to separate clinical applications and EHR environments based on sensitivity and function.

1. Segment Clinical Applications and EHR Environments by Sensitivity and Function

Many EHR environments run across connected tiers: a web-facing layer, an application layer, and a database layer. Each tier should sit in its own security zone, using VLANs or VRFs, with stateful internal firewalls set to default-deny between zones. Start with the EHR areas that matter most: web, application, database, analytics, and dev/test.

Ransomware Blast-Radius Reduction

When you separate tiers with policy enforcement points, ransomware that lands in the web tier can't just wander into the database tier. It has to cross a firewall first, and that firewall blocks traffic unless it's allowed. As NHS Digital puts it:

"A properly segmented network will improve network security by limiting the 'blast radius' of any cyber-attack." - NHS Digital ^[1]

That kind of containment can be the difference between a network-wide outage and a much smaller incident.

Protection of ePHI and Clinical Workflows

Block internet egress from any segment that stores or processes ePHI. Send vendor updates and remote support through MFA-protected jump hosts or controlled proxies instead. Keep APIs and analytics in separate segments, and apply identity-based layer-7 rules so access stays tight and traceable.

Control of East-West and Vendor Traffic

A simple tier model looks like this:

Use mTLS on sensitive service-to-service links to encrypt traffic and confirm service identity.

Auditability and HIPAA-Aligned Governance

Segmentation also makes auditing much easier. Log every allowed and blocked flow to support HIPAA audits and incident reviews. Manage segmentation rules as versioned, peer-reviewed policy-as-code so changes don't happen in the dark.

Apply the same default-deny model even more strictly to connected medical devices and healthcare IoT.

2. Create Dedicated Medical Device and IoMT Zones

After you separate EHR tiers, the next job is to isolate the devices that feed them. Medical devices should sit in dedicated zones based on clinical risk and function. That means keeping life-sustaining equipment, imaging, monitoring, and lab/pharmacy systems apart from general IT, building IoT like CCTV and alarms, and OT systems like HVAC and water pumps.

This matters because not all devices carry the same risk. A bedside monitor, an MRI scanner, and a water pump do very different jobs. Treating them as one flat network is asking for trouble.

Ransomware Blast-Radius Reduction

Separate device zones help trap ransomware inside one device class instead of letting it spread into life-sustaining equipment or lab systems. In plain English: if one area gets hit, the boundary helps keep the damage from jumping into other clinical systems.

Protection of ePHI and Clinical Workflows

Many connected medical devices, or IoMT devices, send patient data across clinical data paths. You see this in a few common flows:

• DICOM images from CT and MRI scanners to PACS
• HL7 or FHIR messages from bedside monitors to interface engines
• Vitals from patient monitoring systems to the EHR

Those paths should be explicitly allowlisted, not left open by default.

Before writing rules, map device traffic with passive discovery tools such as NetFlow or SPAN. That step gives you a clear picture of what each device needs to talk to. Avoid active scans on fragile legacy equipment, because they can crash it.

Control of East-West and Vendor Traffic

The table below shows the core zone categories and their primary controls:

Block direct inbound access to patient-care VLANs. For third-party support, end access at a hospital-controlled jump host inside a dedicated vendor zone. Require MFA. Record every session. No side doors, no direct hops into patient-care networks.

Auditability and HIPAA-Aligned Governance

Document every allowed medical-device flow by clinical justification, not just by port number. That distinction matters. "TCP 2575" says little on its own; "bedside monitor sends HL7 data to the interface engine for charting" tells you what the traffic is for and why it exists.

Log all allowed and blocked traffic from device zones, then review those logs on a set schedule. That gives teams a trail for audits and incident response, showing which IoMT flows were allowed and why. It also supports device-specific HIPAA Security Rule alignment ^[3][5].

Once the zones are set, microsegmentation can tighten traffic inside each one.

3. Use Microsegmentation to Contain Lateral Movement

Dedicated zones separate device classes, but microsegmentation goes one step further. Instead of stopping at network zones, it puts control around individual workloads, applications, and devices. Each asset gets its own policy-bound micro-perimeter. Think of it as the next containment layer inside each zone.

This matters most for east-west traffic moving between clinical, administrative, and IoMT systems. That’s the path attackers tend to use after they get in.

Ransomware Blast-Radius Reduction

Microsegmentation cuts lateral movement risk in a direct way. If each asset can talk only to approved destinations, a compromised workstation can’t jump to an EHR database, a backup server, or a pharmacy system. The infection stays boxed into the segment where it began.

The other half is fast quarantine. If your segmentation platform ties into NAC or EDR tools, it can automatically move a flagged device into an isolated quarantine VLAN within minutes, without disrupting other clinical systems.

Protection of ePHI and Clinical Workflows

Each asset should connect only to the clinical services it needs:

Before you enforce any of these policies, run them in monitor-only mode first. That gives you time to check real clinical traffic patterns and spot legitimate flows you may have missed, without putting patient care at risk.

Control of East-West and Vendor Traffic

Microsegmentation can also lock vendor access to one approved application or device segment, with no route into nearby systems. That way, a vendor session stays in its lane instead of becoming a path into the rest of the environment.

Auditability and HIPAA-Aligned Governance

Microsegmentation also gives you granular logs for every allow and deny decision tied to east-west traffic. That helps with HIPAA audits and forensic investigations. Granular allow/deny logs support audits and forensic review.

Treat segmentation policies like versioned code, and retire unused rules on a fixed schedule. That policy layer also supports Zero Trust enforcement.

4. Align Segmentation with Zero Trust Architecture Principles

Microsegmentation sets the borders. Zero Trust decides who gets through them.

VLANs and firewalls help, but they only get you so far. Zero Trust adds identity- and context-based checks to each request. In plain English: access isn't based only on where traffic comes from. It also depends on who is asking, what device they're using, and whether that request makes sense right now. That's why identity and device trust become the next control layer.

Ransomware Blast-Radius Reduction

Broad VPN access often drops users into a flat subnet. Once that happens, one stolen credential can open the door to the whole network.^[5]

ZTNA fixes that problem by brokering access to specific apps instead of the full network. So instead of letting someone "onto the network", it lets them reach only what they need. That small shift matters a lot.

Identity-based rules should allow the EHR app tier to reach the database only through mTLS and an approved service account. That way, if a credential is stolen, the damage stays boxed into one narrow segment instead of spreading across the environment.^[3][5]

Protection of ePHI and Clinical Workflows

Zero Trust requires continuous verification for every access request. Each decision is checked against user identity, device health, location, and behavior.

This matters during live clinical work, not just in policy docs. If a device slips out of compliance mid-session - for example, if an EDR agent spots suspicious behavior - access can be tightened or cut off on the spot, without waiting for a person to step in.

Control of East-West and Vendor Traffic

The same approach should apply to third-party access. Vendor sessions shouldn't get broad standing access. They should go through brokered, time-bound access on hardened jump hosts, with MFA, session recording, and just-in-time (JIT) credentials for any privileged maintenance work.

Host-based controls can apply these same rules at the workload level. That's especially useful when you're trying to lock down EHR application tiers and databases, where east-west traffic can otherwise move quietly from system to system.

Auditability and HIPAA-Aligned Governance

Zero Trust creates a detailed audit trail for each access decision, whether the request is allowed or blocked. That gives you proof that access controls are working in practice, not just on paper.

Those logs are tied to specific identities, devices, and sessions. For HIPAA, that kind of recordkeeping helps show how access was controlled and when it changed. It also gives security and compliance teams something concrete to work from during an audit or an incident review.

5. Build Policy-Driven Segmentation with Continuous Validation

Zero Trust decides who gets in. Policy-driven segmentation decides what they can touch after that. Continuous validation is the part that makes those rules hold up in day-to-day use.

Segmentation only works when the rules match actual traffic. Start with a full asset inventory, then sort assets by clinical role, sensitivity, and criticality. Put extra focus on clinical systems, IoMT, and vendor connections. You can only segment what you’ve already inventoried.

Once the asset map is current, turn it into explicit allowlists. Write down each required workflow by source, destination, protocol, port, and business reason. That documented set of flows becomes the allowlist. Everything else should be blocked by default.

Ransomware Blast-Radius Reduction

Use default-deny rules between zones and allow only verified flows, like port 5432 for an EHR database or DICOM for a PACS system. Before you enforce new rules, run them in monitor-only mode for 30 to 90 days with NetFlow or sFlow so you can see how systems actually talk to each other. Unmapped administrator paths give attackers room to move laterally across the network. ^[1]

Protection of ePHI and Clinical Workflows

For fragile devices, start with passive discovery. Then move to enforcement only after the system owner signs off. It also helps to set up break-glass paths in advance for emergency access. Those paths should be time-bounded and watched closely. ^[7]

Control of East-West and Vendor Traffic

Block internet egress from clinical segments. Send vendor updates and remote support through controlled proxies that require MFA. Tie vendor access to a BAA, and recertify that access every quarter. Treat segmentation rules like versioned policy that gets peer reviewed. ^[3]

Auditability and HIPAA-Aligned Governance

Log every allowed and denied flow, across both east-west and north-south traffic, and send those logs to a SIEM. Build dashboards that show policy drift and stale exceptions. Then test the controls on purpose by trying unauthorized connections from corporate or guest networks into PHI subnets. If those attempts still get through, the policy looks good on paper but fails where it counts. ^[5]

Proposed HIPAA Security Rule updates from early 2025 suggest network segmentation may soon become a prescriptive requirement for all covered entities. ^[2]

The table below shows the validation cadence that keeps those rules current.

Quick-Reference Tables for Security and Compliance Planning

Use these tables for a fast side-by-side view of the five strategies before you get into rollout.

The first table compares three network setups - flat network, zone-based segmentation, and microsegmentation - across the areas that matter most during a healthcare breach.

The next table links each strategy to its main goal, the controls behind it, and the governance angle teams need to track.

Auditors expect configs, flow justifications, and verification records - not diagrams alone ^[5]. Use the summary above to pick controls, log exceptions, and back up the final segmentation policy.

Conclusion

These five controls work best as a layered defense. They cut exposure, limit attacks, and help protect care delivery.

The risk is still high. That’s why segmentation has to stay up to date as networks, devices, and vendors change. In clinical settings, that balance matters a lot - the best segmentation programs stop attacks from spreading without getting in the way of critical care.

As cybersecurity benchmarks and HIPAA expectations get stricter, organizations need segmentation programs that are mapped, tested, and checked on a continuous basis. Censinet RiskOps™ helps healthcare organizations handle the continuous risk, policy, and validation work that segmentation calls for.

FAQs

Where should a hospital start with network segmentation?

Start with a full discovery process to find and inventory every device on the network. Then map data flows so you can see which systems handle ePHI, and profile communication patterns to separate clinical traffic from non-clinical traffic.

Before you put tight controls in place, use visibility tools in observe mode to set a baseline for normal activity. That gives you a clear picture of how the network behaves day to day, so segmentation is based on actual risk profiles without disrupting critical operations.

How can segmentation protect legacy medical devices?

Network segmentation helps protect legacy medical devices by putting them in secure, restricted zones. That separation keeps old systems from turning into easy entry points for lateral movement inside the network.

Teams can use VLANs, VRFs, or micro-perimeters to lock this down with default-deny policies. In plain English, that means traffic is blocked unless it's clearly allowed. The result is simple: only needed clinical traffic gets through, unauthorized communication drops, and any breach is more likely to stay contained.

How often should segmentation rules be reviewed?

Segmentation rules need regular review as environments change. Teams should also recertify access at least quarterly so they can remove unused accounts, keys, and tunnels before they linger longer than they should.

Periodic testing, including penetration tests and red-team exercises, helps confirm that segments are still secure. It’s also smart to document changes and keep governance tight, because good records make it much easier to spot drift and keep controls in place.

Related Blog Posts

• How Network Segmentation Secures Medical Devices
• Network Segmentation for HIPAA Compliance
• IoT Network Segmentation for Healthcare Devices
• Ultimate Guide to Network Segmentation in Healthcare