TL;DR: User provisioning software is presented as the answer to manual joiner-mover-leaver pain, but the underlying problem is lifecycle control across onboarding, role changes, and offboarding, according to Zluri. The real issue is not automating clicks, but proving access is granted and revoked consistently across apps, directories, and exceptions.
At a glance
What this is: This article surveys user provisioning software and shows that the real challenge is lifecycle control across onboarding, role change and offboarding, especially when apps do not support SCIM.
Why it matters: IAM teams need to treat provisioning as a lifecycle governance problem, because automation only reduces risk when access changes are consistently applied across all systems, not just the easy ones.
Context
User provisioning is the process of creating, updating and removing application access as people join, change roles or leave. In practice, the hard part is not the workflow itself but keeping identity state aligned across HR data, directories, SaaS apps and exceptions.
The article frames user provisioning software as a way to reduce manual work, but its real value depends on whether the organisation can prove access is granted and revoked consistently. That makes it an IAM and IGA issue as much as an operations problem.
Key questions
Q: What breaks when user provisioning does not cover every application?
A: When provisioning coverage is incomplete, access removal becomes inconsistent and former users can retain app-local permissions, cached access, or orphaned accounts. That breaks the joiner-mover-leaver model because the identity record changes, but the effective access state does not. The result is hidden residual access that only appears when a termination is tested end to end.
Q: Why do manual offboarding processes create identity risk?
A: Manual offboarding creates identity risk because it depends on people remembering every connected system and every entitlement path. That increases the chance of missed revocation, especially in SaaS stacks with billing, reporting, and delegated admin functions. Stale access then remains active long after the relationship ends.
Q: How do teams know whether automated provisioning is actually working?
A: Look for two signals. First, new users and role changes should receive the right access without manual rework. Second, revocation should happen cleanly when the identity leaves or changes scope. If either side relies on tickets, exceptions, or cleanup after the fact, the automation is not fully governed.
Q: What should teams prioritise first: provisioning automation or access reviews?
A: If access assignment is still manual and inconsistent, provisioning automation usually comes first because it creates the control trail that reviews need. But reviews remain necessary to catch policy errors, inherited permissions, and exceptions that automation cannot safely infer. The two controls should reinforce each other, not compete.
Technical breakdown
Why SCIM leaves a lifecycle gap in provisioning
SCIM standardises how identity changes are pushed into SaaS applications, but it only works where the target app exposes a compatible connector. When an application lacks SCIM support, the provisioning workflow stops being consistent and teams revert to manual add, update and delete steps. That creates uneven lifecycle coverage across the application estate, especially in environments with many niche or legacy tools. The technical issue is not just integration effort. It is that identity state becomes fragmented, so access decisions no longer share a single governable path.
Practical implication: map which applications depend on SCIM and which still require direct API or manual handling.
How direct API provisioning extends user lifecycle coverage
Direct API integration gives provisioning tools a second route into applications that do not support SCIM. Instead of relying on one standard connector model, the platform can call application interfaces to create, update or remove access based on lifecycle events. That broadens coverage, but it also introduces another control boundary: API permissions, connector reliability and exception handling now sit inside the provisioning chain. The technical question shifts from whether access can be changed to whether every change path is observable and governed.
Practical implication: validate API-based provisioning paths with the same access and logging requirements you apply to SCIM-connected apps.
Why offboarding is the highest-risk provisioning moment
Offboarding is where lifecycle failure becomes security exposure. If access removal is delayed, incomplete or inconsistent across systems, a departing user can retain active entitlements long after the business relationship has ended. The article’s emphasis on secure deprovisioning and access audits reflects a core IAM control truth: termination is only complete when every dependent application, group and account has been removed or reviewed. In lifecycle terms, offboarding is the point where governance either closes the loop or leaves standing access behind.
Practical implication: treat deprovisioning as a complete entitlement closure exercise, not a single system event.
Threat narrative
Attacker objective: Retain usable access after a user should no longer have it, so data and application resources remain exposed.
- Entry occurs through normal employment or role change, where a user gains access to applications during onboarding or transfer.
- Credential or entitlement persistence occurs when provisioning does not fully remove or update access in every connected system.
- Escalation follows when excess or stale access remains available after the role change or departure.
- Impact is unauthorized use of retained access to company applications and sensitive data.
Breaches seen in the wild
- 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 control, not provisioning speed, is the real IAM benchmark. This article is strongest when read as a lifecycle governance problem rather than a tooling roundup. Adding users quickly matters less than proving that onboarding, change and exit events are reflected across the full application estate. The practitioner conclusion is simple: if access state is not trustworthy end to end, automation only makes failure faster.
SCIM coverage is not the same as lifecycle coverage. SCIM solves a connector problem, but it does not by itself solve governance across apps that lack the protocol. That distinction matters because many organisations mistake connector availability for complete lifecycle control. The practitioner conclusion is to measure provisioning by application coverage, not by the existence of a standard.
Secure deprovisioning is the control that converts provisioning into governance. The article repeatedly points to revocation, access audits and role-aware updates because lifecycle control breaks most visibly at offboarding. That is the point where entitlement drift becomes exposure. The practitioner conclusion is to treat removal, not creation, as the test of whether provisioning is actually under control.
Identity lifecycle automation belongs in the same control conversation as IGA and PAM. When access changes affect sensitive applications, the question is not only whether accounts can be created or removed, but whether the organisation can certify and constrain those changes consistently. That aligns provisioning with lifecycle governance across IGA, access reviews and privileged pathways. The practitioner conclusion is to govern provisioning as a cross-domain identity control, not a narrow admin workflow.
Provisioning tools expose the operational gap that many programmes still hide. The article makes clear that organisations often have enough process to assign access, but not enough discipline to prove that access is removed everywhere it exists. This is the gap that exceptions, manual workarounds and non-SCIM apps create. The practitioner conclusion is to close the exception path before claiming lifecycle maturity.
From our research library:
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
What this signals
Coverage is the measure that matters: user provisioning maturity depends on whether access changes are enforced across every application class, including the ones that fall outside standard connectors. Organisations that equate a working SCIM flow with complete lifecycle control will miss the systems where manual handling still creates exposure.
The operational signal to watch is entitlement drift after role changes and offboarding events. If audit trails still show access lingering after a person has moved or left, the provisioning process is not governing identity lifecycle end to end.
For practitioners
- Map provisioning coverage by application class Separate SCIM-enabled apps, direct API-integrated apps and manual exceptions so you can see where lifecycle controls stop being automatic.
- Audit offboarding as a full entitlement closure process Verify that role changes and exits remove access from applications, groups, directories and downstream systems, not only the primary directory record.
- Review API-based provisioning permissions Confirm that any direct API path used for provisioning has bounded permissions, reliable logging and clear exception handling when calls fail.
- Track access audits against lingering entitlements Use access review output to identify users whose entitlements remain active after role changes or termination events.
Key takeaways
- User provisioning only solves part of the problem if access changes are not applied consistently across directories, SaaS apps and exception paths.
- The most important failure mode is incomplete deprovisioning, because stale entitlements can remain usable after a role change or departure.
- IAM teams should measure provisioning by lifecycle coverage and revocation completeness, not by how much of the workflow is automated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centres on lifecycle removal and the risk of access lingering after departure. |
| NHI-09 — NHI Reuse | Provisioning across many apps often reuses identity state and can propagate stale access. | |
| Recommendation — Tighten offboarding workflows so accounts and entitlements are revoked across every connected system. Eliminate reused identity state that carries old access into new lifecycle events. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The subject is account creation, modification, and removal across the identity lifecycle. |
| Recommendation — Govern account lifecycle actions so provisioning and deprovisioning are complete and verifiable. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is fundamentally about managing accounts and access rights at scale. |
| Recommendation — Centralise account management to reduce missed removals and access drift across systems. | ||
Key terms
- User Provisioning: User provisioning is the process of creating, changing, and removing access rights across systems. In practice, it includes account creation, role assignment, permission updates, and deprovisioning. The security value comes from keeping access aligned to current business need throughout the identity lifecycle.
- 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.
- Scim: System for Cross-domain Identity Management is the standard used to exchange user and group lifecycle data between an identity provider and an application. In production, the protocol only solves part of the problem. The harder issue is whether the implementation preserves attributes, order, and tenant scope consistently across real directory sources.
- Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
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.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org