Network Segmentation Guide: Zones, Microsegmentation & Rollout

Most networks are still one room. A laptop in reception can open a TCP connection to the finance database, the hypervisor management interface and every other laptop in the building, because that is what routing does by default. Network security fundamentals covers the flat-network problem and the controls that sit on it; this guide is the design work on top: which model to choose, where the boundaries go, what microsegmentation adds, and how to get default-deny into production without taking the business down.

The stakes are set by what a single compromised endpoint inherits. Lateral movement is cheap in a flat network because there is nothing to move past.

A segment is wherever policy is enforced

The most common failure in segmentation projects is confusing the label with the control. A VLAN is a broadcast domain. A subnet is an address range. Neither of them denies anything. If VLAN 20 and VLAN 30 both have gateway interfaces on the same router and no access list between them, a host in 20 reaches a host in 30 by routing, exactly as designed.

A segment exists where three things are true:

1. Traffic leaving it passes through an enforcement point.
2. That enforcement point has a default-deny posture, so anything not explicitly permitted is dropped.
3. Something logs what it dropped, so you find out when the policy is wrong.

The enforcement point sits at a routed boundary (a firewall or access list between zones), in the fabric (hypervisor policy or cloud security groups, applied at the virtual NIC), or on the host (Windows Defender Firewall, nftables, an agent). What each of those controls is belongs to network security fundamentals; the design decision here is which one owns a given boundary. Host-level enforcement is the one that makes peer-to-peer blocking practical at scale, because the rule travels with the workload.

Treat the VLAN as the place you attach policy rather than the policy itself. VLAN separation depends on switch configuration that VLAN hopping defeats when trunk negotiation is left on or the native VLAN is left at its default, so the policy needs to survive a Layer 2 mistake.

The four models

Perimeter zones divide the estate into a handful of named zones (user, server, DMZ, guest, printers, OT) and put a firewall between them. It is the cheapest model that produces a real reduction in reach, and it stops at the zone edge. An attacker who lands in the server zone still reaches every other server in it.

Tiered enclaves add a dimension: the administrative plane gets its own zone regardless of what it administers. Domain controllers, hypervisor consoles, switch management interfaces and backup servers sit in a management zone that ordinary workstations cannot reach at all. Administrators arrive through a bastion. This is the pattern SSH bastion hardening implements for Unix estates, applied to the whole management plane. It matters because credential theft compounds: a domain admin who logs into a compromised workstation leaves credentials on it, and the tiering exists so that never happens. Active Directory security covers the identity half of that story.

Microsegmentation moves enforcement to the workload. Two web servers on the same subnet with no reason to talk to each other are prevented from doing so. Policy is written against labels (role=web, env=prod, app=billing) rather than IP ranges, so it survives re-addressing and autoscaling. The cost is real: you need a policy engine, an accurate inventory, and a way to see flows.

Physical isolation removes the routed path entirely. Reserve it for the small set of systems where a policy mistake is unacceptable. NIST SP 800-82r3 recommends strict segmentation with an IT/OT DMZ and controlled conduits, noting that true air gaps are rare in practice, and reserves physical isolation for the cases that warrant it. Even then, an isolated network is reachable through removable media, which is how worms cross into them.

Where to draw the boundaries

Boundaries are expensive: each one is a policy to maintain, a set of exceptions to review, and a place a change can break. Draw them where they buy the most.

Trust asymmetry. Put a boundary anywhere the two sides have genuinely different trust levels. Guest wifi and the corporate LAN. Contractor laptops and employee laptops. A printer running firmware from 2019 and anything at all.

Blast radius. If compromising one host in a group would be a bad day, and compromising the whole group would be a company-ending event, the group is too big. Split it.

Compliance scope. PCI DSS scope is defined by connectivity: any system that can reach the cardholder data environment is in scope for assessment. A boundary here reduces audit cost as directly as it reduces risk, which is often what gets the project funded.

Traffic locality. Systems that talk to each other constantly belong together. Systems whose only interaction is a nightly batch job belong apart. Chasing this backwards produces zones with hundreds of cross-boundary rules and no real isolation.

Change velocity. A development environment where builds redeploy hourly and a payroll server patched twice a year should not share a policy domain.

What you should end up with is fewer, larger zones than instinct suggests, plus microsegmentation inside the ones that matter. Twelve zones with a clean policy beat forty with an exceptions list nobody reads.

A worked example

A 500-person company with two sites, roughly 700 endpoints, 90 virtual servers and a small OT footprint in the warehouse. Address plan 10.0.0.0/8, one firewall pair per site, VMware for servers.

The zones are the easy half. The policy matrix is the deliverable:

Two rows carry most of the value. User -> User: nothing removes peer-to-peer SMB and RDP, which is the widest movement path in a Windows estate and the one SMB abuse and pass-the-hash depend on; a Group Policy object that sets Windows Defender Firewall to block inbound 445, 3389 and 5985 from any source except the management subnet enforces it without buying anything. User -> Management: nothing means a phished laptop cannot reach vCenter, the switches or the backup server, which is where a ransomware operator goes to delete recovery points before encrypting.

Note what the matrix does not say. It does not say Server-App -> Server-Data: any. Naming the ports and the source hosts is the difference between a boundary and a doorway.

Microsegmentation: enforcement at the workload

Zone-level policy leaves the inside of each zone flat. In the example above, the 54 application servers can still reach each other on every port. Microsegmentation closes that.

The mechanism is straightforward. Every workload gets a policy applied at its own network interface, either by the hypervisor, the cloud fabric, or an agent driving the host firewall. Rules are expressed against labels rather than addresses:

allow app=billing role=web -> app=billing role=db tcp/5432
allow role=* -> role=logcollector tcp/6514
default deny

Three properties make this worth the effort:

• Policy survives change. A new billing web server inherits the rule the moment it is labelled, whatever address it gets.
• East-west traffic becomes visible. Policy engines log allowed and denied flows per workload, which turns "what talks to the database" from a guess into a query.
• The blast radius becomes one host. An attacker on a compromised web server finds that the other 53 servers refuse its connections.

Rolling it out without breaking production

Segmentation projects fail at cutover. The cause is always the same: flows nobody knew about. A monitoring agent that reaches every host on a custom port. A finance macro that mounts a share on a colleague's desktop. A vendor support tunnel from 2018.

Phase 1: observe, 30 days minimum. Turn on flow export (NetFlow, IPFIX, VPC flow logs, or the policy engine's own discovery mode) and collect for a full month so you capture month-end batch jobs. Do not write a single rule during this phase. On the estates we have run this on, a tenth to a fifth of observed flows turned out to be undocumented, and a handful were things worth shutting down on sight.

Phase 2: draft the matrix. Turn observed flows into intended policy, zone by zone. Every permitted flow gets a named owner and a business reason. Flows nobody can explain go on a list; that list is a security finding in its own right.

Phase 3: log-only enforcement. Deploy the policy in a mode that logs what it would have denied without denying it. Run it for two to four weeks per zone. The would-be-denied log is your remaining gap, and it shrinks fast if the observation phase was honest.

Phase 4: cut over one zone at a time. Flip default-deny on the least risky zone first (guest, then printers, then user endpoints), and leave the server and identity zones until the process is proven. Cut over at the start of a working day with the team available, never on a Friday evening.

Phase 5: keep a rollback and a break-glass. A documented single command that reverts the zone to permit-and-log. A break-glass rule that a named on-call engineer can enable, that expires automatically, and that raises an alert when used.

Phase 6: review the exceptions. Every exception gets an expiry date. A quarterly review that removes dead rules is what keeps the policy from decaying back into permit-any over three years.

On the mid-sized estates we have worked on, first flow capture to default-deny has run somewhere between six months and a year. Plan the calendar around phase 1 rather than compressing it.

Failure modes

A flat management VLAN. Every switch, hypervisor, iLO/iDRAC and backup console in one zone that half the IT department can reach directly. This is the single most damaging shortcut, because it hands an attacker the controls for everything at once.

The jump host inside the zone it protects. A bastion that lives in the server zone and accepts connections from the user zone has moved the boundary rather than enforced it. The bastion belongs in the management tier with its own policy in front of it.

Zone-wide any/any rules with a comment. permit ip 10.40.0.0/24 10.50.0.0/24 with ! app team requested beside it is a hole with documentation. Name the ports and the hosts.

Dual-homed hosts. One server with an interface in two zones bridges them regardless of what the firewall says. Backup servers, monitoring collectors and jump hosts are the usual offenders. Audit for hosts with interfaces in more than one zone.

Shared services that reach everywhere. The monitoring platform, the patch server and the backup agent frequently need broad access, and each one becomes a route between all zones. Give them tightly defined ports, one direction where possible (agents pulling rather than servers pushing), and treat their servers as management-tier assets.

Backups reachable from what they back up. Ransomware crews delete backups first. The backup infrastructure needs to be reachable from the production zone as little as possible, with immutable or offline copies beyond that reach. Ransomware anatomy covers what the operator does with the access they have.

The DR site that never got segmented. Policy applied at the primary site and skipped at the secondary means a failover silently reverts you to a flat network on the worst day of the year.

Segmentation without identity tiering. Twelve beautifully separated zones that all authenticate against the same domain, with the same domain admin accounts logging into all of them, share a single credential blast radius. The network policy and the identity tiering have to agree.

Verify it from inside

After each cutover, test from a host inside the zone rather than from the firewall's own view.

• Sweep the zone from a workstation: ICMP, then TCP 445, 3389, 5985, 22 against a sample of peers and against a host in every other zone. Everything the matrix denies should time out. See port scanning for how to do this without setting off your own alarms unannounced.
• Confirm the drops are logged. A deny that produces no log entry is invisible when it starts breaking something legitimate.
• Test the reverse direction. Policies are frequently asymmetric by accident.
• Repeat quarterly and after any firewall migration, since rule bases lose their ordering during vendor changes.
• Feed the results into detection. A workstation attempting SMB to 40 peers is now a high-fidelity alert, because the policy made that behaviour abnormal rather than routine.

That last point is the underrated dividend. Segmentation makes lateral movement noisy as well as difficult, because traffic that used to be normal background now hits a deny rule and generates an event.

Verdict

Segmentation delivers more risk reduction per unit of effort than nearly anything else in network security, and the effort is real. The order that works: put the User -> User row into a host firewall policy this quarter, since it costs almost nothing. Build a management tier behind a bastion next, because it protects the controls that ransomware operators go for. Then run the full flow-observation and log-only cycle before you take default-deny into the server estate.

Done in that order, the same estate that once let a reception laptop reach a database becomes one where an attacker's second step is a dropped packet and an alert.

Related guides

• Lateral Movement Explained
• VLAN Hopping Explained
• Network Security Fundamentals
• Zero Trust Architecture Explained
• What Is a Firewall
• SSH Hardening Guide
• SMB Security Explained
• API Security Guide