Microsegmentation in Practice, Without Grinding to a Halt
The single most damaging property of most corporate networks is that they are flat: compromise one host and you can reach thousands. Microsegmentation is the antidote — dividing the network into small zones, ideally down to individual workloads, so that reaching one thing does not mean reaching everything. The concept is old and obviously correct. The reason most organisations still run flat networks is that doing it wrong breaks production, so they never start.
Traditional segmentation carved the network into a few large zones with firewalls between them — a step up from flat, but a compromised host still had free run of its whole zone, which might be hundreds of servers. Microsegmentation pushes the boundary down to the workload: each application, sometimes each service, gets its own policy defining exactly what it may talk to. The default becomes deny, and every allowed path is explicit. Lateral movement stops being free.
The east-west traffic nobody watches
Perimeter firewalls inspect north-south traffic — in and out of the network. The traffic that matters for lateral movement is east-west: server to server, workload to workload, the connections an attacker rides after the initial foothold. In a flat network this traffic is entirely unrestricted and largely unmonitored. Microsegmentation is fundamentally about bringing policy and visibility to east-west flows, which is exactly where intrusions expand.
Why it breaks things, and how to not
The way microsegmentation fails is predictable: a team writes deny policies based on a network diagram that is wrong, blocks a dependency nobody documented, and takes down an application. Everyone gets burned, and the project stalls. The disciplined approach reverses the order — observe first. Map the actual flows for weeks, understand what really talks to what, then write policies in monitor mode, watch what they would block, and only enforce once you're confident. You segment based on reality, not on the architecture you wish you had.
- Map real flows before you write a single rule. The network you think you have and the network you actually have differ in exactly the dependencies that will break under enforcement.
- Start with the crown jewels. You don’t need to segment everything at once. Ring-fence the highest-value assets first — that’s where containment pays off most.
- Enforce in monitor mode first. Run policies in ‘would-block’ mode and review, so the first time a rule bites is in a report, not an outage.
- Segment by identity where you can, not just IP. Workload identity survives the dynamic addressing of cloud and containers where IP-based rules silently rot.
- Keep policy as code. Manual per-host firewall rules don’t scale and drift into a mess nobody understands. Version and review segmentation like the infrastructure it is.
- Pick two systems that have no business talking to each other — a developer laptop and the finance database, say — and check whether the network actually stops the connection. If it goes through, your network is flatter than your diagram claims.
- Ask for the map of what actually talks to your most critical workload. If nobody can produce it, you’re not ready to segment it — and neither is the attacker stopped from reaching it.
Mapping true east-west flows and validating that segmentation actually contains lateral movement — without the outage — is careful work our assessment supports, so containment is proven rather than assumed.
Microsegmentation is the control that decides whether a breach is an incident or a catastrophe. Everything upstream — detection, response, Zero Trust identity — buys you time and warning; segmentation is what limits how much the attacker can reach while you use it. Done carelessly it breaks the business; done with discipline it is the difference between losing a host and losing the estate. And you cannot segment the flows you never mapped, in a network you never fully saw.