Who should own identity segmentation across users, workloads, and applications?

Why This Matters for Security Teams

identity segmentation is not just an access-control exercise. It determines whether users, workloads, and applications can be separated cleanly enough to limit blast radius when credentials are exposed, a service is compromised, or a privileged path is abused. Without shared ownership, teams often implement local fixes that conflict with one another and create hidden trust paths. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes fragmented segmentation especially dangerous.

Security teams get this wrong when they treat segmentation as either an IAM-only problem or a network-only problem. Real segmentation spans identity proof, policy enforcement, and workload trust. That means security architecture needs to define the control model, platform teams need to implement the runtime mechanics, and identity teams need to govern entitlements and lifecycle decisions. This is especially important as machine and service identities outnumber humans in many environments, and the Critical Gaps in Machine Identity Management report shows that 59% of companies struggle to audit machine identities because ownership and visibility are unclear. In practice, many security teams encounter segmentation failure only after a lateral movement path or overbroad service token has already been used, rather than through intentional design.

How It Works in Practice

Effective ownership starts with a shared policy model, not a shared spreadsheet. Identity teams define the authoritative identity standards: how users authenticate, how workloads prove who they are, and how application-to-application trust is issued and revoked. Security architecture defines the segmentation rules, including which identities can talk to which systems, under what conditions, and with what level of assurance. Platform teams then enforce those rules in the tools that matter at runtime, such as IAM, service mesh policy, cloud permissions, and network controls.

This works best when segmentation is expressed as policy rather than static exception lists. For example, users may be placed into roles and access boundaries, workloads may receive short-lived credentials tied to a workload identity, and applications may be isolated by environment, function, and data sensitivity. The SPIFFE workload identity specification is useful here because it gives a cryptographic way to assert workload identity independent of IP address or infrastructure location. That matters when the same service is redeployed across clusters, regions, or ephemeral environments.

• Use one source of truth for identity classes, not separate ones for users, services, and apps.
• Map segmentation decisions to business boundaries such as application tier, data class, and environment.
• Enforce least privilege with short-lived credentials and continuous policy evaluation.
• Require explicit owners for exceptions, with expiry dates and review triggers.

The operational test is simple: if a team cannot explain who can access a workload, why that access exists, and how it will be revoked, the segmentation model is not mature enough. These controls tend to break down in hybrid estates with legacy applications because identity signals are inconsistent and enforcement points are fragmented.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance blast-radius reduction against deployment speed and support burden. That tradeoff is real in environments with mainframes, shared service accounts, or vendor-managed applications where native identity support is weak. In those cases, best practice is evolving rather than settled: some teams segment by network zone first, while others prioritize workload identity and policy enforcement, then phase in stricter boundaries over time.

One common edge case is shared platform services. Databases, CI/CD runners, and internal APIs may sit between human users and application workloads, so ownership has to account for both provisioning and runtime authorization. Another is multi-cloud or multi-tenant environments, where the same logical application may have different trust constraints in each environment. The governance answer does not change: identity teams own standards, security architecture owns the segmentation model, and platform teams own implementation. The practical control objective is to make every boundary intentional, reviewable, and revocable.

For broader NHI lifecycle context, the Top 10 NHI Issues and 52 NHI Breaches Analysis both show how ownership gaps become exposure gaps when identities are not segmented consistently across systems.

Related resources from NHI Mgmt Group

• Who should own identity governance for ERP, HCM, and integration users?
• Who should own risk quantification across identity and controls?
• Who should own PQC migration across identity, infrastructure, and applications?
• Who should own identity governance when it spans cloud and enterprise systems?