Microsegmentation on the Diagram and in Production

Segmentation · June 23, 2026 · 9 min read

Every segmentation project begins with the same artefact: a diagram of tidy zones, arrows between the ones that should communicate, and nothing between the ones that should not. It is a genuinely good picture. It describes an estate that would be much harder to move through than the one you have.

The gap between that picture and production is not a gap in enforcement capability. Filtering east–west traffic has been a solved problem for years, at the host, the hypervisor, the fabric and the mesh. The gap is that the picture is a statement about intent, and the estate is a statement about history, and nobody holds an accurate map from one to the other.

The unwritten dependency graph

To restrict what a system may reach, you need to know what it currently reaches and why. Almost no organisation knows this. Not through negligence — because the knowledge was never centralised in the first place.

Connections accumulate from every direction. A batch job was pointed at a database during a migration and nobody moved it back. A monitoring agent reaches everything by design. A reporting tool queries a replica that also serves an application nobody in the current team supports. An integration was added under deadline through a firewall exception whose ticket is now the only surviving documentation, and the ticket says “temporary”.

None of these are wrong. They are just unrecorded, and segmentation is an exercise in enumerating exactly what was never recorded.

Discovery tells you what is, not what should be

The standard first move is to observe traffic and generate policy from it. This is the right move, and its limitation needs to be stated clearly, because misunderstanding it is how projects fail slowly.

Observation produces a description of current behaviour. It cannot distinguish between a dependency that is necessary, one that is accidental, one that is obsolete, and one that is an attacker or a misconfiguration you have not noticed. Turn observed traffic directly into allow rules and you have encoded the estate’s history into policy — including whatever should not have been there. The result enforces something, and the something it enforces is “yesterday”.

Observation also has a coverage problem in time. A flow that occurs at quarter end, during failover, in the annual audit export, or only when a particular customer runs a particular job, will not appear in a fortnight of capture. It will appear the first time you enforce, as an outage, attributed to the segmentation project. Two or three of those and the programme acquires a reputation that no amount of subsequent correctness repairs.

The practical consequence is that discovery windows have to span the estate’s real cycles, and that the output of discovery is a draft requiring human adjudication, not a policy.

Enforcement has to be reversible before it is right

The projects that survive share one property: they can observe the effect of a rule before the rule can break anything, and they can undo it in seconds.

That means running policy in a mode where violations are recorded but permitted, long enough to see the rare flows. It means a rollback path that does not depend on the network segment being rolled back — a control channel that stays reachable when the policy is wrong, because it will be wrong at some point, and the failure mode of a segmentation error is a system you can no longer log into to fix it. It means enforcing one zone at a time, starting where the dependency graph is best understood rather than where the risk is highest, because the first enforcement is a test of the process and not of the architecture.

Teams that reverse this order — highest risk first, enforce immediately, because that is what the risk register implies — are attempting their least-understood segment with an unproven process. It is the most common way these programmes die.

Granularity is a maintenance decision

“Micro” invites a race toward the smallest possible segment, and per-workload policy is presented as the mature end state. Sometimes it is. Often it is a way of generating an unmaintainable rule set with excellent intentions.

The relevant question is not how small a segment can be. It is what happens to the policy when the estate changes, which it does constantly. If a rule set is written against addresses, subnets or hostnames, then every deployment, autoscaling event and rebuild invalidates part of it. The policy decays, drift accumulates, and someone eventually adds a broad rule to stop the pages — which is where segmentation programmes go to die, having produced a large, precise, mostly obsolete rule set with a wide exception through the middle.

Policy that is written against labels — a role, a service, an environment, a data classification — survives the change, because the identity of the workload outlives its address. This is the point where segmentation and identity stop being separate topics. A segment that means “the payment service, whatever instances currently constitute it” is durable. A segment that means “these addresses” is a snapshot.

The right granularity is therefore the finest one whose labels you can actually keep accurate. That is usually coarser than the diagram and far more durable than the ambition.

What segmentation is for

It is worth being precise about the benefit, because overclaiming it invites disappointment.

Segmentation does not prevent compromise. It constrains what a compromise becomes. An attacker with control of a workload still has that workload; what segmentation changes is whether that position is a step toward something else. The value is entirely in the shape of the reachable set: how many other systems are directly addressable, how many hops separate the initial position from anything sensitive, and how many of those hops require a credential rather than just connectivity.

That is a real and substantial benefit, and it is also why it is hard to demonstrate. Segmentation is measured in incidents that stayed small, and an incident that stayed small looks, from the outside, like an incident that was never serious.

Recognising the difference

There is a straightforward way to tell whether a segmentation programme has produced enforcement or documentation. Pick a workload. Determine what it may reach. Then try to reach something outside that set — from the workload itself, with its own credentials.

If the attempt fails, and the failure is visible somewhere, the segment exists. If it succeeds, or succeeds via a path the diagram does not show, or fails silently with nothing recorded, then what exists is a description of a segmented estate rather than a segmented estate.

The diagram is not the problem. The diagram is fine. The problem is that a diagram is a hypothesis, and the only way to convert it into a control is to test it against the network you actually run.