Cloud identity management is failing without NHI governance

At a glance

What this is: This is Apono’s 10-point guide to cloud identity management, with the central finding that non-human identities and standing access are now the main governance gap in cloud environments.

Why it matters: IAM and NHI teams need this because cloud access drift, over-privilege, and unmanaged machine identities create direct paths to lateral movement and persistent exposure.

By the numbers:

• 57% of organizations experienced an API-related data breach in the past two years.
• 73% of those victims suffered three or more incidents.
• Only 5.7% of organizations have full visibility into their service accounts.
• 96% of organizations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Apono's guide to cloud identity management and NHI controls

Context

Cloud identity management is the discipline of deciding what human and non-human identities can access cloud resources, under what conditions, and for how long. In modern cloud environments, that problem is harder because service accounts, API tokens, workload roles, and CI/CD identities create the real execution layer while traditional network perimeters continue to fade.

The governance gap is not visibility alone. It is the combination of fast identity creation, broad default permissions, and weak cleanup that turns cloud access into standing risk. For NHI practitioners, the issue is whether access remains time-bound, contextual, and owned after deployment pressure increases.

Apono’s guidance is representative of a typical enterprise cloud posture rather than an edge case: teams understand least privilege conceptually, but operational drift keeps machine identities over-provisioned and under-reviewed.

Key questions

Q: How should security teams govern non-human identities in cloud environments?

A: Treat non-human identities as first-class identities with owners, lifecycle rules, and explicit expiry. The practical goal is to eliminate standing privilege, scope access to the task, and revoke access when the job ends. If the identity cannot be reviewed, rotated, and retired on schedule, it is a governance gap, not an implementation detail.

Q: When does just-in-time access make more sense than standing access?

A: Just-in-time access makes more sense whenever a role needs elevated permissions only briefly or intermittently. It reduces the time a stolen credential remains useful and lowers blast radius after misuse. If the business need is temporary, the entitlement should be temporary too. Standing access should be the exception, not the default.

Q: What is the difference between human IAM and NHI governance?

A: Human IAM centers on users who can authenticate interactively, challenge access, and be reviewed through periodic controls. NHI governance must handle identities that are created by systems, used by machines, and often never log in again. That means ownership, rotation, expiry, and cleanup matter more than password policy or MFA alone.

Q: Why do cloud identities create so much blast radius when compromised?

A: Cloud identities often have broad, reusable permissions across services, accounts, and pipelines. When one credential is stolen, the attacker may inherit access that was granted for convenience rather than necessity. The safest response is to reduce privilege by default and make elevated access expire automatically.

Technical breakdown

Why cloud identity management breaks down around NHIs

Cloud identity management often assumes identities are human, reviewable, and periodically challenged. Non-human identities break that model because they are created by automation, reused across pipelines, and left in place long after the original task ends. Service accounts, workload roles, and API tokens do not present interactive signals such as MFA, so the security model depends on scope, expiry, ownership, and monitoring. When those controls are weak, the identity becomes the attack path rather than the access method. The technical failure is not cloud scale by itself. It is durable permission without a reliable lifecycle.

Practical implication: Treat every non-human identity as a lifecycle-managed asset with an owner, expiry, and revocation path.

Standing access, JIT access, and blast-radius control

Standing access creates persistent trust, which means a stolen credential remains useful until someone notices and revokes it. Just-in-time access reduces that exposure by issuing permissions only for the duration of the task, then removing them automatically. In cloud environments, JIT is strongest when it is policy-driven and tied to context such as workload, environment, and role. The technical point is simple: access duration is part of security design, not just an operational convenience. If a pipeline or workload needs broad access only briefly, the access model should reflect that brief need.

Practical implication: Replace permanent elevated roles with expiring entitlements tied to task scope and environment.

Policy enforcement inside cloud and CI/CD workflows

Cloud identity controls work best when they are enforced where work actually happens. If approvals, provisioning, and revocation happen outside deployment and operations workflows, teams will route around them. Policy-driven access can be embedded into cloud platforms, CI/CD systems, and chat-based request flows so that authorization decisions are made at the point of need. This is not about adding friction. It is about moving the control plane closer to the action so that identity decisions remain auditable, contextual, and consistent across environments.

Practical implication: Push identity policy into deployment and operations workflows so teams do not bypass controls to ship code.

Threat narrative

Attacker objective: The attacker wants to turn one exposed machine credential into durable cloud access with enough privilege to move laterally and alter production systems.

1. Entry occurs when an API key, service account, or CI/CD credential is exposed in a cloud workflow, config file, or other reachable system.
2. Escalation follows when the compromised identity already has broader permissions than the task requires, allowing the attacker to move across accounts or services.
3. Impact comes from unauthorized cloud actions, data access, or infrastructure changes that persist until the credential is found and revoked.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Cloud identity management is now NHI governance in practice. The article’s core message is that cloud access cannot be governed as if humans are the primary actors. Service accounts, API keys, and workload roles now carry most execution authority, which means identity policy has to account for machine lifecycle, not just user provisioning. Teams that treat NHIs as secondary inventory will miss the real control surface. Practitioners should align cloud IAM with explicit NHI ownership and expiry.

Standing privilege is the structural cloud risk, not a configuration nuisance. Long-lived permissions are what make credential exposure dangerous, because a stolen key remains useful long after the triggering job is forgotten. Just-in-time access is valuable here not because it is fashionable, but because it shortens the attacker’s window and limits blast radius. Teams should measure access duration as a control variable, not a convenience feature.

Policy embedded in workflow is the only scale-safe model for cloud access. Manual approvals and detached ticket queues do not keep pace with cloud change, especially when pipelines and bots are creating access faster than people can review it. The field is moving toward policy enforcement at the point of execution, where authorization can be contextual and auditable. Practitioners should move controls into the systems that issue access, not around them.

Identity sprawl in cloud environments is an operating model problem, not just a tooling problem. The article correctly points to visibility, ownership, and cleanup, but those controls only work when teams define who owns each non-human identity and what event retires it. Without that discipline, permissions drift becomes normal. Practitioners should treat NHI inventory, review, and decommissioning as standard operational control, not audit cleanup.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For the deeper control model, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding guidance.

What this signals

NHI trust debt: the longer cloud teams leave machine identities unowned and unexpired, the more the access model drifts away from least privilege. With 70% of organisations granting AI systems more access than they would give a human employee performing the same job, according to the 2026 Infrastructure Identity Survey, the cloud governance problem is already expanding beyond traditional service accounts.

For security programmes, the next practical step is to merge cloud IAM reviews, secrets hygiene, and NHI lifecycle controls into one operational cadence. Teams that keep those reviews separate will continue to miss the relationship between access sprawl and incident recurrence.

Zero Trust for cloud access only works when policies can be enforced at the identity layer and at the point of execution. That means credential expiry, context checks, and ownership reviews need to be measurable controls, not aspirational guidance.

For practitioners

• Inventory every non-human identity Create a single inventory that includes service accounts, workload roles, API tokens, CI/CD identities, and secrets locations across cloud, SaaS, and Kubernetes environments.
• Replace standing permissions with expiring access Use just-in-time approval and automatic expiry for elevated cloud access, especially for production systems and pipeline credentials.
• Assign explicit owners to machine identities Require a named owner, purpose, and retirement trigger for each NHI so orphaned identities do not survive pipeline or service changes.
• Enforce policy inside deployment workflows Embed access requests and approvals into CI/CD and operations tooling so engineers do not need to leave the workflow to request temporary access. Reference the Ultimate Guide to NHIs for lifecycle controls.

Key takeaways

• Cloud identity management now fails most visibly where non-human identities are over-privileged and under-owned.
• The scale problem is measurable, with API-related breaches and persistent machine access showing that standing privilege remains a common weak point.
• Practitioners should shift from static access review toward lifecycle-based NHI governance, especially for cloud and CI/CD identities.

Key terms

• Non-Human Identity: A non-human identity is any machine or workload credential used to access systems on behalf of software rather than a person. In cloud environments, this includes service accounts, API keys, tokens, certificates, and automation identities that often outlive the job they were created for.
• Standing Privilege: Standing privilege is persistent access that remains valid until someone manually removes it. In cloud and NHI governance, it increases blast radius because stolen or forgotten credentials can be reused long after the original task, project, or pipeline change has ended.
• Just-in-Time Access: Just-in-time access grants permissions only when they are needed and removes them after a defined period or task. For NHI governance, it is a control pattern that reduces exposure by replacing durable entitlements with time-bound access tied to context and purpose.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.

Deepen your knowledge

Cloud identity management and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building cloud access governance in a fast-moving environment, it is worth exploring.

This post draws on content published by Apono: 10 Essential Tips For Cloud Identity Management. Read the original.