Identity and access management best practices are lagging cloud sprawl

At a glance

What this is: This is a practitioner guide to identity and access management best practices, with the main finding that access sprawl and weak lifecycle controls are the biggest gaps.

Why it matters: It matters because the same governance failures now affect human users, service accounts, and AI-driven access patterns, so IAM teams need controls that work across all three identity types.

By the numbers:

• 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.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Zluri's IAM best practices guide for cloud access control

Context

Identity and access management is the discipline of deciding who or what can reach a system, when access should exist, and how that access is removed. In cloud-heavy environments, the problem is no longer limited to employee logins. Service accounts, API keys, temporary credentials, and automated workflows all create identity sprawl that existing governance models often struggle to keep in view.

The article argues for classic IAM controls such as least privilege, multi-factor authentication, access reviews, and automation, but the deeper issue is lifecycle control. If access is granted faster than it is reviewed, and reviewed faster than it is revoked, the programme produces a false sense of control. That is a common starting point for many enterprises, not an edge case.

Key questions

Q: How should security teams implement least privilege in cloud IAM environments?

A: Start by defining the minimum access needed for each role, then restrict higher-risk actions with attributes such as environment, time, and resource sensitivity. Review exceptions regularly and remove inherited permissions that are no longer needed. Least privilege works only when entitlement scope is continuously validated, not when it is written once and forgotten.

Q: Why do service accounts and API keys create more IAM risk than many teams expect?

A: They often operate outside human review cycles, remain valid for long periods, and are reused across systems without clear ownership. That combination makes them easy to forget and hard to retire. The risk is not just compromise, but privilege that outlives the task or system that originally needed it.

Q: How do organisations know whether access reviews are actually working?

A: Look for declining numbers of stale entitlements, fewer exceptions, and faster revocation after role changes or offboarding events. If reviews only produce paperwork but do not reduce dormant access, they are not improving control. Effective reviews change the entitlement landscape, not just the audit trail.

Q: What is the difference between RBAC and ABAC in practical IAM governance?

A: RBAC assigns access by role, which keeps administration simpler and more consistent. ABAC adds conditions such as location, department, or data sensitivity, which makes access more precise. In practice, teams usually need both: RBAC for baseline structure and ABAC for narrowing high-risk permissions.

Technical breakdown

Zero-trust access verification in cloud IAM

Zero-trust access verification means every request is evaluated instead of trusting a previous login or network location. In cloud environments, this matters because users, contractors, workloads, and external integrations can all retain access long after the original trust decision. The article’s emphasis on continuous verification reflects a basic IAM truth: static trust breaks down once identities become distributed across SaaS, infrastructure, and automation layers.

Practical implication: tie access decisions to current context, not inherited trust from an earlier session or device.

RBAC, ABAC, and least privilege in practice

Role-based access control assigns permissions through job functions, while attribute-based access control uses policy conditions such as department, location, or resource sensitivity. The two often need to work together because RBAC alone becomes too coarse and ABAC alone can become too complex. The article’s treatment of least privilege is sound, but the governance challenge is making privilege precise enough to be useful without turning administration into manual exception handling.

Practical implication: define the smallest role set that covers core duties, then use attributes to narrow access for higher-risk actions.

Lifecycle management for access reviews and offboarding

IAM fails most visibly at the edges of the identity lifecycle. Provisioning is easy to automate, but revocation, offboarding, and access review are where access often lingers. That is especially true for API keys, service accounts, and temporary contractor access, where ownership can be unclear and review cadences are too slow for the pace of change in cloud operations.

Practical implication: build revocation and review into the same workflow as provisioning, so access cannot outlive the business need that created it.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Standing access is the real failure mode in most IAM programmes. The article focuses on least privilege, MFA, and automation, but the underlying problem is that many organisations still tolerate access that persists beyond the task that justified it. That creates auditable policy on paper and ungoverned privilege in practice. Practitioners should treat standing access as the baseline risk, not the exception.

Lifecycle drift: access is created faster than it is retired, and the gap widens in cloud and contractor-heavy environments. The article repeatedly points to provisioning, access modification, and deprovisioning, which is exactly where programmes fail under load. When offboarding is manual or delayed, identities continue to carry privilege after role changes, project completion, or vendor exit. The conclusion is straightforward: governance quality is determined by revocation speed, not by approval volume.

Least privilege is not a policy statement, it is an operational boundary. Combining RBAC and ABAC only helps if the organisation can enforce narrow access consistently across applications, infrastructure, and temporary use cases. In practice, many teams define roles well but cannot sustain precision across exceptions and edge cases. Practitioners should expect privilege creep unless access scope is continuously re-validated.

Automation improves IAM only when it shortens the lifecycle of access decisions. The article treats automation as a way to reduce manual error, which is correct, but automation that simply accelerates provisioning without equally strong deprovisioning creates faster sprawl. The real governance test is whether automation reduces the time any identity can exist with unnecessary access. Teams should measure whether workflows reduce privilege duration, not just ticket handling time.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• The broader lifecycle problem is visible in NHI Lifecycle Management Guide, where provisioning, rotation, and offboarding are treated as one governance chain rather than separate tasks.

What this signals

Lifecycle control is becoming the deciding factor in IAM maturity. Organisations that can provision quickly but revoke slowly are creating a persistent privilege surplus, especially across service accounts and contractor access. The governance gap is not identity creation, but the time it takes for access to stop being valid after the work is done.

Only 5.7% of organisations have full visibility into their service accounts. That figure shows why access reviews and policy design fail when teams do not know what identities exist in the first place. Visibility is the prerequisite for any meaningful review cadence, whether the identity is human, machine, or automated.

The market is converging on a broader interpretation of identity control, where NHI lifecycle management and zero-trust principles are no longer separate topics. As access becomes more distributed, teams should expect programme pressure to shift from authentication quality toward entitlement duration, ownership clarity, and revocation speed.

For practitioners

• Shorten the access lifecycle Automate provisioning, modification, and deprovisioning as one connected workflow so access cannot remain active after the business need has ended. Include contractor and third-party access in the same lifecycle rules as employee access, with explicit revocation triggers for role change and offboarding.
• Replace static trust with continuous verification Require re-authentication or step-up checks for sensitive resources instead of assuming that a previous approval still holds. Apply this to cloud apps, admin functions, and external collaborator access where trust tends to accumulate silently over time.
• Make least privilege measurable Review role design and entitlement scope against actual task requirements, then remove permissions that are rarely used or inherited by default. Track the number of exceptions, dormant entitlements, and over-broad roles as operational risk indicators.
• Treat offboarding as a security control Tie access removal to HR, vendor management, and project closure events so revocation happens when the relationship ends, not at the next review cycle. Pay special attention to API keys, service accounts, and shared administrative access.

Key takeaways

• The article reinforces a familiar IAM truth: policy only matters when organisations can actually enforce privilege limits across cloud, SaaS, and contractor access.
• NHI research shows why this remains hard, with only 20% of organisations formalising API key offboarding and 97% of NHIs carrying excessive privileges.
• The most effective IAM programmes will be the ones that treat provisioning, review, and revocation as one lifecycle, not three separate processes.

Key terms

• Least Privilege: Least privilege is the principle of giving an identity only the access required to complete a specific task. In practice, it means reducing broad standing permissions, limiting exceptions, and continuously checking that roles still match real work rather than historical assumptions.
• Role-Based Access Control: Role-based access control assigns permissions through predefined roles instead of one-off user grants. It simplifies administration, but it only stays accurate when role definitions are maintained, exceptions are controlled, and unnecessary inheritance is removed before it becomes privilege creep.
• Attribute-Based Access Control: Attribute-based access control uses policy conditions such as department, device, location, or data sensitivity to decide access. It adds precision to IAM, but the governance burden grows quickly if attributes are inconsistent or if policy logic becomes too complex to operate safely.
• Zero-Trust Access Verification: Zero-trust access verification means every access request is checked against current context rather than assuming previous trust still applies. For identity programmes, it shifts control away from permanent confidence and toward continuous validation of identity, device, and request conditions.

Deepen your knowledge

Identity and access management best practices, least privilege, and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is growing across cloud apps, contractors, and service accounts, it is worth exploring.

This post draws on content published by Zluri: Best Practices 11 Identity and Access Management Best Practices. Read the original.