By Uniqcli Team
Microsegmentation is network segmentation applied at the level of the individual workload rather than the network zone. Instead of dividing an estate into a handful of segments and controlling what crosses between them, it places a policy boundary around each workload — a virtual machine, a container, a physical server, sometimes a single application process — and controls traffic between workloads even when they share a subnet, a switch and a broadcast domain. The traffic it governs is the east-west kind: server to server, service to service, inside the perimeter.
That is the specific gap it exists to close. Traditional designs concentrate enforcement at the boundary between zones, so once something is inside a zone it can generally reach everything else in that zone. Lateral movement — the phase of an intrusion where an attacker uses one compromised host to reach the ones that matter — happens entirely inside that space, where a perimeter firewall never sees it. Microsegmentation makes the reachable set of a compromised host a policy decision rather than an accident of which VLAN it was plugged into.
The vocabulary belongs to zero trust, and the alignment is genuine rather than marketing: NIST's zero-trust architecture guidance describes access to individual resources as an explicit, per-request decision, and CISA's maturity model puts network segmentation on a progression from broad perimeters toward isolated workloads with tightly defined policy. Microsegmentation is one of the controls that implements the network portion of that idea. This page explains the category and where enforcement sits; it does not compare or rank products, because the right enforcement point depends on what already runs in the estate.
Microsegmentation vs VLANs, subnets and firewalls
A VLAN divides a physical switch into separate logical broadcast domains using 802.1Q tagging, and it is the coarse tool most estates already have. It is genuinely useful — it separates voice from data, guests from staff, cameras from everything — but its granularity is the segment. Two servers in the same VLAN can talk to each other freely, and nothing in the VLAN mechanism inspects or restricts that conversation. Subnets are the layer-3 expression of the same boundary, and access control lists on a router or a firewall govern what crosses between them.
The practical limit is arithmetic. Enforcing policy between workloads by giving each one its own VLAN and subnet means one boundary per workload, and every one of those needs an address plan, a gateway, a routing entry and a rule set on the device between them. That does not scale past a small number of tiers, and it hairpins east-west traffic through a firewall that was sized for north-south volumes. Microsegmentation decouples the policy from the topology: the boundary follows the workload, is expressed in terms of identity and role rather than address, and is enforced close to the workload instead of at a chokepoint.
Ringfencing is the intermediate step and, for many organizations, the one that delivers most of the value. Rather than a policy per workload, it draws a boundary around one application — its web tier, its application servers, its database — allowing the flows that application needs internally and denying everything else in or out. It is far less work than full per-workload policy, it protects the systems that actually matter, and it is the sensible first phase of almost every project in this category. Perimeter firewalls do not become redundant either way; they still govern what enters and leaves, while microsegmentation governs what moves inside.
Where the enforcement point actually sits
There are four common places to put it, and the choice is usually decided by what the estate already runs. Hypervisor-based enforcement applies policy in the virtual switch, so every packet leaving a virtual machine passes a filter the guest operating system cannot see or disable. It covers virtualized workloads comprehensively and covers nothing that is not virtualized. Host-agent enforcement puts a policy agent inside each operating system, programming the host's own firewall; it follows the workload across virtual, physical and cloud environments and depends on an agent being installed, supported and running, which excludes appliances and most operational technology.
Fabric-based enforcement uses the network itself: workloads are assigned a policy tag, the tag travels with the traffic, and switches enforce the policy between tags. It needs no agent and no hypervisor, which makes it the only option for equipment that can host neither, and it requires network hardware that supports the tagging and policy model end to end — a real constraint in a mixed-age access layer. Cloud-native enforcement is the same idea expressed in a provider's own primitives, security groups and network policies, and in Kubernetes it is worth remembering that pod-to-pod traffic is open by default until a network policy selects the pods in question.
Most estates of any size end up with more than one enforcement point, which introduces the problem that decides whether the project succeeds: policy has to be authored once and applied consistently across all of them, or the model becomes several unrelated rule sets that drift. When evaluating an approach, the question worth asking is not which enforcement point is strongest but whether one policy model covers every workload type you have — virtual, physical, containerized, cloud and the equipment that will never run an agent — and what happens at the seams between them.
What the zero-trust guidance actually says
NIST SP 800-207, Zero Trust Architecture, is the reference document, and its contribution here is a model rather than a product list: access to a resource is granted per session by a policy decision point and enforced by a policy enforcement point placed as close to the resource as possible, with trust never conferred by network location. Segmenting down to individual resources protected by their own enforcement point is one of the deployment approaches it describes. The paper also makes a point buyers should read carefully — a zero-trust architecture is assembled from components an organization largely already owns, and the enforcement point's placement matters more than its branding.
CISA's Zero Trust Maturity Model puts the same idea on a ladder. The Networks pillar progresses from large perimeter-based segments toward isolation of critical workloads and, at the higher levels, network segments defined by application workflows with policy distributed to them — which is a description of microsegmentation in all but name. The Devices and Identity pillars matter to this page too, because the policy is only as good as the identity attached to the workload and the health of the machine hosting it.
For implementation detail, the National Cybersecurity Center of Excellence's practice guide NIST SP 1800-35, Implementing a Zero Trust Architecture, documents built reference implementations rather than principles, which makes it the more useful document once a design is under way. None of these publications endorse a product, and that is exactly their value in procurement: they let a requirement be written in terms of the properties an architecture must have, which keeps the specification honest and the market open.
Discovery first: the order that decides the outcome
Every project in this category runs the same way when it works. Deploy in observation mode and map the flows — which workloads talk to which, on which ports, how often, and in which direction — for long enough to include the traffic that only happens at month-end, at quarter-end, during backups, during patching windows and during the annual process nobody documented. Applications have dependencies their owners cannot enumerate from memory; the flow map is the only reliable source, and shortening the observation window to hit a date is the most reliably regretted decision available.
Then write policy from the map, and apply it in a mode that logs violations instead of dropping traffic. Watch what would have been blocked, correct the policy, and only then enforce — ringfence by ringfence, application by application, starting with the systems whose flows are best understood rather than the ones whose data is most sensitive. The instinct to begin with the crown jewels is understandable and usually wrong: the first enforcement is where the process gets debugged, and debugging it on the payment system is a choice with consequences.
Default-deny is the destination, not the starting position. A policy that permits known flows and denies the rest is the entire point of the exercise, and switching it on before the flow map is complete produces an outage whose cause is a security control — which, in most organizations, ends the programme rather than the misconfiguration. Getting there incrementally, with each ringfence proven before the next begins, is slower on paper and faster in practice.
What it asks of the infrastructure
Each enforcement model has a hardware and licensing bill. Hypervisor enforcement usually sits in a higher tier of the virtualization licensing and consumes host CPU for filtering, which shows up on clusters already running close to their consolidation limit. Host agents consume CPU and memory on every protected workload, and on database and application servers sized precisely, that overhead is a capacity planning input rather than a rounding error. Fabric enforcement depends on the access and distribution switches supporting the tagging and policy model consistently — a requirement that should be checked per model rather than per vendor, because support varies within a product line and an unmanaged switch cannot participate at all.
Visibility is its own requirement. Flow mapping needs east-west traffic data, which typically means flow export from the switches, telemetry from the hypervisor or agents, or a sensor fed by a network TAP or mirror port sized so it is not silently dropping frames. Where enforcement hairpins traffic through a firewall, that firewall now carries east-west volumes it was probably not sized for, and inside a data centre those can exceed north-south traffic by a wide margin. Distributed enforcement avoids that specific problem, which is a large part of why it is the prevailing design.
Two operational dependencies round it out. The policy engine becomes infrastructure the network depends on, so it needs redundancy and a documented answer to what enforcement points do when it is unreachable — continue with the last known policy, fail open, or fail closed. And out-of-band management access has to survive the policy, because the first serious microsegmentation outage is the one where the rule that broke connectivity also blocked the path to the console that would fix it.
Where microsegmentation projects go wrong
Policy sprawl is the slow failure. Rules written per workload multiply, nobody deletes them when the workload is decommissioned, and after two years the rule set is large enough that no one is confident about changing it. The defence is to write policy in terms of labels and roles rather than addresses — this tier of this application may reach that tier on these ports — so that a new server inherits its policy from its role and a retired one takes nothing with it. Address-based rules also break the moment workloads become ephemeral, which in a container platform is immediately.
Exceptions are the fast failure. Every flow permitted because an application team could not explain it, every workload excluded because its owner objected to the agent, and every temporary allow-any rule left in place is a hole with a name attached. Recording each one with an owner and a review date keeps the list finite; leaving them undocumented produces, within a couple of years, a segmented network in which everything important is in the exception list.
The third is treating it as a network project. The flow map is a statement about applications, and it can only be validated by the people who own them, which means application teams have to be engaged from the discovery phase rather than consulted when something breaks. Projects that skip that step reliably discover a critical dependency during enforcement instead of during observation. The infrastructure side of the work — the switches that support policy tags, the hosts with headroom for an agent, the sensors that make east-west traffic visible — is the part Uniqcli quotes, through authorized US distribution; sending the flow-map requirements and the workload counts with the request is what makes that quote reflect the design rather than a guess at it.
Key takeaways
- Microsegmentation enforces policy per workload rather than per zone, controlling east-west traffic between servers that share a subnet, switch and broadcast domain.
- VLANs and subnets are coarse boundaries that do not scale to one-per-workload; microsegmentation decouples policy from topology and expresses it as identity and role instead of address.
- Enforcement sits in the hypervisor, in a host agent, in the network fabric via policy tags, or in cloud-native primitives — most estates use more than one and need a single policy model across them.
- Ringfencing one application at a time delivers most of the value for a fraction of the effort, and is the sensible first phase before any attempt at per-workload policy.
- Discovery decides the outcome: map flows in observation mode across a full business cycle, log violations before dropping anything, and reach default-deny incrementally rather than at the start.
- The bills are licensing tiers and host overhead for agents, fabric support that must be verified per switch model, east-west visibility via flow export or a TAP, and out-of-band management that survives the policy.
Shop it at Uniqcli
Frequently asked
- What is the difference between microsegmentation and VLANs?
- Granularity and what the boundary is attached to. A VLAN divides a switch into separate broadcast domains, and everything inside one VLAN can generally talk to everything else in it without inspection — the boundary is the segment. Microsegmentation places the boundary around the individual workload, so two servers in the same VLAN and the same subnet still have their traffic governed by policy. It also decouples policy from topology: rules are written in terms of workload role and labels rather than addresses, so a workload keeps its policy when it moves and a new one inherits policy from its role. VLANs remain useful and most microsegmentation designs sit on top of them rather than replacing them.
- Do we need an agent on every workload?
- Only if agent-based enforcement is the model you choose. Host agents follow the workload across virtual, physical and cloud environments and are the most portable option, but they require an installable, supported operating system — which rules out network appliances, printers, cameras, industrial controllers and most operational technology. Hypervisor-based enforcement covers virtual machines with no in-guest agent at all. Fabric-based enforcement uses policy tags carried by the network and covers equipment that can host neither. Estates with a mix normally combine two or three, and the question that matters during evaluation is whether one policy model spans all of them or you end up maintaining separate rule sets that drift apart.
- Is microsegmentation the same as zero trust?
- No, but it implements part of it. Zero trust is an architecture that replaces location-based trust with explicit, continuously re-evaluated access decisions across identity, devices, networks, applications and data. Microsegmentation is a control that enforces the network portion, placing a policy decision between workloads instead of assuming that co-location implies permission. NIST SP 800-207 describes it as one deployment approach among several, and CISA's maturity model places it at the upper levels of the Networks pillar. A programme that segments the network but leaves identity, device health and application access untouched has better network security, not zero trust.
- How long does a microsegmentation rollout take?
- The configuration is quick and the discovery is not, which is where schedules go wrong. The sequence that works is observation first — deploy in a mode that maps flows without enforcing — for long enough to capture a full business cycle including month-end, quarter-end, backup and patch windows and any annual process. Then policy written from that map, applied in a mode that logs violations rather than dropping traffic. Then enforcement, one ringfenced application at a time, starting with the systems whose flows are best understood. Compressing the observation phase is the most common cause of an outage during enforcement, and the outage is usually what ends the programme.
- Does microsegmentation replace our firewall?
- No — they govern different traffic. A perimeter or next-generation firewall controls what enters and leaves the network and inspects north-south traffic at the boundary. Microsegmentation controls east-west traffic between workloads that are already inside, which a perimeter device never sees. Designs that try to do the internal job with the perimeter device end up hairpinning server-to-server traffic through a chokepoint that was sized for a different volume, and inside a data centre east-west traffic can substantially exceed north-south. Distributed enforcement close to the workload avoids that, which is a large part of why it is the prevailing approach.
- Where should a first microsegmentation project start?
- With ringfencing a single application rather than with per-workload policy across the estate. Pick an application whose flows are well understood, map them, draw a boundary around its tiers that permits the internal flows it needs and denies everything else in and out, and prove it in a logging-only mode before enforcing. That delivers a meaningful reduction in lateral movement risk for a fraction of the effort of a full deployment, and it debugs the process — the tooling, the change control, the conversation with application owners — on a system where a mistake is recoverable. Starting with the most sensitive system is the common instinct and the wrong order.
Keep reading