Should organisations prioritise identity mapping before another segmentation project?

Yes, when the main risk is compromised accounts moving across systems you cannot currently trace. Segmentation remains useful, but it will not tell you who can reach what. A current identity-to-resource map gives responders the information they need to contain lateral movement without guessing.

Why Identity Mapping Comes Before Another Segmentation Project

Segmentation reduces where traffic can go, but identity mapping shows who can legitimately reach each resource in the first place. When organisations cannot trace accounts, service identities, or privileged paths across systems, segmentation only narrows the blast radius on paper. A current map of identity to resource access gives responders and architects the context needed to decide whether they are fixing trust boundaries or merely redrawing them.

That distinction matters because lateral movement is usually an access problem before it is a network problem. The OWASP Non-Human Identity Top 10 is useful here because it frames excessive access, weak lifecycle controls, and poor visibility as structural weaknesses rather than edge cases. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which illustrates why identity discovery often becomes the prerequisite to meaningful containment.

In practice, many teams discover that their segmentation design did not fail, it simply never had enough identity context to prove what should have been allowed in the first place.

How the Two Controls Work Together in Practice

Identity mapping and segmentation solve different parts of the same containment problem. Segmentation defines network or logical boundaries, while identity mapping answers which human and non-human identities, roles, tokens, and privileged services can cross those boundaries. If the access map is stale, responders cannot tell whether a connection is expected, over-permitted, or actively abused.

A practical sequence is to map critical identities first, then test segmentation against that map. That usually means building a current inventory of privileged users, service accounts, API keys, automation accounts, and the systems they can reach. Once that picture exists, segmentation can be tuned to reduce unnecessary reachability, but the map remains the reference point for exception handling and incident containment.

Identify the identities that can reach crown-jewel systems and sensitive administration planes.
Trace direct and delegated access paths, including cross-environment and automated access.
Mark which paths are business-required, which are inherited, and which are unknown.
Use segmentation to constrain the unknown and over-broad paths, then verify the result against the map.

This order matters because segmentation without identity visibility can hide excess privilege rather than remove it, especially where automation, shared accounts, or inherited trust relationships are already in place.

These controls tend to break down when access is mediated by automation-heavy environments with rapidly changing service identities, because the network boundary can look stable while the actual trust relationships change daily.

Common Variations and Edge Cases

Tighter segmentation often increases operational friction, so organisations have to balance reachability reduction against the cost of maintaining exceptions and troubleshooting blocked traffic. That tradeoff is especially sharp in environments where identity sprawl is already high, because every new segment adds another place where access must be justified, logged, and reviewed.

There is no universal standard for whether segmentation or identity mapping should come first in every programme, but current guidance suggests prioritising identity mapping when the dominant risk is unknown or over-privileged access. If the environment is already well understood, segmentation may be the faster hardening step. If the environment is poorly understood, segmentation can become an expensive guess.

Another edge case is where teams assume that a network redesign will also solve privilege drift. It will not. Network controls can block paths, but they do not answer ownership, revocation, lifecycle, or exception governance. That is why identity mapping is often the better first move when the organisation needs evidence for containment decisions rather than another layer of theoretical isolation.

When a segmentation project is driven by audit pressure rather than a specific access-risk problem, it is easy to overbuild the network and underbuild the governance needed to keep it accurate.

Risk and Threat Considerations

The material risk is false confidence: organisations can believe they have reduced exposure while still lacking a defensible view of which identities can actually reach which systems. That leaves lateral movement, privilege misuse, and unauthorized automation paths harder to detect and contain.

Failure mechanism: If identity-to-resource relationships are unknown, an attacker who compromises a valid account can exploit legitimate paths that were never mapped, while defenders rely on segment boundaries that do not reflect actual access rights.

Impact: Containment slows down, privilege creep persists, and incident responders may have to guess which systems are reachable, which exceptions are legitimate, and where to cut access without breaking core operations.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Visibility and Discovery	Identity-to-resource mapping depends on discovering service and machine identities.
	NHI-03 — Privileged Access and Excessive Permissions	Excessive access is central when segmentation must contain lateral movement.
Recommendation — Inventory all non-human identities and map their resource access paths before tightening segments. Reduce over-broad identity permissions before relying on network segmentation for containment.
NIST Zero Trust (SP 800-207)	SC-7 — Resource Access Policy and Control	Segmentation should enforce explicit access decisions at trust boundaries.
Recommendation — Define and enforce access policy at each boundary so reachability matches the approved trust model.
CIS Controls v8	6 — Access Control Management	The question is fundamentally about who can access what and how that is governed.
Recommendation — Review and remove unnecessary access paths before treating segmentation as sufficient.
NIST CSF 2.0	PR.AC — Identity Management, Authentication and Access Control	Identity mapping is needed to govern access and contain lateral movement.
Recommendation — Maintain an accurate access model so containment actions target the right identities and systems.

Practitioner Guidance

What to prioritise: Start with the identities that can reach privileged and business-critical systems, then work outward. If those paths are unclear, segmentation should be treated as a control enhancement, not the primary containment answer.

What to verify: Confirm that the access map includes human users, service accounts, API keys, automation, and cross-environment trust. If any of those are missing, the map will understate the real blast radius and the segmentation design will be built on incomplete evidence.

Decision rule: If the organisation cannot answer who can reach what today, fix that first. If it can answer that question reliably, segmentation can then be used to reduce exposure with far less guesswork.

Practitioner takeaway: The strongest containment programmes do not choose between identity mapping and segmentation, they use identity mapping to make segmentation defensible and measurable.