Identity segmentation is the missing layer in zero trust controls

At a glance

What this is: This is a discussion of why identity segmentation is presented as the missing layer in Zero Trust, with the central finding that network segmentation alone leaves identity-driven attacks undercontrolled.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes increasingly need access decisions that follow identity context rather than device location or network zone.

Context

Network segmentation has long been used to separate systems by IP range, VLAN, or firewall boundary, but that model assumes access risk is mainly about where a device sits on the network. Identity-driven attacks break that assumption because attackers often authenticate with valid credentials, which makes the network path look legitimate even when the access should not be.

Identity segmentation moves the control point into the identity control plane. Instead of using only static network boundaries, it applies access rules based on identities, roles, attributes, and context so the policy tracks who or what is requesting access rather than just where the request originates.

Key questions

Q: Why does network segmentation alone fail to stop identity based attacks?

A: Network segmentation reduces exposure, but it cannot stop an attacker who already has valid credentials or a misconfigured identity. If an account has standing access, missing MFA, or excessive privilege, the attacker can operate as an authorised user inside the segmented environment. Identity controls are needed to constrain what that identity can do after access is granted.

Q: Why do identity-based access controls matter more than network location in Zero Trust?

A: Because Zero Trust is meant to evaluate the request, not the address. Identity-based controls matter when users, devices, and applications move across locations and still need access decisions that reflect role, context, and entitlement. Network location alone cannot express those differences reliably.

Q: What signs show that segmentation is too dependent on the network layer?

A: Common signs include broad access tied to subnet membership, firewall rules that mirror office topology, and the same permissions applying to very different users or devices. Those patterns indicate the policy is using network position as a shortcut for authorisation, which creates avoidable exposure.

Q: Should IAM teams replace network segmentation with identity segmentation?

A: No. They should use network segmentation for traffic containment and identity segmentation for access control. The two serve different purposes. The practical decision is to keep network boundaries as a supporting control while moving authorisation logic into the identity plane.

Technical breakdown

Why network segmentation stops at the wrong control plane

Network segmentation is built around infrastructure boundaries such as subnets, VLANs, and firewall rules. Those controls reduce exposure, but they do not express who should access a resource once a user, device, or application is already inside an allowed segment. Because the policy is usually tied to location and traffic path, it tends to stay static even when the access risk changes. That is why the model works best in a castle-and-moat design and becomes less precise in distributed environments where identities, not office networks, determine access.

Practical implication: teams should treat network segmentation as a perimeter control, not a substitute for identity-aware authorisation.

How identity segmentation uses roles and attributes for access control

Identity segmentation applies segmentation logic to the identity control plane rather than the network map. In practice, that means access decisions can use identity, role, device context, and application context to narrow which resources a subject can reach. This is closer to Zero Trust because access is evaluated against the subject and the request, not assumed from network membership. The value is not just tighter access. It is a policy model that can distinguish between users, devices, and applications even when they operate from the same network location.

Practical implication: security teams should map critical resources to role and attribute conditions, not just to IP ranges or zones.

Why compromised credentials defeat static segmentation

The article's key security point is that attackers increasingly target user identities, then use compromised credentials to inherit whatever access the network policy already permits. Static rules cannot tell the difference between legitimate and malicious use once authentication succeeds. That creates a control gap: the network may be correctly segmented, yet the identity can still move across resources that are too broadly available for its actual role. Identity segmentation is meant to close that gap by making access more granular and context-aware.

Practical implication: teams should review where valid credentials still unlock excessive reach across otherwise segmented environments.

NHI Mgmt Group analysis

Identity segmentation is the missing control layer when Zero Trust stops at the network boundary. The article is correct that modern environments no longer fail only at the perimeter; they fail at the identity decision point. When access policy is still anchored to network zones, the programme protects traffic paths but leaves identity-based access decisions under-governed. That means Zero Trust remains incomplete until identity becomes the control surface.

Static segmentation assumes access can be inferred from location, and that assumption no longer holds. Firewall rules and VLAN boundaries were built for environments where users sat behind stable network edges. In distributed work, identity and context change faster than those boundaries do, so the policy is always one step behind the actual request. Practitioners should re-evaluate any architecture that still treats network location as a proxy for authorisation.

Identity segmentation makes least privilege enforceable in the places network segmentation cannot reach. The article's emphasis on roles, attributes, and context reflects the core IAM problem: access should follow entitlement, not topology. That is especially relevant where users, devices, applications, and workloads share infrastructure but do not share the same access needs. The practical conclusion is that authorisation must become identity-centric if Zero Trust is to be more than a perimeter redesign.

Identity-context segmentation: this article points to a useful concept for practitioners who need to separate traffic control from access control. Network segmentation limits paths, but identity-context segmentation limits who can use those paths based on role and context. That distinction is where modern identity governance starts to matter more than infrastructure zoning.

For identity programmes, segmentation is no longer just a network design choice. It is a governance choice about where authorisation lives and which signals it should trust. That changes the work for IAM and PAM teams because they must define access granularity at the identity layer, not only inherit it from network architecture. The field is moving toward policy that follows the subject, not the segment.

What this signals

Identity segmentation becomes decisive where authentication succeeds but authorisation is still too broad. That is the programme-level lesson for IAM and PAM teams: if your controls only verify that traffic stayed inside a trusted zone, you are still missing the access decision that matters most. The identity plane has to carry more of the policy load than the network plane.

Identity-context policy is the better mental model for Zero Trust in distributed environments. Access should be resolved using identity, role, and contextual signals because those signals survive device changes, remote work, and hybrid infrastructure. This is where identity governance and network design stop being separate conversations and start becoming one operating model.

For practitioners

• Reframe segmentation around identity decisions Map your highest-value resources to identity, role, and attribute conditions instead of assuming IP ranges and VLANs are enough to express access intent.
• Find broad access inherited from network location Review where users receive access simply because they sit inside a trusted subnet or firewall zone, then document where that location-based trust exceeds role need.
• Tie Zero Trust to the identity control plane Use identity-aware policy as the centre of Zero Trust design so devices, users, applications, and workloads are evaluated on context rather than network adjacency.
• Test whether valid credentials still open too much Simulate access using compromised-but-valid accounts to identify which segmented resources remain reachable without additional identity checks or contextual restrictions.

Key takeaways

• Identity segmentation addresses a governance gap that network segmentation cannot cover because authenticated access can still be overbroad.
• The article's central issue is not the absence of perimeter controls, but the use of static network policy as a proxy for identity authorisation.
• Practitioners should shift Zero Trust design toward identity-aware access decisions while keeping network segmentation as a containment layer.

Key terms

• Identity Segmentation: The practice of separating identities by workload, environment, and risk so one credential cannot easily move across unrelated systems. For machine identities, segmentation is a blast-radius control as much as a least-privilege measure, because shared dependencies can turn a single compromise into a wider operational event.
• Network Segmentation: Network segmentation divides traffic and resources into controlled zones so access can be restricted between groups, systems, or applications. In remote access design, segmentation limits what a connected user or workload can reach after authentication, which reduces lateral movement and shrinks blast radius.
• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.