Notifications
Clear all
Topic starter
01/07/2026 2:02 am
TL;DR: Manual joiner, mover, and leaver handling creates silent access drift, delayed provisioning, and incomplete offboarding across employees, contractors, and partners, according to Zluri’s guide on JML automation. The governance problem is not just speed. It is whether identity programmes can keep least privilege intact as roles change and access footprints expand.
NHIMG editorial — based on content published by Zluri: The IT Admin's Guide to JML - Joiners, Movers, and Leavers Automation
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams automate joiner, mover, and leaver access changes?
A: Security teams should tie access decisions to authoritative lifecycle signals such as HRMS create, update, and termination events, then map those signals to predefined entitlement rules.
Q: Why do mover events create more identity risk than joiners or leavers?
A: Mover events are risky because the excess access usually does not break anything, so it remains invisible for long periods.
Q: What breaks when offboarding does not include shadow IT?
A: When offboarding ignores shadow IT, former users can keep active access to applications IT never tracked, including trials, department-managed tools, and self-service SaaS.
Practitioner guidance
- Map lifecycle triggers to access outcomes Define which HRMS fields, request events, and termination signals must create immediate provisioning, recalculation, or revocation actions.
- Separate birthright access from exception access Encode baseline entitlements by role and keep exception access time-bound, approved, and easy to remove.
- Audit mover controls for access accumulation Review recent promotions, transfers, and manager changes to confirm old access was removed when new access was added.
What's in the full article
Zluri's full guide covers the operational detail this post intentionally leaves for the source:
- Role-by-role onboarding playbook logic for joiners, including contextual app recommendations and in-app channel assignment
- Automation rule chaining for mover events, including how old-role removal and new-role provisioning are sequenced
- Offboarding workflow detail for shadow IT discovery, device retrieval, backup before license termination, and full account deletion
- Access request handling for contractors and event-based movers, including expiry settings and approval history
👉 Read Zluri's guide on joiners, movers and leavers automation →
JML automation in IAM: where access lifecycle breaks down?
Explore further
01/07/2026 2:22 am
JML automation is now a baseline governance requirement, not an efficiency upgrade. Manual joiner, mover, and leaver handling breaks because identity change is continuous while human intervention is intermittent. The result is access drift, delayed revocation, and entitlement gaps that no static review cycle can fully catch. Practitioners should treat lifecycle automation as part of core IAM control design, not a back-office convenience.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why lifecycle and revocation failures persist in practice.
A question worth separating out:
Q: Who is accountable when lifecycle access changes are not completed on time?
A: Accountability should sit with the identity or IT owner who controls lifecycle workflow design, because incomplete JML is a governance failure, not a user behaviour issue. The relevant control question is whether the organisation can prove that provisioning, changes, and revocation happen from authoritative signals and are auditable end to end.
👉 Read our full editorial: Joiners, movers and leavers automation is identity governance at scale
