Lifecycle management platforms expose the access governance gap

At a glance

What this is: This is a lifecycle management explainer showing that manual provisioning and deprovisioning leave governance gaps across onboarding, mid-lifecycle changes, and offboarding.

Why it matters: It matters because IAM and IGA teams need lifecycle controls that keep access aligned to role changes and departures before stale permissions become security exposure.

Context

User lifecycle management is the set of processes that grants, changes, and removes access as people move through onboarding, role changes, and offboarding. In this article, Zluri argues that manual handling of those steps leaves gaps because IT teams cannot keep SaaS permissions continuously aligned to employment status.

The security issue is not just administrative burden. When lifecycle workflows depend on tickets and manual checks, access can outlive the role that justified it, which creates unnecessary standing privilege and weakens governance across IAM and IGA programmes.

Key questions

Q: What breaks when lifecycle management is still manual?

A: Manual lifecycle management creates delays between a business event and the identity update that should follow it. New hires wait for access, movers accumulate old permissions, and leavers keep credentials longer than they should. The result is predictable drift, avoidable audit issues, and higher security exposure.

Q: Why do role changes create access risk in SaaS environments?

A: Role changes often leave the old access in place while new access is added, which creates privilege creep. If provisioning logic does not revoke entitlements as cleanly as it grants them, the user accumulates permissions beyond current need. That is a governance failure, not just an administrative delay.

Q: How do security teams know whether offboarding is actually working?

A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.

Q: How do organisations decide which access requests should be self-service and which need approval?

A: Use self-service for low-risk, well-understood applications and reserve approval for sensitive tools, unusual role combinations, or exceptions outside standard policy. The key is to predefine the boundary before employees start requesting access, so the request portal enforces governance rather than replacing it.

Technical breakdown

Why manual lifecycle workflows create access drift

Manual lifecycle workflows depend on people noticing when a joiner, mover, or leaver event has occurred and then translating that change into permissions across multiple SaaS apps. That creates delay, inconsistency, and the likelihood that access changes are only partially applied. In identity terms, the problem is not only provisioning speed. It is the mismatch between business state and entitlements, especially when access is distributed across many disconnected applications and the authoritative HR record is not directly enforced in the access layer.

Practical implication: teams need automated lifecycle triggers tied to authoritative HR data, not ticket-driven access changes.

Why offboarding is the highest-risk lifecycle stage

Offboarding is the most sensitive lifecycle phase because access that remains after departure can become unauthorized access immediately. The article’s core point is that revocation must cover every SaaS app, not just the obvious systems. If deprovisioning is incomplete, departed users may retain valid access paths long enough to expose data, reuse sessions, or retain permissions in overlooked applications. This is a classic governance failure in user lifecycle management, where the control objective is complete removal, not partial cleanup.

Practical implication: offboarding workflows should verify full revocation coverage across every application, not just core systems.

How self-service request models change approval pressure

Self-service access request models reduce friction for employees, but they also shift more emphasis onto approval quality, entitlement visibility, and role-based matching. If the request catalog is broad but governance is weak, the organisation can move faster while still granting permissions that are excessive for the new role. The technical issue is not self-service itself. It is whether request routing, entitlement review, and role context are strong enough to prevent access sprawl while preserving productivity.

Practical implication: combine self-service access with role-aware approvals and entitlement validation before granting access.

Threat narrative

Attacker objective: The objective is to exploit residual SaaS access that should have been removed, enabling unauthorized access to data and applications.

1. Entry occurs through normal onboarding or role-change processes when access is granted without sufficient policy automation or verification.
2. Escalation happens when permissions are broadened during job transitions or left in place after the employee no longer needs them.
3. Impact follows when stale access survives offboarding and exposes SaaS data to unauthorized use or compromise.

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.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 identity state is managed as a workflow, not as a control boundary. Zluri’s article reinforces a familiar IAM lesson: onboarding, mover, and leaver events only stay safe when the organisation can translate business status into authoritative access changes. Manual handling turns lifecycle management into a queue, which is too slow for modern SaaS estates. The practitioner conclusion is that lifecycle governance must be treated as an enforcement problem, not an admin convenience problem.

Offboarding is not a cleanup task, it is an access revocation control. The article correctly centres departure risk because the security value of lifecycle management is most visible when access must disappear completely. This is where many programmes fail, not because they lack intent, but because they lack complete coverage across all apps and accounts. The practitioner conclusion is that revocation scope matters more than revocation speed alone.

Self-service access does not solve governance unless role context stays authoritative. The article’s employee app store example shows how request friction can be reduced, but a faster request path can still produce excessive permissions if role and entitlement checks are weak. That means the real governance question is not whether employees can request access quickly, but whether requests are constrained by current role, approval logic, and approved application scope. The practitioner conclusion is that convenience must remain subordinate to entitlement control.

User lifecycle management is where IAM and IGA either converge or drift apart. Lifecycle workflows connect identity proofing, entitlement assignment, recertification logic, and offboarding into one operational system. If those steps live in disconnected tools or manual ticket queues, governance becomes fragmented and audit evidence becomes harder to trust. The practitioner conclusion is that lifecycle management should be designed as a single control plane for access change, not a set of isolated tasks.

Standing access drift is the hidden consequence of weak lifecycle automation. The article points to the real problem: not every access grant is dangerous, but access that remains after its business purpose has ended is a persistent exposure. That is why lifecycle management must be measured by how quickly and completely it removes obsolete permissions, not just by how many workflows it automates. The practitioner conclusion is that stale access is the signal to watch, not workflow volume.

From our research library:

• 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.
• Read next: NHI Lifecycle Management Guide

What this signals

Standing access drift: User lifecycle management should be judged by how completely it removes obsolete permissions, not by how many provisioning tasks it automates. When offboarding and mover events lag behind HR changes, entitlement sprawl becomes a governance problem, not an operations problem.

Lifecycle programmes need tighter alignment between HR data, approval logic, and application entitlements so the business state is reflected in access state without manual cleanup. That is especially important where SaaS sprawl makes incomplete revocation easy to miss.

For practitioners

• Automate joiner-mover-leaver triggers Connect HRMS events to provisioning and deprovisioning workflows so role changes update SaaS access without manual ticket handling.
• Scope offboarding to every SaaS application Build revocation workflows that enumerate all apps and remove access from each one before closing the leaver event.
• Validate mover access against current role Review role changes against approved entitlement sets so employees lose obsolete access when they transfer, change department, or move location.
• Constrain self-service requests with approval logic Require identity verification, role-aware approval, and application approval lists before granting access through self-service request channels.
• Measure stale-access exposure after departures Track how often former employees retain access after offboarding and use that as a governance metric for lifecycle control effectiveness.

Key takeaways

• Manual lifecycle handling leaves access aligned to process queues instead of business need, which creates avoidable governance gaps.
• The article centres onboarding, mover, and leaver risk, with offboarding carrying the clearest exposure when revoked access is incomplete.
• Lifecycle automation only reduces risk when it removes obsolete permissions across all applications, not just the obvious ones.

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.
• Joiner Mover Leaver: Joiner Mover Leaver is the identity lifecycle process for creating, changing, and removing access as people enter, change roles, or leave an organization. It governs provisioning, modification, and deprovisioning across systems, ensuring access matches current job needs and reducing orphaned accounts, privilege creep, and residual access risk.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Deprovisioning: Deprovisioning is the removal of access when a user changes roles or leaves an organisation. For security teams, it is the point where stale accounts, tokens, and permissions should disappear. Weak deprovisioning leaves residual access that can outlive the business need that created it.

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.