How should security teams use microsegmentation with zero trust?

Security teams should use zero trust to control whether an identity can access a resource and microsegmentation to control how far that identity can move after access is granted. The two controls work best when paired with least privilege, short-lived credentials, and explicit zone boundaries, especially for service accounts and privileged users.

Why This Matters for Security Teams

zero trust and microsegmentation solve different problems, and security teams often get into trouble when they try to make one do the work of the other. Zero trust is about deciding whether an identity should get access at all, while microsegmentation limits where that identity can go once access exists. That distinction matters most for service accounts, workloads, and privileged users, where blast radius is usually the real failure mode.

NIST SP 800-207 Zero Trust Architecture explains that access decisions should be continuously evaluated rather than assumed from network position alone. In NHI programs, that becomes critical because identities are numerous, persistent, and often over-privileged. NHIMG’s Ultimate Guide to NHIs — Standards notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which reflects how tightly these controls are linked in practice.

The practical risk is simple: if access is granted too broadly, microsegmentation has to absorb the resulting lateral movement. In practice, many security teams discover that gap only after a service account has already moved from one zone into a more sensitive environment.

How It Works in Practice

The most effective pattern is to use zero trust at the access layer and microsegmentation at the movement layer. Zero trust should answer: is this identity, workload, or agent allowed to request this resource right now? Microsegmentation should then answer: which network paths, service-to-service flows, and data-plane destinations remain reachable after the request is approved?

For non-human identities, that usually means combining short-lived credentials, workload identity, and policy enforcement at runtime. A workload can authenticate with cryptographic identity, such as SPIFFE/SPIRE, then receive access only for the specific task it is performing. NHIMG’s Guide to SPIFFE and SPIRE is useful here because it frames workload identity as the primitive that makes zero trust enforceable for machine-to-machine traffic.

• Use zero trust policy to decide whether the identity may reach the service, API, or namespace at all.
• Use microsegmentation to restrict east-west traffic after initial access, especially between tiers and environments.
• Pair both controls with least privilege, JIT credential issuance, and short TTLs so access expires before it becomes reusable.
• Log identity, request context, and network path together so policy failures and segmentation failures can be correlated.

Current guidance suggests treating segmentation boundaries as enforcement points, not as the primary identity control. That means policy-as-code, continuous authorization, and explicit service boundaries should be evaluated together rather than separately. NIST SP 800-207 Zero Trust Architecture supports this model, while the NHI management guidance from NHIMG emphasizes that secrets sprawl and excessive privilege are what make segmentation valuable in the first place. These controls tend to break down in flat networks with shared service accounts because identity attribution and path restriction both become too coarse to contain lateral movement.

Common Variations and Edge Cases

Tighter microsegmentation often increases operational overhead, requiring organisations to balance containment against deployment speed and troubleshooting complexity. That tradeoff becomes visible in environments with frequent service discovery, autoscaling, or ephemeral containers, where overly strict rules can block legitimate east-west traffic.

There is no universal standard for exactly where to place segmentation boundaries in every stack. In practice, the safest approach is to align zones to application trust levels, data sensitivity, and administrative function, then adjust based on observed traffic. Service meshes can help at the application layer, while network segmentation helps reduce blast radius at the infrastructure layer, but neither replaces identity-based authorization.

One recurring edge case is third-party integration. NHIMG’s State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means segmentation alone will not reveal risky access paths. The control plane still needs explicit trust decisions, because a segmented network does not stop an over-privileged identity from reaching every allowed endpoint inside its zone.

For this reason, best practice is evolving toward context-aware authorization plus microsegmentation, not microsegmentation as a substitute for zero trust. When identity is compromised or too broad, segmentation limits movement, but it cannot correct poor entitlements or long-lived secrets.

Related resources from NHI Mgmt Group

• How should security teams use SASE without losing Zero Trust discipline?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• Why do NHIs complicate zero trust and least privilege efforts?