Without microsegmentation, Zero Trust loses one of its main containment mechanisms. An attacker who gets past identity checks can still move laterally across poorly separated systems, reach critical workloads, and disrupt more of the environment than necessary. In practice, the model becomes easier to bypass because the network remains too open inside the perimeter, even if authentication is strong.
What Zero Trust still needs microsegmentation to do
zero trust is strongest when identity, device state, policy enforcement, and network containment all work together. Microsegmentation supplies the internal blast-radius control that keeps a verified session from becoming a free pass across the estate. Without it, the architecture may verify who or what is asking, but still allow that actor to reach far more than it should.
This is why Zero Trust is not just an access decision problem. It is also a movement-control problem. If east-west traffic remains broadly permissive, a single compromised account, token, workload, or admin path can still fan out into systems that should have been isolated by policy.
That containment layer is especially important in environments that rely on NHIMG’s Ultimate Guide to NHIs because excessive reach often comes from credentialed access, not from perimeter bypass. The same principle shows up in workload identity designs such as Guide to SPIFFE and SPIRE, where identity is only part of the story and traffic scope still has to be constrained deliberately.
What breaks operationally when the inside stays too open
Without microsegmentation, the main failure mode is lateral movement. An attacker does not need to keep defeating control after control if one authenticated foothold can reach file shares, management planes, databases, CI/CD systems, or other adjacent workloads. The result is not simply a weaker policy, but a weaker assumption about how far any one compromise can spread.
The second break is policy precision. Zero Trust depends on denying implicit trust, yet flat or loosely separated networks preserve the old assumption that anything inside is comparatively safe. That mismatch creates gaps between policy intent and actual reach, which makes the environment harder to reason about, harder to monitor, and harder to contain during incident response.
At enterprise scale, the issue is compounded by identity sprawl and privileged access sprawl. NHIMG’s The 2026 Infrastructure Identity Survey notes that 70% of organisations grant AI systems more access than a human employee doing the same job, which is a useful reminder that overreach is often normalised before it is noticed. If the access layer is broad and the network layer is broad, compromise becomes a routing problem for the attacker, not a containment problem for the defender.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 |
|---|---|---|
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection / Segmentation | Microsegmentation is the containment mechanism this question hinges on. |
| PL-2 — Policy and Procedure | Zero Trust requires explicit access and containment policy, not implicit internal trust. | |
| Recommendation — Enforce segmented policy boundaries to limit east-west movement after a foothold. Define and maintain policy that limits internal reach to the minimum required connections. | ||
| CIS Controls v8 | 13.7 — Network Segmentation | Segmentation is the prescriptive control that reduces lateral movement in this scenario. |
| Recommendation — Segment networks and restrict east-west traffic between systems and zones. | ||
| NIST CSF 2.0 | PR.AC-5 — Network Integrity is Protected | Open internal paths weaken the integrity assumptions Zero Trust needs to enforce. |
| PR.AC-4 — Access Permissions Managed | The question concerns how access should be constrained once identity is accepted. | |
| Recommendation — Protect internal network integrity with restrictive trust boundaries and traffic controls. Limit permissions so authenticated access does not translate into broad system reach. | ||
Practitioner Guidance
What to prioritise: Treat microsegmentation as the control that proves Zero Trust can actually contain a breach, not as an optional optimisation. Start with the most sensitive workloads, administrative paths, and shared services that create the largest blast radius if reached laterally.
What to verify: Test whether a compromised but authenticated principal can still enumerate or contact adjacent systems that are not needed for its function. If it can, your Zero Trust posture is still relying too much on identity checks and not enough on reach limitation.
What good looks like: A valid login or trusted workload identity should allow only the minimum set of east-west communications required for that role, with every other path denied by policy and observable in logs when blocked.
Practitioner takeaway: Zero Trust without containment is closer to authenticated access than true trust reduction, so the practical question is not whether identities are verified, but whether compromise stays small when verification fails.
Related resources from NHI Mgmt Group
- What breaks when organisations try to run Zero Trust without full certificate visibility?
- What breaks when organisations try to extend zero trust to web access without browser-level controls?
- What breaks when organisations try to adopt Zero Trust without asset visibility
- How should organisations implement Zero Trust without breaking existing access workflows?
