Identity lifecycle management still breaks at offboarding and review

At a glance

What this is: Identity lifecycle management automates identity creation, access changes, monitoring, and offboarding across people and machine identities, with the article arguing that lifecycle governance is the core control plane for secure access.

Why it matters: For IAM practitioners, the key issue is that lifecycle failures create standing access, weak audit trails, and delayed revocation across NHI, autonomous, and human programmes.

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.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Netwrix's guide to identity lifecycle management stages and best practices

Context

Identity lifecycle management is the discipline of creating, modifying, reviewing, and removing access as identities move through the enterprise. The article frames it as the mechanism that keeps access aligned to role, policy, and business need across hybrid environments.

The problem is that manual lifecycle handling still produces dormant accounts, privilege creep, and delayed revocation. That matters for human users, service accounts, and machine identities alike, because lifecycle drift becomes an access-control failure, not just an administrative inconvenience.

The article’s strongest point is that lifecycle governance only works when provisioning, review, and deprovisioning are connected to authoritative data and enforced consistently. That is the difference between an identity programme that records access and one that actually controls it.

Key questions

Q: What breaks when identity lifecycle management does not revoke access cleanly?

A: When revocation is incomplete, dormant accounts, stale permissions, and orphaned credentials remain available after the business reason for access has ended. That creates unauthorised use risk, weakens audit trails, and makes it harder to prove that access was removed everywhere it should have been removed.

Q: Why do access reviews fail when identity lifecycle data is incomplete?

A: Access reviews only work when the underlying identity record reflects current role, owner, and system scope. If source data is stale or fragmented, reviewers certify the wrong entitlement set and privilege creep survives the review cycle instead of being removed.

Q: How do organisations know whether lifecycle governance is actually working?

A: The strongest signal is not how many accounts were created, but how consistently unnecessary access is removed after role changes, departures, and expiry events. Strong programmes can show complete revocation evidence, low orphan-account counts, and audit logs that match the real identity state.

Q: Who is accountable when a departed user or service account still has access?

A: Accountability should sit with the identity owner, the system owner, and the process owner for offboarding. If any one of those roles is unclear, access can linger across directories, cloud apps, and secrets stores without a clear party responsible for removal.

Technical breakdown

Identity creation and authoritative source sync

Identity creation starts when authoritative systems such as HRIS, directory services, or CRM feeds supply identity attributes to the IAM stack. Those attributes drive role templates, group membership, and the first access grants. The technical risk is inconsistency: if source records lag or drift, accounts are created with stale entitlements and the rest of the lifecycle inherits that error. In practice, lifecycle accuracy depends on reliable attribute synchronisation, not just automated provisioning logic.

Practical implication: connect provisioning workflows to authoritative sources and treat attribute quality as a control, not a data hygiene issue.

Access modification, JIT access, and least privilege

Access changes should follow role change, task scope, or expiry rather than administrative convenience. Just-in-time access reduces standing privilege by granting permissions only for the task window, then withdrawing them automatically. In lifecycle terms, the key mechanism is not merely approval flow but entitlement decay, where access should become narrower or disappear as soon as the business need ends. Without that decay, role changes become a long-lived privilege accumulation path.

Practical implication: design access changes so temporary access expires by default and role changes automatically remove obsolete entitlements.

Deprovisioning, audit trails, and privilege creep

Offboarding is the final lifecycle stage where access must be revoked across all connected systems, including cloud apps, directories, and machine identities. The technical weakness in many programmes is fragmentation: revocation happens in one system but not others, leaving dormant accounts and orphaned credentials behind. Audit trails matter because they show who changed what and when, which is essential for proving that revocation actually occurred. Without reliable logs, privilege creep becomes hard to detect and harder to prove.

Practical implication: require cross-system deprovisioning evidence and use audit logs to verify that revocation completed everywhere.

Threat narrative

Attacker objective: The attacker objective is to exploit stale or excessive access that lifecycle controls failed to remove, turning ordinary identity drift into unauthorised reach.

1. Entry occurs when identities are provisioned with broader access than their role requires, or when stale accounts remain active after a role change or departure.
2. Escalation happens when privilege creep, delayed revocation, or weak review cycles leave standing permissions available for misuse or lateral movement.
3. Impact follows when dormant or excessive access is used to reach sensitive systems, create compliance gaps, or expose data without a clear audit trail.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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 lifecycle management is only as strong as the revocation path. The article treats onboarding and provisioning as the visible part of ILM, but the control failure usually sits at the end of the cycle. When deprovisioning is delayed or partial, access outlives employment, contract scope, or task need. The implication is straightforward: lifecycle success should be measured by removal completeness, not by how quickly accounts are created.

Privilege creep is not a nuisance metric, it is a structural governance failure. The article correctly links role changes, temporary access, and manual exceptions to excess entitlement accumulation. That pattern matters because entitlement drift converts ordinary business change into standing exposure. Practitioners should read privilege creep as evidence that access governance is not keeping pace with operational reality.

Machine identities must be governed through the same lifecycle discipline as human identities. The article includes service accounts and machine identities for good reason. Those identities rarely leave on their own, and their credentials often persist beyond the business process that created them. The practical conclusion is that lifecycle governance cannot stop at employee offboarding; it has to follow every non-human identity to termination, rotation, and evidence of revocation.

Zero Trust and ILM converge at one point: access should expire when the need does. The article’s JIT discussion is useful because it shows lifecycle management as a time-bound entitlement system rather than a static provisioning model. That matters across human, NHI, and autonomous programmes because the control objective is the same: remove standing access wherever possible and prove that the remaining access is justified.

Identity lifecycle programmes fail when they depend on manual exception handling. The article repeatedly shows that efficiency gains come from automation, but the deeper point is governance consistency. Manual workflows create uneven revocation timing, incomplete logs, and approval gaps that undermine auditability. Practitioners should treat exception handling as the place where lifecycle controls most often lose authority.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For the lifecycle side of the problem, read NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding need to work together.

What this signals

Lifecycle governance is becoming the control plane for mixed identity estates. As organisations add more service accounts, machine identities, and AI-linked access paths, the old split between human IAM and NHI governance becomes less useful. The operational question is no longer whether access exists, but whether the lifecycle process can prove when and why it ended.

The post also reinforces a simple planning signal: if your programme cannot revoke access quickly and evidence it cleanly, it is already behind the identity state of the estate. That is especially true where temporary access, contractors, and machine identities share the same control fabric.

Privilege persistence is the real risk surface. When access is allowed to outlive business need, the attack path is created by governance latency rather than by a novel exploit. Teams should expect lifecycle evidence, recertification outcomes, and deprovisioning completeness to become board-level control metrics.

For practitioners

• Map every identity to a lifecycle owner Assign named ownership for human users, service accounts, and machine identities so that creation, change, and removal decisions have a clear accountable party across HR, IT, and security.
• Verify deprovisioning across all connected systems Do not accept account closure in one directory as proof of offboarding. Confirm revocation in SaaS apps, cloud consoles, directories, and secrets stores, and keep the evidence with the access record.
• Use time-bound access for non-routine work Grant temporary access with explicit expiry for projects, contractors, and elevated tasks so that lifecycle controls remove entitlement automatically when the business need ends.
• Audit role changes for hidden entitlement growth Review movers and role transitions for permissions that no longer match current duties, then remove inherited access that survived the change without business justification.
• Tie recertification to revocation evidence Make access reviews prove that a decision led to removal where required, instead of treating recertification as a paper exercise that ends at approval.

Key takeaways

• Identity lifecycle management fails most often at the removal stage, where delayed revocation and fragmented offboarding leave access behind.
• The scale of the issue is already visible in privilege creep, dormant accounts, and incomplete audit trails across human and machine identities.
• Practitioners should treat lifecycle completeness, not provisioning speed, as the measure that tells them whether IAM is actually controlling access.

Key terms

• Identity lifecycle management: Identity lifecycle management is the discipline of controlling an identity from creation through change and eventual removal. It combines authoritative data, automated provisioning, access review, and deprovisioning so access always matches current business need rather than historical assignment.
• Privilege creep: Privilege creep is the gradual accumulation of access that is no longer justified by a person’s job, a contractor’s scope, or a machine account’s purpose. It usually appears when role changes and exceptions are not fully cleaned up across all connected systems.
• Deprovisioning: Deprovisioning is the removal or suspension of access when an identity is no longer entitled to it. In practice, it must reach every directory, application, vault, and connected service, or the identity remains partially alive and still usable.
• Just-in-time access: Just-in-time access is a time-limited entitlement pattern that grants permissions only for the duration of a task or approval window. It reduces standing privilege by making access temporary, auditable, and automatically removable when the need has expired.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Netwrix: Identity Lifecycle Management: A Complete Guide to ILM Stages, Tools, and Best Practices. Read the original.