Overview
Network segmentation is the practice of dividing a network into smaller pieces so that a compromise in one piece does not give the attacker free movement through the rest. It is one of the oldest controls in information security (the original perimeter firewall, the original VLAN, the original air gap) and it is still one of the most useful.
Zero Trust has not made segmentation obsolete. The two are complementary, not substitutes. Zero Trust moves the access decision from the network to the identity and the policy engine; segmentation reduces the blast radius of a single compromise and limits the lateral movement that a Zero Trust bypass or a misconfiguration can enable. An organization that has Zero Trust but no segmentation has a single policy engine compromise away from total network exposure. An organization that has segmentation but no Zero Trust has a network that limits movement but still authenticates broadly. The right posture is both.
The interesting question is what segmentation looks like in 2025. The options range from the traditional (VLANs and firewalls, designed for an on-prem world) to the modern (service-mesh sidecars that enforce per-workload policy, designed for a Kubernetes world) to the hybrid (a mix of both, because most organizations have both). The right answer depends on the environment, the team, and what the network actually does.
How it works
Traditional segmentation is based on network primitives: VLANs (which are Layer 2 broadcast domains identified by a 12-bit tag, so up to 4,094 of them on a single switch fabric), VRFs (which are Layer 3 routing tables that overlap, so the same router can run multiple isolated routing instances), and firewalls (which are stateful packet filters that apply policy at the boundary between segments). The control is: traffic from one segment can only reach another segment if the firewall says so, and the firewall's policy is the operational contract for what the network allows.
Microsegmentation moves the control from the network boundary to the workload. A workload (a virtual machine, a container, a Kubernetes pod) has an identity, and the policy for what that workload can talk to is attached to its identity, not to its IP address. The implementation is usually a sidecar proxy (Envoy in Istio, Linkerd's proxy, Cilium's eBPF-based enforcement) that intercepts every network call the workload makes, evaluates the call against policy, and either allows, denies, or rejects. The control plane (Istio, Cilium, Calico, or a cloud-provider service mesh) manages the policy and the sidecar configuration.
The hybrid model uses both. The network layer provides the coarse segmentation (datacenter VLANs, cloud VPCs, the boundaries between environment tiers like dev, staging, and production), and the workload layer provides the fine segmentation (which specific services can talk to which other specific services, regardless of where they are). The boundary between the two is usually the policy engine: a single set of authorization rules, expressed in a vendor-neutral format (Rego, Cedar, or a domain-specific language), evaluated at the enforcement point whether the enforcement point is a firewall or a sidecar.
In practice
A small-to-medium on-prem network is usually segmented with VLANs and a pair of firewalls (one at the internet edge, one at the internal trust boundary). The pattern is: a management VLAN with the operators' workstations, a server VLAN with the workloads, a user VLAN with the endpoints, a guest VLAN with the Wi-Fi, and a DMZ for internet-facing services. The firewall policy is the operational contract: server-to-server is allowed within the server VLAN, user-to-server is allowed for specific services, and the management VLAN can reach everything for break-glass purposes. This is the same pattern that has been in use since the 2000s, and it is still the right starting point for an on-prem network that does not have a service mesh.
A cloud-native environment is usually segmented with VPCs (one VPC per environment, one VPC per service tier, or a shared VPC with firewall rules between subnets), security groups (stateful firewall rules attached to each workload), and a service mesh (Istio, Linkerd, or the cloud-provider equivalent) for fine-grained service-to-service policy. The pattern is: the VPC is the coarse boundary, the security group is the medium boundary, and the service mesh is the fine boundary. A workload that needs to talk to a database gets a specific security group rule; a service that needs to talk to another service gets a specific mesh policy. The two layers are independent and the right answer is to use both.
A hybrid environment (the common case in 2025) usually runs a mix: an on-prem datacenter with VLANs and firewalls, cloud VPCs with security groups, and a mix of cloud-native services (with a mesh) and legacy services (without). The unifying control is a policy engine that can express the rule in one place and enforce it everywhere. Open Policy Agent, Cedar, and the cloud-provider policy services (AWS IAM, Azure Policy, GCP IAM) all do this to varying degrees. The hard part is not the technology; it is the operational discipline of keeping the policy in sync with the actual network.
Common mistakes
Treating segmentation as a one-time project. The network changes (new services, new VPCs, new cloud accounts), the segmentation has to change with it. An organization that segments the network in a year-one project and then never revisits the segmentation gets the cost of segmentation without the benefit. The right operational model is segmentation-as-code: the firewall rules, security group rules, and service-mesh policies are all in version control, with the same change-review process as application code.
Over-segmenting. A network with 50 segments is harder to operate than a network with 5, and the security benefit of the 50th segment is rarely proportional to the operational cost. The right starting point is the smallest number of segments that maps to the actual trust boundaries in the organization: one segment per environment tier, one segment per major service, and one segment for the management plane. Add more only when a specific compromise scenario requires it.
Under-segmenting the management plane. The management plane (the network the operators use to deploy, monitor, and respond) is the highest-value target in any environment, because a compromise of the management plane gives the attacker the ability to control every other part of the environment. The management plane should be on its own segment, with explicit allowlists for what it can reach, and ideally with its own authentication (mTLS to every service, not shared credentials) so that a compromise of the user plane does not lead to a compromise of the management plane.
Assuming segmentation is the primary control. Segmentation is one control among many, and it is most useful as a defense-in-depth measure: a control that limits the blast radius when another control fails. An organization that has segmentation but weak identity, weak patching, weak detection, and no Zero Trust is an organization that has built a wall around a house with no roof. The wall will keep some attackers out; the others will walk in through the ceiling.
Defensive guidance
Start with the smallest segmentation that maps to your actual trust boundaries. The starting point is usually three segments: the user plane (endpoints), the workload plane (servers and services), and the management plane (operators and tooling). Add more segments only when a specific threat model requires it. The right test for whether a new segment is needed is: would a compromise of the contents of this segment be meaningfully different from a compromise of the segment it would otherwise be in?
Put the management plane on its own segment, with explicit allowlists. The management plane is the highest-value target in the environment; it is also the segment that the smallest number of people need access to, which makes the allowlist manageable. Use mTLS for management plane access where possible, so that a compromise of the user plane does not lead to a compromise of the management plane.
Treat the segmentation as code. Firewall rules, security group rules, and service-mesh policies should all be in version control, with the same change-review process as application code. A change to the segmentation should go through a pull request, with the same review rigor as a change to the application. The operational cost is real; the operational benefit is that the segmentation stays in sync with the network, which is the only way it stays useful.
Run a segmentation exercise at least once a year, where the goal is to confirm that the segmentation is what you think it is. The exercise is: pick a service in segment A, attempt to reach it from segment B, document what you find, and fix any unexpected gaps. The output of the exercise is a list of segmentation changes to make and a list of detection rules to add. The input to the exercise is a current network diagram, which you should also have.
Combine segmentation with Zero Trust. Segmentation limits the blast radius; Zero Trust limits the access. The two together are a defense-in-depth posture that holds up when one of the two fails. An organization that has only one of the two has a posture that holds up only as long as the one does not fail. The right operational model is to treat both as ongoing engineering work, not as one-time projects.