User lifecycle management is failing in the 30-event middle

At a glance

What this is: This analysis shows that user lifecycle management breaks down in the middle of employment, where role changes, project assignments, and temporary elevations are still handled manually instead of through governed access updates.

Why it matters: IAM and IGA teams need to treat the access-change middle as a first-class lifecycle problem because unmanaged transitions create privilege creep, audit exposure, and delayed productivity across human identity programmes.

By the numbers:

• Over a typical 5-year tenure, an employee experiences 32+ access-impacting events, according to Zluri.
• The remaining 30 events represent 94% of the lifecycle and are handled reactively, according to Zluri.
• A typical 100-person company faces roughly 650 access-impacting events annually, according to Zluri.

Context

User lifecycle management is the process of keeping access aligned to the current role, team, and employment state of each person. In practice, many programmes still treat identity governance as a start-and-stop exercise, even though most risk is created by the transitions in between.

This article argues that the real governance gap sits in the access-change middle: promotions, transfers, temporary elevations, manager changes, leave events, and project work. For human IAM teams, that middle is where privilege creep accumulates and where manual ticketing breaks the link between business change and access change.

The article is written as a lifecycle automation argument, but its deeper point is governance-oriented. The problem is not that onboarding and offboarding are absent; it is that the organisation lacks a repeatable control plane for the 30-plus changes that happen while an employee is still active.

Key questions

Q: What breaks when identity lifecycle management only automates onboarding?

A: Offboarding and role changes become the weak point, which leaves stale access, orphaned accounts, and entitlement drift in place after the business has moved on. Automation that stops at provisioning creates process speed without governance. The control must prove that access can be removed as reliably as it can be granted.

Q: When does manual lifecycle management become a security risk?

A: Manual lifecycle management becomes a risk as soon as entitlement changes depend on tickets, email, or human memory. At that point, access can lag behind role changes, former users can retain permissions, and temporary access can outlast the business need. The practical signal is persistent mismatch between current role and active entitlement.

Q: What are the signs that least privilege is failing in an IAM programme?

A: Common signs include users keeping access after role changes, service accounts with more privileges than they use, repeated audit exceptions, and manual access reviews that cannot keep up with entitlement growth. When access becomes hard to explain or hard to revoke, PoLP has become a paper control rather than an operating control.

Q: How should organisations handle access when employees change roles internally?

A: Organisations should link internal role changes to access changes in the same workflow. New responsibilities, approvals, and collaboration tools should be updated together so old permissions do not linger. That reduces privilege drift and makes mover processes easier to audit, especially in remote-first teams where informal handoffs are harder to spot.

Technical breakdown

Why the onboarding-offboarding model misses the real access surface

Most organisations model access as binary: a person joins, then later leaves. That model ignores the fact that entitlement scope changes continuously during employment. Promotions, team changes, project assignments, leave, and temporary elevations all require different combinations of add, remove, and adjust actions. When those events are handled as ad hoc tickets, the access graph becomes historical rather than current. The result is not just delay but misalignment, because permissions remain attached to past responsibilities long after the role has changed.

Practical implication: Treat access changes as lifecycle state transitions, not tickets, so policy can calculate what should change when the person’s role changes.

How privilege creep forms across repeated lifecycle events

Privilege creep is the accumulation of access that no longer matches the person’s current job. It builds one small exception at a time. A project adds a tool, a temporary elevation never expires, a transfer leaves old access behind, and a promotion overlays manager privileges without removing IC access. None of these events looks alarming in isolation, but together they create standing access that is no longer justified. In lifecycle terms, cleanup is not a one-time offboarding activity. It is the continuous removal of stale access as roles evolve.

Practical implication: Build removal logic into every role change so old access is revoked at the same moment new access is granted.

Why automation depends on HR as the access trigger

The article’s operational model depends on HR being the authoritative source of lifecycle change. The access system must compare the current HR record with the prior state, identify what changed, and route the right response playbook. That means job title, department, team, manager, location, employment type, status, and contract date become control inputs. Without that trigger, access updates remain dependent on people remembering to submit requests, which is exactly where the governance gap begins. The mechanism is simple: detect, classify, execute, verify.

Practical implication: Use HR field changes as the event source for access updates, with verification after each automated change.

Threat narrative

Attacker objective: The practical attacker outcome is a large pool of stale, over-scoped, and still-usable access that expands the blast radius of a compromise or audit failure.

1. Entry occurs when role changes, projects, or leave events are handled through tickets and informal requests instead of governed automation.
2. Credential and entitlement exposure grows as old access remains in place while new access is added, creating standing privilege across multiple apps.
3. Escalation happens when temporary access, manager access, and project access become permanent because no expiry or cleanup process removes them.
4. Impact is delayed detection, privilege creep, audit exposure, and in some cases retained access after offboarding despite SSO disablement.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Lifecycle governance fails when access is treated as a start-and-stop event. The article shows that most organisations still behave as though onboarding and offboarding are the only meaningful control points. That assumption leaves the 30-plus in-between events outside governance, where privilege creep becomes normal rather than exceptional. For human IAM, the real control problem is not provisioning at entry. It is continuous entitlement re-alignment during the employment lifecycle.

Access change has become the hidden control surface in identity programmes. Promotions, transfers, temporary elevations, manager changes, and project work all change what a person should be able to do. When each event is handled through tickets and memory, access drift becomes structurally inevitable. The practitioner lesson is that lifecycle maturity should be measured by how many middle events are governed automatically, not by whether joiners and leavers are covered.

Privilege creep is a lifecycle defect, not an audit surprise. The article’s 5-year journey example makes clear that access accumulation is the expected outcome when cleanup is not built into every transition. This is where IAM, IGA, and PAM intersect: role change, elevated access, and entitlement removal must be managed as one lifecycle, not three disconnected processes. The implication is that access review programmes need to be tied to change events, not just periodic recertification.

Automatic reconfiguration is the only scalable answer to mid-lifecycle change. The article’s process model assumes HR-driven triggers, event classification, pre-built playbooks, and verification after each change. That is the correct governance shape because manual handling cannot keep pace with 32-plus events per employee. For practitioners, the key decision is whether lifecycle governance is event-driven enough to keep pace with organisational change.

Identity governance in human environments is increasingly about removal discipline. The strongest signal in the article is not how many apps are provisioned at hire, but how many remain after roles shift. That reframes the maturity question for IGA teams: can the programme prove that outdated access is being removed as quickly as new access is added? If not, the lifecycle model is still incomplete.

What this signals

Access governance has to move from milestone thinking to transition thinking. When programmes only recognise the start and end of employment, they miss the long middle where most entitlement drift occurs. That is where identity teams need to focus their operating model, because the bulk of risk is created by change events, not by initial provisioning.

Event-driven lifecycle control is now the practical baseline for human IAM. The operating assumption should be that every material HR change can and should trigger an access response, with verification built in. Where that trigger does not exist, teams should expect exception handling to become the default and audit evidence to become reconstructive rather than authoritative.

For practitioners

• Automate HR-triggered access changes Use job title, department, manager, team, location, status, and contract-date changes as the trigger for access workflows rather than tickets or Slack requests.
• Model every role transition as an access delta For promotions, transfers, and team moves, calculate what must be added, removed, and re-scoped so old access does not stack with new access.
• Set expiry on temporary access at issuance Grant on-call, project, and incident elevation with a hard end time and automated revocation tied to the original business justification.
• Verify post-change entitlement state After each automated update, confirm that the new access works and the removed access no longer works, then record the result in the audit trail.
• Track lifecycle coverage as a governance metric Measure what percentage of access-impacting events are handled systematically, because joiner and leaver coverage alone does not show whether the programme is working.

Key takeaways

• The article’s central warning is that lifecycle governance breaks down when organisations stop at onboarding and offboarding.
• The unmanaged middle of promotions, transfers, project work, and temporary elevations is where privilege creep accumulates over time.
• The control gap is not a lack of access requests. It is the absence of event-driven reconfiguration, removal discipline, and verification.

Key terms

• User Life Cycle Management: User life cycle management is the end-to-end process of creating, updating, reviewing, and removing user identities and access across enterprise systems. It links identity governance to employee onboarding, role changes, and offboarding so access stays aligned with job responsibilities and business need.
• Privilege Creep: Privilege creep is the gradual accumulation of access rights beyond what an identity actually needs. It usually happens when permissions are added for convenience and never removed. For NHIs, privilege creep expands blast radius and makes old credentials far more dangerous than their original purpose suggests.
• Access Delta: The difference in permissions, roles, groups, or application entitlements between two identities. In governance terms, the delta is useful because it shows what needs justification, not just what exists. In identity programmes, a large unexplained delta is often the earliest sign of privilege creep or mis-scoped access.
• Lifecycle Trigger: A lifecycle trigger is the event or source signal that causes an access change, such as a role update, termination, or transfer. If the trigger is stale, missing, or poorly governed, the identity system can keep access alive long after the business need has ended.

Deepen your knowledge

Identity lifecycle management, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.