Why does zero trust still need microsegmentation in practice?

Zero trust verifies access decisions, but it does not automatically limit where a valid session can go once approved. Microsegmentation adds the runtime boundary that constrains internal movement, which matters when compromised identities, tokens, or endpoints are already inside the environment. Together, they reduce the blast radius of a successful breach.

Why This Matters for Security Teams

zero trust is an access decision model, but it does not stop a valid identity from moving too far once it is admitted. That distinction matters because lateral movement often happens after authentication, when a user, workload, or compromised secret already has a foothold. Microsegmentation adds a runtime constraint that narrows who can talk to what, which is especially important in hybrid clouds, east-west traffic, and environments with shared service accounts. NHI Management Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

Practitioners often overestimate the protection provided by identity checks alone, especially when tokens, API keys, or service accounts are already active inside the environment. The control gap is not theoretical: a session can be legitimate at the edge and still be dangerous across internal tiers. Current guidance in NIST SP 800-207 Zero Trust Architecture treats policy enforcement as continuous, not one-time, which is why segmentation remains part of practical zero trust design. In practice, many security teams discover the need for microsegmentation only after a credential compromise has already enabled internal traversal.

How It Works in Practice

Microsegmentation works by defining smaller trust zones and enforcing policy between them, so that a workload, user, or service can reach only the resources it genuinely needs. In zero trust programs, this typically complements identity-aware policy enforcement rather than replacing it. The identity layer decides whether a request is allowed; segmentation decides where that allowed request can go next. For NHI-heavy environments, that distinction is critical because service accounts and API keys often have machine speed access across multiple systems.

In operational terms, teams usually combine network controls, host controls, workload identity, and observability to make this usable. A practical implementation often includes:

• mapping application dependencies before tightening rules, so segmentation does not break legitimate east-west traffic;
• tagging workloads by function or sensitivity, then enforcing allowlists between zones;
• using strong workload identity and secret handling so policy can follow the workload, not just the IP address;
• logging denied and unusual flows into SIEM for detection, investigation, and tuning.

This is where NHI governance becomes directly relevant. If secrets are poorly managed, segmentation can only limit the blast radius after compromise, not prevent the compromise itself. NHI Mgmt Group’s Guide to SPIFFE and SPIRE is useful here because workload identity gives segmentation policies a more durable basis than static network location. NIST SP 800-53 Rev. 5 also supports this approach through access, audit, and boundary protections that make segmentation measurable rather than ad hoc. These controls tend to break down when legacy applications depend on broad flat-network assumptions because dependency mapping is incomplete and traffic owners cannot clearly define allowed paths.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance blast-radius reduction against deployment complexity and troubleshooting time. That tradeoff is most visible in older data centers, highly dynamic Kubernetes clusters, and SaaS-connected environments where traffic paths change quickly. Best practice is evolving toward policy that follows the workload, but there is no universal standard for how granular microsegmentation should be in every environment.

Some teams can use coarse application-tier segmentation and still achieve meaningful risk reduction. Others, especially those with privileged NHIs, regulated data, or shared control planes, need much finer boundaries. This is also where zero trust and microsegmentation are sometimes confused: zero trust is the decision framework, while segmentation is one of the enforcement mechanisms that keeps a valid identity from becoming an enterprise-wide incident. The strongest programs treat them as layered controls, not competing approaches.

For identity-heavy environments, the key exception is when workload identity and secret hygiene are weak. In that case, microsegmentation helps, but it cannot compensate for broad privilege or unmanaged tokens. That is why the Ultimate Guide to NHIs — Standards is a useful reference point for aligning segmentation with governance, lifecycle, and least privilege. The practical limit is clear: segmentation works best when the environment can express trust boundaries precisely, and it becomes harder to maintain when applications, identities, and routing are tightly coupled.

Related resources from NHI Mgmt Group

• Why do AI agents complicate zero trust architecture in practice?
• How should security teams implement Zero Trust SaaS in practice?
• What is the difference between SASE and Zero Trust in practice?
• How should security teams use microsegmentation with zero trust?