Network segmentation for ePHI means splitting your practice network into separate zones so that systems holding patient data cannot be reached from every other device on the wire. In a segmented design, the electronic health record server, the imaging modalities, the front-desk workstations, and the waiting-room wifi each live on their own VLAN with firewall rules governing what may cross between them. That architecture does two things at once. It stops an attacker who lands on a receptionist’s laptop from walking straight into the EHR database, and it narrows the set of systems an auditor has to review when you demonstrate access control under the HIPAA Security Rule. Most small practices we assess have none of it.
The 5 Things Every Practice Should Know Before Segmenting
Our team works with medical, dental, and behavioral health practices in the 10 to 100 employee range, and the same five points come up on nearly every engagement.
- A flat network makes every device an entry point to ePHI. If the smart TV in the waiting room and the EHR server share a subnet, the TV is in scope.
- Segmentation is an architecture project, not a product purchase. No appliance segments your network for you. Somebody has to decide which zones exist and what traffic is allowed between them.
- Medical devices are the hardest zone and the one you cannot skip. Imaging modalities and infusion pumps often run unpatchable operating systems, which is precisely why they belong behind their own boundary.
- Segmentation shrinks audit scope, which is the budget argument that lands. Fewer systems in the ePHI zone means fewer systems to document, log, and defend.
- Order of operations matters more than technology choice. Inventory first, zone design second, cutover by department third. Practices that start by buying switches stall out.
Why Network Segmentation for ePHI Starts With the Flat Network Problem
A flat network is one where every connected device sits in the same broadcast domain and can reach every other device without passing a firewall, and it remains the default state of nearly every small practice we walk into. The reason is history rather than negligence. The office grew from six people to sixty, a new dental chair or ultrasound unit got plugged into whatever port was free, and nobody ever went back to redraw the boundaries. The result is a network where the credentials on a billing clerk’s machine are one hop away from the server holding twenty thousand patient records.
We see the consequence of that design most clearly during incident response. When ransomware detonates on a flat clinic network, the operator does not need a sophisticated exploit chain. Standard Windows file sharing and remote management protocols, already permitted between every host, do the work. Segmentation does not prevent the initial compromise, and any vendor who tells you otherwise is selling something. What it does is decide how much of your practice goes dark on the worst day of your year.
How Lateral Movement Crosses a Flat Clinic Network
Lateral movement is the phase of an attack where an intruder uses an initial foothold to reach higher-value systems, and on a flat network it is usually the easiest part of the operation. The path we most often reconstruct runs from a phished front-desk credential, to a network share discovered by scanning the local subnet, to a service account cached on that share’s host, to the practice management server. None of those steps require a new vulnerability, which is the point. Our breakdown of how ransomware spreads laterally across a network walks the same chain in more depth.
There is a fair counterargument worth holding here. Segmentation adds complexity, and complexity introduces its own failure modes. A misconfigured access control list between the clinical zone and the imaging zone can stall a radiology workflow at nine in the morning, and that outage is a patient care problem, not just an IT one. Practices that segment badly do sometimes end up less reliable than they started. The honest position is that segmentation is worth doing and worth doing carefully, with documented rules, tested failure paths, and a rollback plan for each zone you introduce.
Where Medical Devices Break the Assumption of Trust
Medical devices break the usual endpoint model because you generally cannot patch them, cannot install an agent on them, and cannot take them offline for a maintenance window without cancelling appointments. An ultrasound cart running an unsupported operating system will still be on your network in three years, and the manufacturer’s support agreement may explicitly forbid you from touching its software stack. That combination makes the device a permanent, known weakness sitting inside the same zone as your patient records.
The architectural answer is isolation rather than remediation. Put clinical devices on a dedicated VLAN, permit only the traffic the device genuinely needs, which is usually a single destination and port for its acquisition server, and deny everything else including internet egress. That approach accepts the device will stay vulnerable and removes its ability to reach anything worth reaching. Some clinicians push back that isolation risks breaking device integrations, and occasionally it does, which is why the inventory step described below is not optional. Our healthcare secure workspace practice exists largely to handle these cases without disrupting care delivery.
The 7 Network Segmentation Gaps We Find in Small Practices
These are the gaps our assessments surface most often, roughly in order of how much risk they carry per hour of work it takes to close them.
1. Guest wifi bridged to the internal LAN. The waiting-room network shares a subnet, or at minimum a DHCP scope and DNS server, with staff machines. A patient’s compromised phone becomes a foothold inside your perimeter. Building a properly isolated guest wifi network is usually a same-day fix and closes the widest hole for the least effort.
2. Clinical and administrative traffic on one subnet. Billing workstations, scheduling terminals, and the EHR client all resolve to the same broadcast domain as the EHR server. Splitting clinical from administrative is the single boundary that most reduces what an attacker can reach.
3. Unmanaged switches with no VLAN capability. You cannot segment through a switch that does not support tagged traffic. We regularly find consumer-grade eight-port switches under desks, added years ago, carrying clinical traffic. Segmentation stalls until the switching layer supports it. Our primer on what VLAN segmentation is and how it improves security covers the mechanics.
4. No east-west traffic control between zones. East-west traffic is communication between systems inside your network rather than traffic in and out of the internet. Many practices build VLANs and then permit any-to-any routing between them, which produces the paperwork of segmentation without the containment. Zones are only real when a firewall rule enforces them.
5. Medical devices left in the general pool. Imaging modalities, lab analyzers, and monitoring equipment sit alongside laptops with full internet egress. Ninety percent of the risk from an unpatchable device disappears when the device can only talk to one server.
6. Vendor remote access dropped into the flat network. The practice management vendor, the imaging vendor, and the copier vendor each have a remote support path, and those paths frequently terminate on a jump host with broad internal reach. Vendor access needs its own zone with time-bound rules and logging.
7. Backup infrastructure reachable from production. Backup servers joined to the same domain and the same subnet as production get encrypted in the same attack. Segmenting backups, alongside the encryption controls covered in our review of ePHI encryption risks small businesses miss, is what makes recovery a real option rather than a hope.
How to Roll Out Network Segmentation for ePHI Without Downtime
A segmentation rollout succeeds when it moves in three ordered phases, inventory then zone design then departmental cutover, because each phase produces the information the next one needs. We have watched practices attempt the reverse, buying hardware and drawing VLANs before knowing what talks to what, and the result is a stalled project and a frustrated office manager.
Start With an Inventory, Not a VLAN Plan
Begin by cataloguing every device that touches ePHI and every flow it depends on. That means the hostname, the operating system, the owner, the traffic it originates, and the traffic it receives. A week of passive traffic capture on the existing flat network tells you more than any vendor questionnaire, because it shows the integrations nobody documented. This is the same discipline behind a proper network audit, and skipping it is the most common cause of a broken clinical workflow after cutover.
Phase the Cutover by Department
Move one department at a time, starting with the lowest clinical risk. Front desk and billing first, then back office, then clinical workstations, then medical devices last with the vendor on standby. Each move gets a one-week observation window with logging turned up before the next begins. Practices we support this way typically complete a full segmentation across four to eight weeks with no cancelled appointments, and the ongoing network management work afterward is what keeps the boundaries from eroding as new devices arrive.
How Network Segmentation for ePHI Narrows Your Audit Scope
Segmentation narrows HIPAA audit scope because only systems that store, process, or transmit ePHI need to demonstrate the Security Rule’s technical safeguards, and a properly segmented network shrinks that population from every device in the building to a defined, documented zone. That distinction has real cost consequences. Access reviews, audit logging, encryption verification, and risk analysis all get scoped per system, so cutting the in-scope set from ninety devices to twenty-five cuts the recurring compliance workload with it.
The proposed HIPAA Security Rule overhaul strengthens this argument further, moving network segmentation language from an addressable consideration toward an expected safeguard. Practices that segment now are positioning for a requirement rather than reacting to one. When you sit down with a HIPAA compliance audit checklist, a documented zone diagram answers a surprising number of questions in a single page. For practices that want the boundaries watched continuously rather than annually, our network security monitoring and cybersecurity compliance teams handle the evidence side alongside the architecture.
Frequently Asked Questions
Does HIPAA require network segmentation for ePHI?
The HIPAA Security Rule does not name network segmentation as a standalone requirement, but it does require access controls that limit ePHI to authorized systems and people under 45 CFR 164.312, and segmentation is the ordinary technical means of achieving that. The proposed Security Rule update moves segmentation language toward an expected safeguard rather than an optional one. Auditors already treat a flat network as evidence that access control has not been implemented.
How many VLANs does a small medical practice actually need?
Most practices in the 10 to 100 employee range land on five to seven zones: clinical workstations, administrative and billing, medical devices, servers holding ePHI, guest wifi, vendor remote access, and sometimes a separate zone for building systems like cameras and HVAC. More zones are not automatically better, because each boundary needs rules somebody maintains. The right number is the smallest set that keeps ePHI systems reachable only by what genuinely needs them.
Will segmentation break our EHR or imaging integrations?
It can, which is why the traffic inventory comes before the zone design rather than after. Integrations break when a rule blocks a flow nobody documented, so a week of passive capture on the flat network is the cheapest insurance available. Moving one department at a time with an observation window between phases means a mistake affects one workflow for one day instead of the whole practice.
Is segmentation worth it if we already encrypt ePHI?
Yes, because the two controls answer different failure modes. Encryption protects data at rest and in transit if a device or backup is stolen, while segmentation limits which systems an active intruder can reach with valid credentials. Ransomware operators who log in as a real user are not slowed by disk encryption at all, and that gap is exactly what a zone boundary closes.
How long does an ePHI segmentation project take?
For a single-location practice with a switching layer that already supports VLANs, four to eight weeks is realistic, including inventory, design, and a phased cutover. Practices that need switch replacements or have heavy medical-device dependencies run longer, sometimes a full quarter. The medical practice we contained in under three minutes had that response time because the zones were already drawn before the incident.
Talk to Our Team About Your ePHI Segmentation Plan
Segmentation is the control that decides how bad your worst day gets. A flat practice network gives an intruder the whole building from one phished password, and it hands an auditor ninety in-scope systems to ask about instead of twenty-five. The work itself is not exotic. It is an inventory, a zone diagram, a switching layer that supports tagging, firewall rules that actually enforce the boundaries, and a departmental cutover sequence that respects patient care. Practices that treat it as an architecture project finish in a couple of months and spend less on compliance every year afterward. Practices that treat it as a product purchase are still flat three years later.
If you want to know where your own boundaries sit today, we will map your current traffic, show you which devices can reach ePHI right now, and give you the zone design that closes the gaps in priority order. Book a free strategy call with our team and we will start with the inventory. If you would rather read further first, our guide to segmenting a business network to contain breach damage covers the same architecture outside a healthcare context.
Written by Vic, Mindcore Technologies.
