User lifecycle management and IT service delivery need tighter governance

At a glance

What this is: This article argues that user lifecycle management can improve IT service delivery through automated onboarding, self-service requests, and offboarding, but only when those workflows are governed end to end.

Why it matters: For IAM teams, the operational gain matters only if provisioning, approvals, and deprovisioning stay tied to lifecycle control so speed does not outrun access governance.

Context

User lifecycle management is the set of processes that create, change, and remove user access as people move through an organisation. In this article, Zluri frames it as an IT service delivery problem, but the governance question is whether workflow automation keeps access decisions aligned to joiner, mover, and leaver control.

The article focuses on onboarding, self-service access requests, and offboarding because those are the points where service speed and access control collide. For identity teams, the real issue is not whether the process is automated, but whether provisioning, approvals, and deprovisioning remain controlled, repeatable, and reviewable.

Key questions

Q: How should security teams govern user lifecycle workflows in IAM programmes?

A: Treat lifecycle workflows as access-control logic, not just service automation. Define who can approve each stage, limit reusable playbooks to policy-approved entitlement sets, and make offboarding prove that access was removed across every system in scope. The question is not how much the workflow automates, but whether it still expresses the organisation’s access policy.

Q: When does self-service app access create more risk than it reduces?

A: Self-service access becomes risky when the catalog expands faster than policy, ownership, and review. If users can request software without clear entitlement controls, the organisation gains speed but loses visibility. The risk rises further when low-friction requests bypass meaningful approval or post-access review.

Q: What breaks when offboarding is not tightly linked to access control?

A: Access can outlive the employment or role change that justified it, which creates privilege creep and audit gaps. The failure is not only technical. It also undermines accountability, because the organisation can no longer prove that access was removed when the business relationship changed.

Q: How do IAM teams know whether lifecycle automation is actually working?

A: Look for fewer manual exceptions, faster role changes, and verified access removal after offboarding. More importantly, check whether downstream systems stay in sync with the authoritative source and whether review findings show declining entitlement drift. If those signals do not improve, the automation is only moving tickets faster.

Technical breakdown

Automated onboarding still depends on governed playbooks

Onboarding workflows reduce manual work by turning recurring access patterns into reusable playbooks. That changes the operating model, but it does not remove the need for defined approval paths, role-based access logic, and app-level accountability. If a workflow can be edited and reused without strong change control, the same automation that speeds service delivery can also spread access mistakes at scale. The technical issue is not provisioning itself, but whether each playbook still expresses the organisation’s access policy rather than just convenience.

Practical implication: treat onboarding playbooks as governed access logic, not admin shortcuts.

Self-service access requests shift the control point, not the risk

An employee app store moves the request process from ticket queues into a curated catalogue. That improves speed, but the security question becomes how pre-approval rules, role conditions, and approver routing are enforced before access is granted. If users can request from a broad catalogue without precise policy boundaries, the organisation may reduce friction while expanding entitlement drift. Self-service is therefore a policy design problem as much as an IT service problem.

Practical implication: define approval conditions and catalogue boundaries before broadening self-service access.

Offboarding is only effective when revocation is complete

Offboarding is the lifecycle stage where access must be removed across devices, apps, SSO, and licences. Automating that sequence reduces delay, but the mechanism only works if every relevant access path is in scope and the removal logic is consistent across systems. The article’s emphasis on data transfer and access removal shows that offboarding is not a single action. It is a chained deprovisioning process, and gaps in any link leave residual access behind.

Practical implication: verify that offboarding workflows revoke every application and SSO path, not just the obvious ones.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• 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.

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 automation does not reduce governance requirements, it raises the cost of getting them wrong. A user lifecycle platform can accelerate onboarding, self-service, and offboarding, but the access model still has to be designed, approved, and reviewed. When teams treat workflow automation as the control instead of the delivery mechanism, policy drift becomes repeatable at machine speed. The practitioner conclusion is straightforward: automation must sit inside lifecycle governance, not replace it.

Self-service access is a governance design problem, not just a UX improvement. Curated catalogues and automated approval rules can improve service delivery, but they also shift entitlement decisions into the structure of the catalogue itself. That means the real control surface becomes role logic, approver routing, and app eligibility, not the request button. Practitioners should read self-service as a governance boundary that must be explicitly limited.

Clean offboarding is the only lifecycle stage where residual access should not survive the process. The article correctly highlights revoking access, removing SSO, and backing up data for continuity, which are the basic operational ingredients of a leaver process. The governance lesson is that offboarding must be complete across every access path, because one missed system turns a lifecycle event into standing access. The practitioner takeaway is to measure offboarding completeness, not just workflow completion.

Identity blast radius is the right concept for lifecycle platforms that touch many applications at once. A reuseable workflow may be efficient, but any entitlement mistake scales across every user and app the playbook touches. That makes lifecycle governance a blast-radius problem as much as an administrative one. Teams should focus on how far a workflow error can travel, because that is what separates useful automation from systemic entitlement risk.

ULM programmes should be judged by control fidelity, not by how many tasks they automate. The meaningful question is whether onboarding, request, and offboarding flows still reflect access policy at the point of decision. That aligns with NIST-CSF access permissions thinking and with NHI governance principles that apply whenever credentials are issued and withdrawn through workflow. Practitioners should evaluate whether the system preserves control intent as processes scale.

What this signals

Identity lifecycle automation only works when policy fidelity survives reuse. The real governance test is whether an onboarding or offboarding playbook still reflects the current access model after it has been copied across teams, roles, and systems. If not, the programme is optimising speed while quietly widening entitlement drift.

Self-service access changes where decisions happen, not whether decisions matter. Once request logic is embedded in a catalogue, the catalogue becomes a governance boundary. That means IAM teams need to watch eligibility rules, approver routing, and exception handling as closely as they watch provisioning itself.

For practitioners

• Map every lifecycle workflow to a control owner Document who approves onboarding, mid-lifecycle changes, and offboarding for each application class, then require a named owner for any reusable workflow or playbook.
• Constrain self-service to pre-approved entitlement sets Build the app catalogue around role and seniority conditions so users can only request access that already matches policy and approval routing.
• Test offboarding for full-path revocation Validate that device access, app access, SSO sessions, and licences are all removed in the same leaver flow, including apps that are not part of the obvious core stack.
• Review workflow reuse for entitlement drift Reassess any onboarding playbook that has been copied across teams or departments to confirm the app list, approval path, and scheduling rules still match the role.
• Measure lifecycle completion, not just ticket closure Track whether access is actually provisioned or revoked across every target system before marking the workflow complete, so service metrics do not hide residual access.

Key takeaways

• User lifecycle management can improve IT service delivery, but only if automation remains tied to explicit access governance.
• The main control risk is not speed, it is whether onboarding, request, and offboarding workflows stay complete across all connected systems.
• IAM teams should measure lifecycle fidelity by access outcomes, not by whether the workflow technically completed.

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.
• Self-Service Access: Self-service access lets users request, approve, or obtain access to systems and data through a controlled workflow without manual intervention from an administrator. It usually relies on policy checks, identity verification, and automated provisioning, so access is granted only when the request matches defined roles, attributes, risk conditions, and approval rules.
• Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
• Lifecycle playbook: A lifecycle playbook is a reusable workflow template that standardises how onboarding or offboarding steps are executed. It turns repeated identity tasks into governed sequences with defined inputs, approvals, and actions, which improves repeatability and makes exceptions easier to audit.

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 building or maturing an IAM programme, it is worth exploring.