A breach rarely ends where it starts. An attacker phishes one employee, drops a loader on a laptop, and then the real work begins: hunting for credentials, domain controllers, file shares, and eventually the backup server. On a flat network, that journey is often a short one — sometimes a single command away from the crown jewels. Segmentation is the practice of making that journey long, noisy, and expensive.

What segmentation actually means

A flat network lets almost any device talk to almost any other device. Your marketing intern's laptop can reach the SQL server, the payroll system, the hypervisor management interface, and the NAS holding last night's backups. Nobody designed it that way on purpose. It grew.

Segmentation replaces that with defined groups of assets and enforceable rules about which groups may communicate, over which protocols and ports, and under what conditions. The enforcement point matters more than the diagram. A VLAN with a permissive router between it and everything else is a label, not a control.

It helps to think of two extremes. Isolation is a wall — no traffic passes, and operations usually suffer. Segmentation is a set of locked doors with logs: traffic that should happen still happens, and everything else is denied and recorded. Most real environments live somewhere in between, tightening over time.

Why lateral movement is the hard part

Perimeter defenses answer one question: can someone get in? They say very little about what happens next. Once inside, an attacker usually needs three things to move: network reachability, usable credentials, and time without being noticed.

Segmentation attacks the first directly and the other two indirectly. If the compromised laptop cannot open a session to the database subnet, the attacker must find another path — and each new path means new credentials, new tooling, and new opportunities to trip a log alert.

There is a detection benefit too. East-west traffic inside a well-segmented network is boring and predictable. The application tier talks to the database tier on port 1433, the web tier talks to the app tier on 8443, and not much else. When a workstation suddenly starts probing SMB across twenty hosts, that behavior stands out instead of dissolving into normal background noise.

Segmentation will not stop an attacker from getting in. It decides how far they get, how long it takes, and how many chances you have to catch them.

One caution: encryption does not help here. An attacker moving laterally is often riding legitimate protocols with stolen credentials, so TLS just wraps the intrusion in something your tools cannot read.

Practical zone design

Start from what you are protecting and how it is used, not from an org chart. Zones that hold up in practice usually include:

• User endpoints — workstations and laptops, ideally separated by role or department where practical.
• Identity infrastructure — domain controllers and identity providers, reachable only by the systems that genuinely need authentication.
• Application tiers — web, application, and middleware layers, each talking only to the tier next to it.
• Data stores — databases and warehouses, accepting connections only from their application tier and administrative jump hosts.
• Management plane — hypervisors, switches, firewalls, and backup consoles. This zone deserves the strictest rules and the least lateral access.
• Backup and recovery — separate credentials, separate network path, and ideally a copy that is not domain-joined at all.
• Operational technology and IoT — printers, cameras, badge readers, and industrial equipment that often run old firmware nobody can patch.
• Guest and contractor — internet-only, with no route into internal services.

Two rules of thumb are worth repeating. The management plane should never be reachable from user endpoints. And backups should be isolated from the directory, because attackers who control the domain can otherwise delete or encrypt the recovery path along with everything else.

Making the design real

Policy that is not enforced is a wish. Here is a sequence that avoids breaking production:

1. Inventory and map flows. You cannot write rules for traffic you have not observed. Collect flow logs for a few weeks before you decide anything.
2. Classify assets. Tag each host with its zone, owner, and criticality. Stale tags are the main reason segmentation projects stall.
3. Write policy from the flows. Turn observed, legitimate traffic into explicit allow rules, and make the default deny.
4. Enforce in monitor mode first. Log what would have been blocked, review it with application owners, then flip to blocking in stages.
5. Add host-level controls. Internal firewalls, endpoint firewalls, and identity-aware proxies catch traffic that never crosses a network boundary — useful for cloud and remote work.
6. Alert on denials. A blocked connection is either a misconfiguration or an attacker. Both are worth knowing about within minutes, not months.

Avoid the big-bang cutover. Segment one zone, prove it, document the exceptions, then move on.

Common mistakes and the cloud wrinkle

The most frequent failures are predictable. Teams create a hundred VLANs with a router that permits everything between them. They enforce segmentation on paper while an unmanaged switch quietly bridges two zones. They leave a management subnet wide open because "the admins need flexibility." They forget the VPN pool, which lands users directly in the server network.

In cloud environments, segmentation looks different but follows the same logic. Security groups, subnet boundaries, private endpoints, and network policies between workloads do the job. Identity becomes the primary control: a service account with broad permissions is a flat network wearing a costume. Apply the same discipline to IAM roles that you would to firewall rules.

Remote work adds a final complication. When laptops are off-site, the office firewall is irrelevant. Device posture checks, per-application tunnels, and zero-trust access brokers are worth the effort if you want segmentation to follow the user.

A workable starting point

Pick one zone with high value and few dependencies. Backup infrastructure and identity servers are good first candidates. Restrict inbound access to known administrative hosts, deny everything else, log all denials, and test that the legitimate workflows still run. Then repeat.

Expect to spend more time on conversations than on configuration. Application owners know which flows matter; flow logs tell you the rest. Keep an exception register with an owner and an expiry date, review it quarterly, and treat every new flat path as a decision rather than an accident. That habit, more than any product, is what keeps lateral movement slow.

Photo: dlohner / Pixabay