Network Segmentation Best Practices

Segmentation doesn't prevent initial compromise — phishing, a vulnerable exposed service, a stolen credential will still get an attacker a foothold somewhere. What it limits is what happens next: lateral movement. In a flat network, compromising one workstation on a shared broadcast domain with servers, other workstations, and management interfaces means the attacker can immediately scan, enumerate, and attack everything else on that segment. In a properly segmented network, that same foothold can reach only what policy explicitly permits.

This is also why segmentation shows up repeatedly in compliance frameworks (PCI DSS scope reduction, HIPAA's minimum necessary principle applied to networks) — it's a control that both reduces risk and reduces the size of what has to be audited and hardened to a high standard.

Segmentation happens at multiple layers, and mature environments combine them rather than relying on one:

• •VLANs — Layer 2 broadcast domain separation; cheap and standard, but only as strong as the routing/ACL policy enforced between VLANs, since VLANs alone just group hosts, they don't restrict traffic
• •Subnetting + inter-VLAN routing ACLs — the actual enforcement layer; a router or Layer 3 switch applies access control between VLANs, which is where the real policy lives
• •Firewall-enforced zones — for higher-assurance boundaries (e.g., cardholder data environment, OT/ICS network, DMZ) a stateful firewall rather than a router ACL enforces the boundary, giving you logging, deep inspection, and IPS capability at the chokepoint
• •Microsegmentation — host- or workload-level policy (via host agents, hypervisor-level firewalls, or a service mesh) that doesn't depend on IP subnet boundaries at all; essential in virtualized/cloud/container environments where workloads move and scale dynamically

A reasonable baseline segmentation scheme for a typical mid-size enterprise network separates, at minimum:

• •User/workstation VLANs — segmented further by department or trust level where useful, always separated from server VLANs
• •Server/application VLANs — segmented by function and sensitivity (e.g., database tier separate from web/app tier)
• •Management VLAN — out-of-band access to switch/router/firewall management interfaces, reachable only from a small set of admin jump hosts, never from general user VLANs
• •Guest/BYOD VLAN — internet-only, no route to any internal VLAN whatsoever
• •OT/IoT/printer VLAN — isolated because these devices are frequently unpatchable or unmanaged, with tightly scoped ACLs for the specific traffic they legitimately need
• •DMZ — covered in depth in the companion article on firewall/DMZ design

A Cisco-style extended ACL restricting the workstation VLAN (VLAN 10) from reaching the server VLAN (VLAN 30) except for specifically permitted application traffic, applied on the Layer 3 switch/router interface:

ip access-list extended VLAN10-TO-VLAN30
 remark Allow workstations to reach the internal app server only on 443
 permit tcp 10.0.10.0 0.0.0.255 host 10.0.30.15 eq 443
 remark Allow DNS to the internal resolver
 permit udp 10.0.10.0 0.0.0.255 host 10.0.30.5 eq 53
 remark Deny everything else to the server VLAN, log for visibility
 deny ip 10.0.10.0 0.0.0.255 10.0.30.0 0.0.0.255 log
 remark Permit everything else outbound (internet-bound, etc.)
 permit ip any any

interface Vlan10
 ip address 10.0.10.1 255.255.255.0
 ip access-group VLAN10-TO-VLAN30 in

• •VLANs created for organizational/broadcast reasons with no ACL enforcement between them — this is segmentation in name only
• •Management interfaces (switch/router/hypervisor admin, out-of-band iLO/iDRAC) left reachable from general user VLANs
• •Flat backup and monitoring infrastructure that has broad reach into every segment by necessity, becoming a high-value pivot target if compromised — these systems need their own hardening and tighter-than-usual scrutiny
• •Overly permissive "temporary" ACL entries that never get removed, mirroring the same drift problem seen in DMZ firewall rules
• •Assuming VLAN separation alone stops an attacker with Layer 2 access — VLAN hopping via double-tagging or misconfigured trunk ports is a real technique when trunk negotiation isn't locked down
• •No east-west traffic logging, so lateral movement between segments (when it does succeed) goes undetected

• •Default-deny between segments; every allowed flow should be a deliberate, documented decision, not a byproduct of convenience
• •Disable dynamic trunk negotiation (DTP) on access ports and explicitly set trunk ports to prevent VLAN hopping
• •Put segmentation policy under the same change-review and audit cadence as firewall rules — it decays the same way if untended
• •Combine subnet-based segmentation with microsegmentation for cloud/virtualized workloads, since IP-based policy alone doesn't hold up under autoscaling and dynamic IP assignment
• •Instrument east-west traffic (flow logs, IDS taps on inter-segment links) so lateral movement attempts are visible, not just blocked silently

Everything above is about design. A segmentation policy that looks correct in a firewall rule review can still fail in practice — a forgotten permissive rule, a misconfigured route, a VLAN a new switch got trunked into by default. The only way to know segmentation actually constrains an attacker is to test it the way an attacker would use it, not just read the ACLs.

PCI DSS v4.0 makes this explicit for cardholder data environments: segmentation used to reduce audit scope must be validated by penetration testing at least annually and after any significant change to the segmentation controls, specifically confirming that out-of-scope systems genuinely cannot reach in-scope systems. That requirement is good practice generally, not just a PCI checkbox — segmentation is a control that silently decays as networks change, and a config review alone won't catch a route or firewall rule that quietly reopened a path.

In practice this means periodically attempting lateral movement from a low-trust segment (guest VLAN, a standard workstation) toward higher-value segments (server VLAN, management network, cardholder data environment) using the same tools an attacker would — port scans, protocol probes, credential relay attempts where applicable — and confirming the attempt is both blocked and logged. For Active Directory environments specifically, tools like BloodHound surface indirect lateral-movement paths (via group memberships, cached credentials, or delegation) that a pure network-layer ACL review would never reveal, since those paths use protocols segmentation was designed to allow (SMB, RPC, Kerberos) rather than ones it was designed to block.