Network-based segmentation divides infrastructure by location. Identity-based segmentation authorizes a verified user, device, or workload to reach a specific service. The strongest zero trust design uses both: network zones provide broad containment, while identity policy decides which connections are allowed inside and across those zones.
Network-based segmentation: control by location
Network-based segmentation controls traffic according to where an asset sits. Common enforcement points include VLANs, subnets, routing boundaries, network security groups, access control lists, and firewalls.
The model is useful because it creates a clear macro boundary. A payment environment, production cluster, or OT zone can be separated from general corporate traffic. Traffic crossing that boundary can then be inspected, logged, and restricted.
The weakness is that location becomes a proxy for trust. Once a workload enters an approved subnet, it may inherit access to many other systems in that subnet. The policy also depends on stable addresses and an accurate map of the network. Containers, cloud workloads, mobile devices, and acquired networks make both assumptions fragile.
Network segmentation remains the right control for broad isolation and compliance boundaries. It is not enough as the only control for east-west access between workloads that share a zone.
Identity-based segmentation: control by verified identity
Identity-based segmentation attaches policy to the identity and attributes of the requester and the protected service, not just to an IP address or subnet. A policy can say that a particular workload identity may reach one database service on one port, while every other connection stays denied.
Identity can represent a human, device, application, container, API, AI agent, or other non-human identity. The system authenticates that identity before it creates the session, then evaluates authorization against policy. This follows the core position in NIST SP 800-207: authentication and authorization are distinct functions performed before a session to an enterprise resource is established.
The result is a smaller trust unit. Two workloads can share a subnet and still have different permissions. A workload can move between hosts or clouds without gaining a new set of permissions just because its address changed.
Identity-based segmentation does not mean ignoring the network. It adds a policy layer that makes identity, service, and context the decision inputs.
Network segmentation vs identity-based segmentation
The difference is the object each model protects. Network-based segmentation protects zones. Identity-based segmentation protects the relationship between a named identity and a named service.
| Decision factor | Network-based segmentation | Identity-based segmentation |
|---|---|---|
| Primary policy input | IP address, subnet, VLAN, route, or zone | Cryptographic or federated identity, service, and context |
| Main boundary | Between network locations | Around an identity-to-service interaction |
| Typical scope | A subnet, VLAN, VPC, or firewall zone | One workload, device, user, API, or service |
| East-west control | Strong when traffic crosses a boundary, weak inside one | Applies to each explicitly authorized connection |
| Response to IP changes | Rules often need updates | Policy can stay attached to the identity |
| Best use | Macro isolation and network architecture | Least-privilege reachability and lateral-movement control |
| Main operational risk | Rule drift, route changes, and broad trusted zones | Identity inventory, enrollment, policy design, and lifecycle management |
Neither model wins every row. Network segmentation gives security teams a dependable outer boundary. Identity-based segmentation gives them a finer decision inside that boundary.
What identity-based segmentation changes in practice
Identity-based segmentation changes the question from “Which network can reach this service?” to “Which verified identity may reach this service, under which conditions?” That change matters most in four situations.
Dynamic cloud and container environments
Cloud workloads are short-lived and addresses are often assigned dynamically. A policy tied only to an address can outlive the workload that held it or fail when the workload moves.
An identity-based rule can follow the workload across hosts, clusters, or cloud environments. The rule still needs good identity issuance and revocation, but it does not require security teams to treat every address change as a policy redesign.
Shared zones with high east-west risk
A subnet can contain a web tier, a job runner, a monitoring service, and a database client. Network segmentation may place them in one application zone for routing simplicity, but those components do not need equal reachability.
Identity-based policy can allow the job runner to call the queue, the web tier to call a specific API, and the API to call the database. It can deny all unrelated paths even when the systems share the same underlay network.
Unmanaged and legacy devices
Some OT, IoT, and medical devices cannot run an endpoint agent or support modern identity protocols. A network-only approach can isolate them into a zone, but that still leaves broad trust among devices inside it.
An identity-first design can use a gateway or connector to represent the device and enforce service-level policy without changing the device firmware. The enforcement method must match the device constraints. Identity-based does not mean every endpoint needs the same software.
Third-party and machine access
Vendors, automation jobs, and machine identities rarely need access to an entire network. They need one service for one task and often only for a defined period.
Identity-based access can grant that narrow relationship, record which identity used it, and revoke it without dismantling a shared tunnel. That is a better fit for partner connectivity and non-human identity governance than a broad network allowlist.
Which model is easier to operate?
Network-based segmentation is easier to understand at the beginning. Network teams already know the VLANs, routes, and firewall zones, and auditors recognize those boundaries.
Identity-based segmentation is easier to keep accurate in an environment that changes quickly. Its control plane must issue identities, connect them to real assets, handle expiration and revocation, and expose useful audit records. Without that lifecycle work, identity policy becomes another source of drift.
The operational comparison should focus on the type of change your team handles most often:
- If systems are stable and the main goal is to isolate broad environments, network zones may be the simplest control.
- If workloads move frequently or teams need service-level access, identity-based policy reduces address-driven changes.
- If the estate includes both managed and unmanaged assets, combine network zones with identity-aware gateways or connectors.
- If the organization needs one policy model across cloud, data center, OT, and partner environments, identity gives the policy a common subject.
The CISA Zero Trust Microsegmentation Guidance treats microsegmentation as a way to reduce attack paths and contain compromise. The practical lesson is to measure reachable services, not just count the number of VLANs created.
How the two models work together
Use network segmentation for the macro boundary and identity-based segmentation for the fine-grained decision. This layered design avoids forcing either control to solve the problem it was not built for.
- Create broad zones. Separate production, corporate, development, OT, and sensitive data environments according to business and risk boundaries.
- Define service dependencies. Identify the services each workload actually needs, including administrative, monitoring, backup, and data flows.
- Issue meaningful identities. Bind identities to people, devices, workloads, and services with clear ownership and expiration rules.
- Write identity-to-service policy. Allow a named identity to reach a named service. Deny unrelated paths by default.
- Run in observation first. Compare proposed policy with real flows and resolve legitimate dependencies before enforcement.
- Enforce in waves. Start with high-value services or high-risk paths, then expand by application or environment.
- Review both layers. Network zones and identity policy should have separate owners, change records, and tests.
This is different from a full network redesign. The goal is to preserve useful underlay routing while making authorization more precise. NetFoundry describes this approach as Universal Microsegmentation, where policy is applied by identity and service rather than by network architecture.
A decision framework for security architects
Choose network-based segmentation first when the decision is about physical or logical isolation. Examples include separating a production plant from office IT, keeping a cardholder data environment behind a documented boundary, or limiting routes between cloud accounts.
Choose identity-based segmentation first when the decision is about least privilege between changing workloads. Examples include limiting an AI agent to approved tools, allowing a deployment runner to reach one internal API, or preventing one service in a shared cluster from reaching another.
Use both when the environment is regulated, distributed, or difficult to change. The network layer supplies containment and familiar evidence. The identity layer supplies precise authorization and a record of which subject reached which service.
Do not select a model based only on the word “microsegmentation.” Ask five concrete questions:
- What is the smallest resource the policy must protect?
- Does the requester move, scale, or change addresses frequently?
- Can the endpoint run an agent, or does enforcement need to happen at a gateway?
- Can the team attribute each connection to a named identity?
- What evidence must the organization produce during an audit or incident review?
The answers expose whether a zone is enough or whether the policy must follow an identity.
FAQ
What is identity-based segmentation?
Identity-based segmentation authorizes access according to a verified user, device, workload, or service identity. It grants access to specific services instead of trusting every system that shares an IP range or network zone.
What is network-based segmentation?
Network-based segmentation divides infrastructure into zones using controls such as VLANs, subnets, routes, ACLs, and firewalls. It limits traffic between locations, but systems inside the same zone may still have broad reachability unless another control intervenes.
Is identity-based segmentation better than network segmentation?
Neither is universally better. Network segmentation is strong for broad isolation, while identity-based segmentation is stronger for least-privilege service access and changing workloads; mature designs commonly use both.
What are the pros and cons of network segmentation?
Network segmentation is familiar, visible, and useful for compliance boundaries, but it can create broad trusted zones and address-based rule maintenance. It also gives limited control over east-west traffic that stays inside one zone.
Does identity-based segmentation replace VLANs and firewalls?
No. VLANs and firewalls still provide useful macro isolation and traffic enforcement. Identity-based segmentation adds a finer policy decision so a system is not trusted merely because it is inside an approved network.
How does identity-based microsegmentation reduce lateral movement?
It limits each identity to the services explicitly allowed by policy. If one workload is compromised, the attacker does not automatically inherit the reachability of the surrounding subnet, which reduces the available paths for lateral movement.
Can identity-based segmentation work with legacy or unmanaged devices?
Yes, when the design uses an appropriate gateway, connector, or other enforcement point that can represent the device without installing software on it. The policy still needs a reliable way to identify the device and manage its lifecycle.
Related articles
- How to Implement Zero Trust for Cloud Workloads
- Zero Trust Tools for Cloud Workloads: A How-To Guide
- Best Zero-Trust Workload Connectivity Platforms
- Overlay Networking for CIDR Conflicts
Sources & References
- NIST SP 800-207, Zero Trust Architecture – zero trust architecture and pre-session authorization
- CISA Zero Trust Microsegmentation Guidance – microsegmentation guidance
- NetFoundry Universal Microsegmentation – identity-first service-level policy model
- NetFoundry Zero Trust Workload Connectivity – workload identity and service-level reachability
- Elisity: Microsegmentation vs Network Segmentation – comparison dimensions and implementation context