Zero trust IAM fails when standing privileges remain in place

At a glance

What this is: This is a practitioner analysis of zero trust identity and access management, with the central finding that login-time verification is not enough when standing permissions, broad roles, and manual approvals still govern access.

Why it matters: It matters because IAM and NHI teams have to control access continuously across human and non-human identities, not just at the point of authentication.

By the numbers:

• 59% of organizations now rank insecure identities and risky permissions as their number one cloud security risk.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Apono's analysis of zero trust identity and access management principles

Context

Zero trust IAM is the discipline of treating every access request as uncertain until it is verified, authorized, and scoped for the current task. The article argues that many teams still rely on login-time checks while leaving broad permissions in place, which creates an NHI governance problem as much as a human access problem.

That gap matters because cloud, Kubernetes, CI/CD, databases, and third-party access paths all depend on identities that can outlive the work they were created for. In practice, the model fails when standing permissions, shared roles, and manual ticket queues remain the real control plane instead of policy-driven, time-bound access.

For security architects, the operational question is not whether zero trust is desirable. It is whether the organization can enforce least privilege and revocation consistently across human users, service accounts, runners, and workloads without turning every request into a delay.

Key questions

Q: How should security teams implement zero trust IAM in cloud-native environments?

A: Start by enforcing real-time authorization on every privileged request, then replace standing access with scoped, time-bound elevation. Apply the same policy logic across cloud consoles, Kubernetes, databases, CI/CD, and internal apps so exceptions do not become the default control model. Consistency matters more than a single tool choice.

Q: Why do NHIs complicate zero trust IAM programs?

A: NHIs complicate zero trust because they often outnumber human identities, operate automatically, and carry permissions that are rarely reviewed with the same discipline as employee access. If teams treat service accounts and runners as exempt from zero trust, they preserve the exact standing privilege patterns that attackers exploit.

Q: What is the difference between just-in-time access and role-based access control?

A: Role-based access control assigns permissions in advance based on a role, while just-in-time access grants elevated permissions only for a specific task and a limited time. RBAC is useful for baseline access. JIT is better for high-risk privilege because it reduces the duration and scope of exposure.

Q: When does zero trust IAM create more friction than risk reduction?

A: Zero trust creates friction when teams try to apply it with manual approvals, brittle exceptions, or poorly designed workflows that slow engineers without actually reducing exposure. If a control is too slow to use, people route around it. The goal is policy-driven access that is both restrictive and operationally workable.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero trust IAM is becoming a lifecycle problem, not an authentication problem. The article is right to move beyond login checks, but the deeper issue is that most organizations still treat access as something granted once and reviewed later. That model does not hold when workloads, runners, and API-driven systems create access at machine speed. Practitioners should treat identity lifecycle control as the primary zero trust workstream.

Just-in-time access is only effective when it is paired with strong revocation discipline. Temporary elevation reduces exposure only if the underlying credentials actually expire, and if approvals are tied to policy rather than convenience. The operational failure mode is familiar: a temporary grant becomes a de facto standing grant because no one owns cleanup. Teams should measure revocation latency, not just approval speed.

Non-human identities must be governed as first-class production identities. Service accounts, CI/CD runners, and cross-cloud roles often carry the most dangerous permissions because they are embedded in automation and rarely challenged by normal user workflows. Zero trust does not work if those identities bypass review, context, or expiry. The practitioner conclusion is simple: a zero trust programme that ignores NHIs is incomplete.

Policy consistency matters more than access channel variety. Cloud consoles, Kubernetes, databases, SSH, and internal apps all look different to engineers, but they should not produce different security expectations. Fragmented rules create shadow exceptions and force teams into manual workarounds. The right response is a unified access policy layer that applies the same standards wherever privileged action occurs.

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 makes privilege review and revocation materially harder to execute at scale.
• For the access-lifecycle angle, the NHI Lifecycle Management Guide shows where provisioning, rotation, and offboarding controls usually break down first.

What this signals

Ephemeral privilege debt: zero trust programmes often fail not because teams reject the model, but because they accumulate access that should have expired weeks earlier. With only 5.7% of organisations reporting full visibility into their service accounts, the governance gap is structural rather than procedural, and it affects both human and machine access paths.

Practitioners should expect zero trust work to shift from authentication controls toward lifecycle enforcement, especially where access is granted through cloud roles, CI/CD automation, and service accounts. The relevant question is no longer whether the identity was verified once, but whether the permission still needs to exist now.

That is why the 52 NHI Breaches Analysis and the NIST SP 800-207 Zero Trust Architecture guidance remain useful together. One shows how identities are abused in practice, while the other defines the continuous verification model teams should use to narrow exposure.

For practitioners

• Inventory standing privileges across all identity types Map human accounts, service accounts, API keys, tokens, and workload roles to the permissions they actually hold. Look for dormant admin access, shared accounts, and roles that exist outside normal change control so you can reduce the blast radius before an incident forces the issue.
• Replace durable elevation with time-bound workflows Route privileged requests through approval-based JIT flows that expire automatically when the task ends. Use short-lived credentials for production access, and make revocation the default outcome rather than an afterthought.
• Apply the same policy engine to NHIs and users Do not let CI/CD runners, service accounts, and third-party integrations bypass the controls used for human access. A consistent policy layer reduces exceptions and helps prevent machine identities from becoming the quiet back door into production.
• Audit access paths that still depend on manual tickets Identify environments where engineers wait on ticket queues for routine elevation, then replace those paths with approved self-service where policy conditions are met. Manual gates often create both delay and shadow access workarounds.

Key takeaways

• Zero trust IAM fails when teams stop at login-time verification and leave broad permissions in place.
• NHIs amplify the problem because service accounts, tokens, and runners often keep privileges long after the task is complete.
• The practical response is to enforce time-bound access, consistent policy, and revocation across every identity type and platform.

Key terms

• Standing Privilege: Standing privilege is access that remains continuously available after it is first granted. In NHI governance, this is one of the clearest sources of overexposure because the permission often outlives the task, the workload, or the person who originally needed it.
• Just-In-Time Access: Just-in-time access is a model for granting elevated permissions only when they are needed and removing them automatically afterward. It is used to reduce the exposure window for both human administrators and non-human identities that require temporary operational authority.
• Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
• Workload Identity Federation: Workload identity federation lets automation exchange one trusted identity for another short-lived credential without storing static secrets. It is a common pattern for CI/CD and cloud workloads because it reduces secret sprawl and limits the damage if an automation path is compromised.

Deepen your knowledge

Zero trust identity and access management is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are standardising access controls across human and non-human identities, it is worth exploring.

This post draws on content published by Apono: 7 Principles of Zero Trust Identity and Access Management. Read the original.