Zero trust and microsegmentation expose identity control gaps

At a glance

What this is: This explainer compares zero trust and microsegmentation and finds that both depend on clear identity control boundaries, not just network design.

Why it matters: IAM teams need to align authentication, authorisation, and segmentation rules so identity policy does not drift away from the assets and paths it is meant to protect.

Context

Zero trust is an access model that verifies users and devices before granting only the access they need, while microsegmentation narrows where network movement is possible after access is granted. The article's core point is that these are related controls, but they solve different parts of the security problem and can be misused if identity scope is vague.

For identity programmes, the real question is not whether an environment uses zero trust or microsegmentation. It is whether IAM, authorisation policy, and network containment are aligned tightly enough that access decisions match the assets, sessions, and pathways they are supposed to protect.

Key questions

Q: What breaks when microsegmentation is used without strong IAM controls?

A: Microsegmentation alone cannot fix over-privileged identities, weak credential hygiene, or missing offboarding. It may slow lateral movement, but if the identity is already broadly authorised, the attacker still has legitimate paths to sensitive systems. The result is contained compromise, not prevented compromise.

Q: Why does zero trust still need microsegmentation in practice?

A: 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.

Q: How do security teams know if microsegmentation is actually reducing blast radius?

A: They should test whether a compromised asset can reach adjacent systems, whether denied flows are being logged, and whether containment happens without manual rework. If lateral movement still succeeds across critical segments, the control is not reducing blast radius in a meaningful way.

Q: Should IAM teams treat service accounts differently in zero trust designs?

A: Yes. Service accounts, tokens, and other non-human identities often have broader and longer-lived access than human users, so they can undermine zero trust if their scope is not tightly governed. IAM teams should design their trust boundaries around these identities explicitly rather than assuming human access patterns apply.

Technical breakdown

How zero trust and microsegmentation differ

Zero trust is an identity-first access model. It assumes every request must be authenticated and authorised before it reaches a protected resource, so the control point is the access decision itself. Microsegmentation is a containment technique. It breaks the network into smaller security zones so that movement after initial access is constrained. The two can reinforce each other, but they are not interchangeable. A team can have strong segmentation and still allow overbroad access, or strong authentication and still leave lateral movement open. The practical issue is deciding which control owns the trust boundary at each layer.

Practical implication: Map each access path to the control that actually governs it, rather than assuming network segmentation substitutes for authorisation design.

Why segmentation can fail without identity scope

Microsegmentation reduces blast radius only when identity permissions are already narrow enough to make the segments meaningful. If users, workloads, or service identities carry broad entitlements, segmentation may only slow movement instead of preventing it. This is why identity scope and network scope need to be designed together. In practice, the hidden failure mode is policy drift: segmentation rules describe where traffic may go, while IAM still permits identities to reach more than they should. That mismatch creates a false sense of containment because the access model and the network model are speaking different languages.

Practical implication: Review whether segmented zones are backed by equally narrow identity permissions, especially for privileged and service accounts.

Where zero trust becomes an IAM governance problem

Zero trust is often presented as a network architecture, but in practice it becomes an IAM governance issue because the trust decision depends on identity assurance, authentication strength, and least privilege. If access policies do not reflect current roles, devices, or workload context, the zero-trust label adds little operational value. The same is true for non-human identities, where tokens, service accounts, and machine credentials can outlive the intended access window. That makes lifecycle control, revocation, and entitlement review part of the zero-trust control plane, not separate hygiene tasks.

Practical implication: Treat entitlement governance and credential lifecycle as part of zero-trust implementation, not as downstream admin work.

NHI Mgmt Group analysis

Zero trust and microsegmentation are complementary controls, but only if IAM owns the trust boundary: network containment without identity precision produces a brittle security model. Zero trust determines who or what may reach a resource, while microsegmentation determines how far movement can continue after access is granted. The practical conclusion is that segmentation must follow identity policy, not replace it.

Microsegmentation without tight entitlement governance creates a false containment story: organisations often assume smaller network zones automatically reduce exposure. In reality, overprivileged users, workloads, and service identities can still traverse too much of the environment inside those zones. That makes privilege scope, not just network design, the deciding factor in whether segmentation reduces blast radius.

Identity control gaps become visible when access policy and network topology diverge: the article shows why authentication, authorisation, and segmentation must be designed as one control system. When they are managed separately, teams can satisfy one architecture and still leave the other weak. The result is policy drift, where the environment looks segmented but access remains broader than intended.

Zero-trust programmes should be measured by effective access restriction, not by deployment of a label: a zero-trust claim is only credible when identity assurance, entitlement review, and resource scoping are aligned. That is especially important for NHIs and service identities, where access often persists quietly and expands through operational convenience. The practitioner takeaway is to evaluate control integrity, not architecture naming.

Identity blast radius: the article points to a governance concept that matters beyond this one explainer. The size of an identity's practical blast radius is determined by the overlap between authentication confidence, authorisation scope, and segmentation boundaries. When those three diverge, the organisation has more trust than its policy intends, and practitioners need to reset the model.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Identity blast radius: the practical size of an identity's reach is determined by how authentication, authorisation, and segmentation overlap. When those layers are managed separately, teams can claim zero trust while still preserving excessive access paths, so the first programme question is where those boundaries are actually enforced.

Microsegmentation matters most when the identities inside the environment are already well-scoped. For IAM and security architects, that means the control conversation should start with entitlement precision, then move to network containment, because a segmented network with broad permissions still leaves too much room for movement.

For practitioners

• Define trust boundaries by identity type Separate human users, service identities, and administrative accounts into distinct access paths so zero trust rules reflect actual operating risk.
• Align segmentation with entitlement scope Check that each network segment has matching least-privilege permissions for the identities that can reach it, including workloads and automation accounts.
• Audit privileged and non-human identities first Start with service accounts, tokens, and elevated users because those identities can undermine both zero trust and microsegmentation when scope is too broad.
• Test containment under lateral movement assumptions Validate whether an identity that enters one zone can still reach adjacent resources through allowed policy paths, not just through the network perimeter.

Key takeaways

• Zero trust and microsegmentation solve different control problems, and neither is sufficient on its own when identity scope is unclear.
• The governance gap is the mismatch between access entitlements and network containment, especially for privileged and non-human identities.
• Practitioners should measure whether identity policy and segmentation boundaries line up, then tighten the overlap where they do not.

Key terms

• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Microsegmentation: A network control approach that divides environments into small security zones with explicit rules between them. Its purpose is to limit lateral movement and reduce blast radius when an identity, workload, or device is compromised.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Overprivileged Identity: An overprivileged identity has more access than its workload or service actually needs. In NHI environments, this often happens through default cloud permissions, role accumulation, or poor review discipline. The practical risk is a larger blast radius if the identity is compromised or misused.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.