What Is Micro-Segmentation?

Micro-segmentation applies policy at the level of individual workloads rather than network zones. Where conventional segmentation separates a server network from a user network, this separates one server from another — including servers on the same subnet.

The objective is a default-deny posture between workloads, where each can reach only what it specifically requires.

Identity rather than address

The important shift is that policy attaches to a workload's identity rather than to its network location. A rule permits the application server to reach the database server, and it continues to hold when either moves, scales or is rebuilt with a different address.

That property is what makes it viable in dynamic environments. Address-based rules in an estate where workloads are created and destroyed continuously become wrong faster than anyone can maintain them.

The cost is discovering how things actually communicate

Achieving default-deny requires knowing every legitimate flow, and in an estate of any age nobody does. Applications have dependencies established years ago, integrations nobody documented, and monitoring or backup agents that reach everything.

This is why implementations run in observation mode for an extended period, building a map from actual traffic before any policy is enforced. Skipping that step is how micro-segmentation projects cause outages and get cancelled.

Where it is worth the effort

Environments holding regulated or high-value data, where limiting lateral movement has direct compliance and breach-impact value. Multi-tenant platforms where separation between tenants matters. And estates where east-west traffic is substantial and currently unrestricted.

It is disproportionate effort for a small, static environment where coarse segmentation achieves most of the benefit.

Policy authorship is the sustaining problem

Initial policy comes from observed traffic. Subsequent policy has to come from somewhere, and if every new application requires a specialist to write rules, the programme becomes a bottleneck and teams route around it.

The approaches that scale attach policy to labels rather than instances — this workload is a web tier, that one is a database — so a new deployment inherits policy from its role. Application teams then declare intent and the platform enforces it.

That requires consistent labelling, which is an organisational discipline rather than a technical one, and it is the thing to establish before the enforcement tooling rather than after.

Performance and failure behaviour deserve testing before enforcement. Policy evaluated per connection adds latency, and the behaviour when the policy service is unreachable — fail open or fail closed — determines whether an outage in the control plane becomes an outage in the applications. Both are defensible choices and neither should be discovered accidentally.

A common mistake worth avoiding

Where to start

Deploy flow visibility before buying enforcement. The map of what actually talks to what is valuable on its own, and it is the precondition for any policy that will not cause an outage.

See micro-segmentation in practice. GuardsArm runs security program reviews.