Should IAM teams replace network segmentation with identity segmentation?

Why network segmentation and identity segmentation solve different problems

network segmentation limits where traffic can move. identity segmentation limits what an identity can do, regardless of where it connects from. If you replace one with the other, you usually lose containment, because identity controls do not stop traffic flow and network controls do not express business authorization. The better model is layered: network boundaries constrain reachability, while identity rules constrain access.

That distinction matters most in hybrid and cloud environments, where the same user, workload, or service can move across subnets, accounts, clusters, and SaaS control planes. A session that is permitted by identity policy may still need a network boundary to prevent broad lateral movement, and a host that is isolated at the network layer may still require fine-grained identity authorization inside the allowed path.

For workload-centric designs, the identity side becomes especially important because access often depends on short-lived credentials, role assumptions, or service-to-service assertions rather than a stable IP address. Cloud Workload Identity Guide is useful here because it shows how keyless workload access and federated trust can replace static keys without turning network placement into the primary control.

How to think about the control boundary in practice

Use network segmentation to contain blast radius, isolate trust zones, and reduce the paths an attacker can traverse once inside. Use identity segmentation to decide who or what can reach a resource, which actions are permitted, and under what conditions those permissions are granted. In other words, the network decides whether a path exists; identity decides whether the action is allowed.

This is why “identity segmentation” should not be treated as a drop-in replacement for VLANs, firewalls, or security groups. Identity rules are stronger for authorization, but they depend on the enforcement point that mediates the request. If that enforcement layer fails, is bypassed, or is too coarse, the network boundary still matters as a backstop. Zero Trust Identity Guide is a good reference for the identity-centric policy model that keeps access decisions close to the resource.

For teams modernising access design, the practical target is not “identity instead of network” but “identity plus network, with identity carrying the primary authorisation logic.” That approach scales better across remote users, services, and automated systems because policy can follow the identity rather than the subnet, while segmentation still preserves containment where identity controls are not sufficient.

What IAM teams should preserve when moving authorization into the identity plane

Keep three design goals separate: reachability, authorization, and privilege scope. Reachability is a network question, authorization is an identity question, and privilege scope is where identity governance becomes operational. If you collapse all three into one control plane, troubleshooting gets harder and exceptions become invisible.

A strong implementation usually needs at least one lifecycle and one entitlement control path. NHI Lifecycle Management Guide helps with the lifecycle side, especially provisioning, rotation, and offboarding. Cloud PAM and CIEM Guide is the better fit when the decision is about effective permissions, privilege right-sizing, and just-in-time access. Those controls are what make identity segmentation credible at scale.

Where segmentation is being redesigned, it is usually worth validating whether teams can still answer three questions quickly: which identity was allowed, which resource it touched, and whether the request path stayed within expected boundaries. If the answer is unclear, the design may have improved policy expressiveness but weakened operational visibility. Identity Security Programme Guide is useful for the operating-model side of that change.

Practitioner Guidance

What to prioritise: Keep network segmentation where it reduces blast radius or protects legacy systems, then move authorisation logic into identity only where the resource can actually enforce it. The right question is not “can identity replace the network?” but “which decision belongs at which layer?”

What to verify: Confirm that every identity-based policy is enforced at the actual resource or control point, not just documented in a policy engine. Also verify that a denied identity request still leaves the network boundary intact, so one control does not become the silent fallback for the other.

Common mistake: Teams often remove segmentation once they have conditional access, service roles, or zero trust policy in place. That is too aggressive if the environment still contains flat east-west paths, weak workload isolation, or legacy workloads that cannot enforce fine-grained authorization.

Practitioner takeaway: Identity segmentation is a better authorisation model, but network segmentation remains a containment model, and mature IAM programmes need both working together rather than one replacing the other.

Related resources from NHI Mgmt Group

• How should teams implement identity-first network segmentation in OT without repeatedly changing firewalls or VLANs?
• When should teams choose identity-first access over network segmentation for workloads?
• When should industrial teams choose identity-based segmentation over network redesign?
• How should security teams prioritise NHI remediation in cloud environments?