Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk What do security teams get wrong about segmentation…
Governance, Ownership & Risk

What do security teams get wrong about segmentation in Zero Trust?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated July 11, 2026 Domain: Governance, Ownership & Risk

They often treat segmentation as a network design exercise instead of an identity and governance control. Effective segmentation limits what each identity can reach, based on real dependencies and risk. Without that link, microsegmentation becomes too broad, too static, or too easy to bypass.

Why This Matters for Security Teams

Segmentation fails when it is treated as a subnet map instead of an access decision. zero trust is supposed to verify each request, yet many teams still build boundaries around VLANs, host groups, or application tiers and assume that is enough. NIST SP 800-207 Zero Trust Architecture makes clear that trust decisions should be continuous and context-aware, not implied by network position.

That matters because NHI-driven traffic rarely follows clean human-user patterns. Service accounts, API keys, and workload tokens can chain through multiple services, inherit excess access, and bypass a perimeter that was designed for static trust zones. The result is often broad east-west reach, weak blast-radius control, and segmentation rules that look precise on paper but fail under real workloads. NHIMG research on the Ultimate Guide to NHIs — Standards shows that 90% of IT leaders say proper NHI management is essential for successful zero trust, which is a strong signal that identity governance and segmentation are inseparable.

In practice, many security teams discover segmentation gaps only after an API key, service account, or automation token has already moved laterally through a trusted path.

How It Works in Practice

Effective segmentation in Zero Trust starts with identity, not IP range. Each workload, service account, agent, or API client needs a defined identity, an observed set of dependencies, and policy that limits what it can reach at runtime. That is why current guidance suggests combining network enforcement with workload identity, policy-as-code, and explicit service-to-service authorization.

A practical model usually includes:

  • Mapping real dependencies before enforcing rules, so controls reflect actual application flows rather than assumed architecture.
  • Using workload identity, such as SPIFFE/SPIRE or OIDC-based tokens, to prove what the service is before it is allowed to connect. See Guide to SPIFFE and SPIRE.
  • Applying least privilege to every identity, including service accounts and automation identities, rather than granting broad subnet access.
  • Evaluating policy at request time with contextual signals like workload, destination, environment, and purpose, rather than relying on static allowlists.
  • Shortening credential lifetime so compromise does not translate into durable lateral movement.

For identity-centric segmentation, the control plane is just as important as the firewall. NIST SP 800-207 Zero Trust Architecture emphasizes continuous verification, while NHIMG’s Ultimate Guide to NHIs — Standards documents how excessive privileges and poor rotation practices widen the attack surface for non-human identities. Segmentation works best when policy can answer not only where traffic came from, but whether that identity should be allowed to make this request right now.

These controls tend to break down in environments with flat legacy networks, unmanaged east-west service discovery, or shared credentials because the identity-to-dependency mapping is too weak to enforce precise runtime decisions.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance blast-radius reduction against engineering friction and policy maintenance.

One common edge case is shared infrastructure. In Kubernetes, service meshes, and CI/CD runners, teams often inherit abstractions that make IP-based segmentation look neat while hiding the real trust relationships underneath. Another is third-party and SaaS integration, where the boundary is not inside the enterprise network at all but inside token scope and OAuth consent. NHIMG research on the State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how easily segmentation assumptions can fail outside the core network.

Best practice is evolving on how far policy should move from network controls into identity-aware authorization, so there is no universal standard for this yet. What is consistent is the need to avoid treating segmentation as purely static. In highly dynamic cloud environments, the safer model is to define trust around the workload identity and its approved actions, then let the network enforce only the narrow transport path needed for that action. That approach is stronger than traditional microsegmentation, but it demands better inventory, dependency discovery, and governance discipline than many teams have today.

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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01Segmentation must account for each non-human identity's allowed reach.
OWASP Agentic AI Top 10A2Autonomous agents can chain tools and bypass static network boundaries.
CSA MAESTROTRAThreat modeling should include identity-centric segmentation and lateral movement.
NIST AI RMFAI RMF supports governance for dynamic, context-aware access decisions.
NIST Zero Trust (SP 800-207)PA-3Zero Trust requires continuous verification, not implied network trust.

Use AI RMF governance to define accountability for runtime authorization decisions.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org