Notifications
Clear all
Topic starter
01/07/2026 2:06 am
TL;DR: Lifecycle management platforms can automate joiner, mover, and leaver workflows through event-driven playbooks, permission-level provisioning, and discovery-first offboarding, according to Zluri. The real issue is not automation itself, but whether lifecycle control is precise enough to keep access aligned to current entitlement and accountability.
NHIMG editorial — based on content published by Zluri: How Zluri Automates User Lifecycle Management and the 9 capabilities it highlights
Questions worth separating out
Q: How should IAM teams govern offboarding when applications are not fully inventoried?
A: They should treat discovery as part of the control, not a separate audit exercise.
Q: When does lifecycle automation fail to stop access creep?
A: It fails when removal and provisioning are split across different rules or separate approvals, because the identity can remain in a transitional state long enough for overlap to persist.
Q: What do security teams get wrong about access requests?
A: They often treat access requests as a simple approval queue instead of a governance mechanism for exceptions.
Practitioner guidance
- Map lifecycle controls to live access evidence Use discovered entitlements as the starting point for offboarding and recertification, especially where shadow IT and team-managed tools sit outside your central inventory.
- Separate application access from permission scope Review whether your provisioning logic can set the correct permission level inside an application at execution time.
- Collapse mover transitions into one governed sequence Configure role changes so deprovisioning and provisioning are triggered by the same HRMS event and logged together.
What's in the full article
Zluri's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how the Playbook, Automation Rule, and directory integrations work together across joiners, movers, and leavers.
- Detailed examples of Apply Condition and Add Conditions inside specific app blocks, including permission-level governance cases.
- Walkthroughs of the Wait For delay, Trigger Playbook chaining, and Break on Error behaviour in workflow execution.
- The article's own product framing for why these mechanics are positioned differently from legacy IGA workflows.
👉 Read Zluri’s blog post on lifecycle automation and JML governance →
JML lifecycle automation: what it means for identity teams?
Explore further
01/07/2026 2:28 am
Discovery-first lifecycle control is the right answer to incomplete visibility, not to lifecycle complexity. The article makes the strongest case when it shows that offboarding based on known inventory is structurally incomplete in SaaS-heavy environments. That is the governance gap: access continues wherever discovery never happened. The implication is that lifecycle programmes must treat live access state as the governing record, not the spreadsheet of managed apps.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do you know if mover provisioning is actually working?
A: You should see the old role removed, the new role granted at the correct scope, and both actions recorded in one sequence tied to the same HRMS change. If users retain old permissions after a move, or if new access arrives without scope recalculation, the mover process is not governing entitlement drift.
👉 Read our full editorial: Zluri’s lifecycle automation points to tighter JML governance
