Zero trust IAM still relies on identity controls that break

At a glance

What this is: This is a Zero Trust IAM primer that argues continuous verification, least privilege, microsegmentation, MFA, and just-in-time access are the core controls for reducing unauthorised access and lateral movement.

Why it matters: It matters because IAM teams have to govern humans, non-human identities, and eventually autonomous actors with the same access principles, even though the controls behave differently across each.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Zluri's guide to zero trust identity and access management

Context

Zero trust identity and access management is an access governance model that assumes trust must be continuously earned, not inherited from network location or prior authentication. In practice, that means identity, device context, and privilege scope all have to be checked before access is granted, whether the actor is a person or a machine.

The article argues that traditional perimeter-based trust is no longer enough in cloud, mobile, and remote-work environments. That is directionally correct for IAM teams, but the practical challenge is that the same zero trust language is often applied to human users, service accounts, and workload identities without distinguishing how each one should be governed.

For non-human identities, the important question is not whether zero trust is desirable, but whether the organisation can actually enforce revocation, segmentation, and continuous validation at machine speed. That is where most identity programmes still break down, even before autonomous behaviour enters the picture.

Key questions

Q: How should security teams implement zero trust IAM across human and machine identities?

A: Start by separating identity classes and governing each one with controls that match its behaviour. Human users need strong authentication and context-aware access. Machine identities need lifecycle control, credential rotation, and revocation that actually works in automation pipelines and cloud services. Zero trust fails when the same policy is applied everywhere without operational differences.

Q: Why do service accounts and API keys create problems for zero trust programmes?

A: Because they often carry standing access, are reused across systems, and are not reviewed as rigorously as human accounts. That means a compromise can persist beyond the intended task and move laterally with little friction. Zero trust only contains that risk if machine identities are inventoried, scoped tightly, and revoked when they are no longer needed.

Q: What breaks when least privilege is not enforced in a zero trust model?

A: The model stops containing blast radius. If an identity has broad reach, strong authentication only proves who or what entered the environment, not how far that actor can move once inside. Least privilege has to be enforced at the entitlement layer and the network layer, or compromise still spreads across the environment.

Q: Who is accountable when zero trust controls fail to stop unauthorised access?

A: Accountability sits with the identity, access, and platform owners who defined the trust boundary and the revocation process, not just with the security team. In practice, failures usually come from unclear ownership of entitlements, missing lifecycle control for machine identities, or policies that were never tested against real operational conditions.

Technical breakdown

Continuous verification in zero trust IAM

Continuous verification means access is not a one-time event. The identity must be checked at request time, and often again during the session, using signals such as device posture, context, and policy state. In zero trust architecture, this reduces reliance on static trust granted at login or provisioning. For IAM, the technical issue is that verification must remain consistent across SSO, privileged access, and application entitlements, or policy drift creates false confidence. For non-human identities, the same model applies to tokens, service accounts, and workload identities, but the verification points are different because machines do not authenticate like people.

Practical implication: map every access path to a verification point and confirm that machine identities are re-evaluated at the same control layers as users.

Least privilege, microsegmentation, and blast radius control

Least privilege limits what an identity can do, while microsegmentation limits where that identity can move. Together they reduce blast radius when credentials are stolen, misused, or over-granted. In identity terms, privilege scope is the real control surface, not just authentication strength. If an account has broad entitlements or can laterally reach adjacent systems, strong login controls do little to contain the compromise. This matters most for service accounts and workload identities, which are frequently provisioned for speed and then left with persistent access that outlives the task they were created for.

Practical implication: review privilege scope and network reach together, because access reduction fails if segmentation and entitlements are governed separately.

Just-in-time access and time-bound authority

Just-in-time access gives an identity elevated permissions only for the duration of a task, then removes them. That pattern is useful because it shortens the window in which abuse can occur and reduces standing privilege. Technically, JIT works best when coupled with approval, expiry, and logging so access can be reconstructed after the fact. But JIT is not a universal fix. It is strongest when the environment can enforce clean start and clean end states. For humans, that is an operational process. For NHI and workload identities, it becomes a lifecycle and token-management problem.

Practical implication: use JIT where you can enforce expiry and revocation reliably, then verify that the underlying identity lifecycle can actually support it.

NHI Mgmt Group analysis

Zero trust IAM is still an identity governance model, not a control outcome. The article correctly frames continuous verification, least privilege, and segmentation as core principles, but those principles only work if identity state is accurate and revocation is enforceable. In practice, the model fails when access is broader than intended, stale, or impossible to trace across users, service accounts, and tokens. Practitioners should treat zero trust as a governance discipline that must be proved in operations, not assumed from policy language.

Identity blast radius is the real zero trust problem. The article focuses on unauthorised access and lateral movement, which are the symptoms. The deeper issue is that many programmes still cannot bound what an identity can reach once compromise occurs, especially in cloud and SaaS estates. That is why privilege scope, segmentation, and access expiry have to be assessed together. The practical conclusion is that zero trust only works when the organisation can materially shrink the blast radius of every identity type.

NHI governance is the missing layer beneath zero trust language. The article speaks to users and devices, but the strongest operational failure mode in modern estates is often machine identity sprawl. Service accounts, API keys, and tokens are frequently outside the same governance cadence as human access, even though they sit inside the zero trust trust chain. That gap is exactly where visibility, rotation, and offboarding become decisive. Practitioners should align zero trust programmes with NHI lifecycle control rather than treating them as separate efforts.

Continuous verification breaks down when access is assumed to persist long enough to be reviewed. That assumption fits human IAM, but it becomes fragile as machine and agent identities multiply and session boundaries shorten. A programme built only around periodic review cannot reliably govern identities that are provisioned quickly, used briefly, and forgotten just as fast. The implication is that zero trust maturity now depends on lifecycle governance, not just policy enforcement.

For autonomous actors, zero trust would expose an assumption collapse rather than just a missing control. Identity controls assume access is stable enough to be granted, observed, and reviewed. If an actor can choose actions, tools, and timing independently, that assumption fails because authority can appear and disappear within the same execution window. Practitioners should recognise that the governance model itself must change when the actor becomes autonomous, not simply add more verification steps.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most zero trust programmes are trying to govern what they cannot fully see.
• For the lifecycle angle, read NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that make zero trust enforceable in practice.

What this signals

Identity programmes are moving from authentication-centric thinking to lifecycle-centric governance. Once access is time-bound and continuously verified, the real programme question becomes whether identities can be inventoried, scoped, and revoked with operational certainty. The organisations that can answer that question will have a materially stronger zero trust posture than those relying on policy statements alone.

Zero trust is becoming a control architecture for non-human identities as much as for people. That shift matters because machine accounts do not fail in the same way as human users. Their privileges accumulate through provisioning, integrations, and service dependencies, so governance has to focus on rotation, ownership, and offboarding as active controls, not administrative cleanup.

The next maturity step is to treat zero trust as a test of identity fidelity. If access records, segmentation, and revocation are not aligned, the model is only partially enforced. The practical signal to watch is whether your platform can prove that an identity could not have accessed more than it needed at any point in the session.

For practitioners

• Map every zero trust control to an identity type Separate human access, service accounts, workload identities, and any AI-driven execution paths before applying policies. The same control name can hide very different governance requirements, especially around verification, expiry, and revocation.
• Reduce standing privilege before extending zero trust claims Identify accounts that retain access after the task ends, then remove persistent entitlements, especially for machine identities that are rarely reviewed with the same rigour as people.
• Tie segmentation to entitlement scope Review whether a credential can both authenticate and move laterally across adjacent systems. If it can, microsegmentation is not fully protecting the identity surface.
• Make revocation operationally testable Validate that tokens, service accounts, and elevated human access can actually be revoked on demand, and confirm that logging proves the revocation happened before the next access event.

Key takeaways

• Zero trust IAM reduces risk only when identity state, privilege scope, and revocation are governed together.
• The scale of machine identity overprivilege means most enterprises still have a large gap between zero trust policy and operational reality.
• Practitioners should treat lifecycle control and blast-radius reduction as the real indicators of zero trust maturity.

Key terms

• Zero Trust Identity And Access Management: A security model that grants access only after continuous verification of identity, device, and context. It assumes no implicit trust based on network location and applies least privilege, segmentation, and time-bound access to reduce the impact of compromise across human and machine identities.
• Just-in-Time Access: A temporary access pattern that grants elevated permissions only for the duration of a task. It reduces standing privilege by forcing access to expire automatically, but it only works well when identity lifecycle controls, approvals, and revocation are reliable enough to enforce the end of access.
• Microsegmentation: A network and access design that splits an environment into smaller security zones with separate policy boundaries. It limits lateral movement by preventing one compromised identity from automatically reaching other systems, but it must be paired with entitlement governance to be effective.
• Continuous Verification: An access control approach that re-checks identity, device, and policy conditions during the session rather than only at login. It strengthens zero trust by making access conditional over time, not just at the point of authentication, and it is especially important when workloads and service accounts are involved.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Zero Trust Identity and Access Management: A 101 Guide. Read the original.