Identity and access management still fails when access outgrows governance

At a glance

What this is: This is a 101 guide to identity and access management that argues IAM must cover lifecycle, access control, authentication, and governance together.

Why it matters: It matters because practitioners need one governance model that works across human users, service accounts, and emerging AI-driven access patterns.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Zluri's guide to identity and access management fundamentals

Context

Identity and access management is the control discipline that decides who or what can reach systems, data, and administrative functions. In practice, the problem is not whether access exists, but whether access stays aligned to roles, privileges, and business change as those conditions move.

This guide frames IAM as more than authentication and sign-in policy. It links lifecycle management, access control, and governance into one operating model, which is the right lens for modern enterprises that now have to manage humans, service accounts, and AI-driven access paths at the same time.

Key questions

Q: How should organisations manage access reviews for changing job roles?

A: Organisations should tie access reviews to real role changes, not calendar-only recertification. The review should test whether the current entitlements still match the work being done, whether temporary access has expired, and whether inherited privileges are still justified. If the answer is no, revoke immediately and keep the audit trail.

Q: Why do MFA and SSO not solve IAM governance by themselves?

A: MFA and SSO strengthen authentication, but they do not limit what an identity can do after it gets in. If roles are broad, permissions are stale, or exceptions accumulate, a successful login still opens the wrong level of access. Governance has to control entitlements as well as entry.

Q: What do security teams get wrong about least privilege in RBAC?

A: They often treat RBAC as a set-and-forget structure, when roles actually degrade over time through exceptions, inherited access, and convenience-driven expansion. Least privilege only holds when roles are regularly cleaned up against current tasks and removed when they no longer serve a defined business need.

Q: Who is accountable when access is not revoked on time?

A: Accountability sits with the identity and access owners who approve, operate, and verify revocation, but also with the process owner who failed to make offboarding measurable. Frameworks such as the NIST Cybersecurity Framework 2.0 and PCI-DSS both depend on demonstrable access control, not informal intent.

Technical breakdown

Identity lifecycle management and access drift

Identity lifecycle management covers joiner, mover, and leaver events, plus the ongoing changes that happen after initial provisioning. The technical failure mode is access drift, where permissions accumulate faster than they are reviewed or removed. In cloud and SaaS environments, drift is amplified by decentralised administration, temporary project access, and third-party integrations. Lifecycle control only works when provisioning, change management, and deprovisioning are treated as one continuous process rather than separate tasks.

Practical implication: centralise lifecycle events so access changes are revoked, not just recorded.

Access control, RBAC, and least privilege

Access control is the mechanism that limits what a given identity can do once authenticated. RBAC assigns access through roles, while least privilege narrows those roles to the minimum required for the task. The weakness in many programmes is role inflation, where broad roles become proxies for convenience instead of true job function. That creates privilege creep, especially when teams layer exceptions on top of exceptions. Zero Trust models sharpen this problem because every entitlement must be continuously defensible, not just historically assigned.

Practical implication: recertify roles against actual task demand, not org charts.

Authentication, MFA, and adaptive access checks

Authentication proves identity, while authorisation decides what that identity can do after proof is established. MFA improves assurance by requiring more than one factor, and adaptive authentication changes the challenge level based on risk signals such as device, location, or session context. The architectural lesson is that authentication strength does not compensate for weak authorisation. If downstream permissions are overbroad, a strong login only gives a stronger entry point into a poorly governed environment.

Practical implication: pair strong authentication with tightly scoped authorisation policies.

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

Identity governance breaks when access is treated as a point-in-time event. This guide assumes provisioning and revocation can be managed as routine admin tasks, but modern environments create continuous entitlement change across cloud, SaaS, and third-party integrations. The field-level lesson is that identity governance must operate on a live state, not on periodic snapshots. Practitioners should treat access drift as the core control problem.

Least privilege is the right principle, but role design is usually where it fails. RBAC works only when roles map cleanly to actual work, and most enterprise roles do not. They accrete exceptions, temporary access, and inherited permissions until the role becomes a convenience layer rather than a governance control. The implication is that access models need role hygiene, not just role assignment.

Authentication strength cannot compensate for poor access architecture. MFA, SSO, and adaptive checks reduce account takeover risk, but they do not fix overbroad standing permissions once a session is established. IAM programmes often over-invest in entry controls and under-invest in entitlement discipline. Security teams should judge IAM by what an identity can reach after login, not only by how hard it was to log in.

Third-party and machine identities are now part of the same governance problem. This article focuses on human IAM, but its logic extends to service accounts, API keys, and AI agents because all of them can hold privileges that outlive the original use case. That is where traditional IAM programmes start to blur into NHI governance. The practitioner takeaway is to stop running separate mental models for human and non-human access.

Identity governance is becoming an evidence discipline, not just an access-control discipline. The article correctly ties IAM to compliance, auditing, and operational control, which reflects where programmes are heading. The organisations that can prove who had access, when it changed, and why it was still justified will be better positioned for both audit and incident response. Practitioners should design for traceability as a first-class requirement.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, which shows how quickly unmanaged credentials become business risk.
• That governance gap is why teams should pair lifecycle controls with the NHI Lifecycle Management Guide when access must be revoked as fast as it is created.

What this signals

Standing access is the hidden assumption most IAM programmes still depend on. When credentials, roles, and approvals are treated as durable, access reviews become a retrospective check instead of a real control. For modern programmes, the operational question is whether entitlement data can move as quickly as the business changes.

With 97% of NHIs carrying excessive privileges in our research, the boundary between human IAM and NHI governance is already blurred. Teams that only optimise login controls will miss the larger problem, which is how much access remains alive after authentication has succeeded.

Access traceability is becoming a governance differentiator. Organisations that can show who approved access, when it changed, and when it was removed will have a cleaner path through audit, incident response, and privilege reduction. That is the direction identity governance is moving, whether programmes started in human IAM or machine identity management.

For practitioners

• Map every identity to a lifecycle owner Assign a named owner for provisioning, role change, and offboarding across users, service accounts, and other non-human identities so exceptions do not become permanent.
• Reduce role inflation in RBAC models Review roles for inherited permissions, temporary entitlements, and outdated job mappings, then remove access that does not support a current business task.
• Pair MFA with entitlement review Use MFA and adaptive authentication to strengthen entry controls, then verify that post-login permissions remain narrow enough for the actual work being done.
• Establish evidence for compliance audits Retain access history, approval records, and deprovisioning evidence in a format that supports GDPR and PCI-DSS review without manual reconstruction.
• Extend IAM thinking to machine identities Apply the same governance logic to API keys, tokens, and service accounts so non-human access does not become the hidden exception in an otherwise controlled programme.

Key takeaways

• IAM is not just authentication, it is the governance layer that keeps access aligned to changing roles and responsibilities.
• The biggest operational risk is privilege drift, where roles, permissions, and offboarding lag behind business change.
• Teams should measure IAM by post-login entitlement scope, audit evidence, and revocation speed, not by login friction alone.

Key terms

• Identity Lifecycle Management: Identity lifecycle management is the process of creating, changing, and removing access as people or systems move through their work. In practice, it covers provisioning, updates, and deprovisioning so access stays current instead of lingering after the need has changed.
• Role-Based Access Control: Role-based access control assigns permissions through predefined roles instead of one-off grants. It is effective only when roles reflect real job duties and are regularly cleaned up, otherwise role creep turns it into a convenient wrapper for excess access.
• Least Privilege: Least privilege means giving an identity only the access needed to complete its current task. The control is simple in principle but difficult in operation because exceptions, inherited access, and temporary approvals often expand beyond the original need.
• Identity Governance: Identity governance is the set of processes used to approve, review, monitor, and revoke access over time. It connects operational access control with auditability and compliance, making access decisions explainable rather than just technically possible.

Deepen your knowledge

Identity lifecycle control and access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your IAM programme is expanding into service accounts, API keys, or AI-driven access, it is worth exploring.

This post draws on content published by Zluri: Access Management Identity and Access Management, a 101 guide. Read the original.