Topic starter
06/11/2026 6:37 pm
TL;DR: Manual joiner-mover-leaver workflows create orphaned accounts, privilege creep, audit gaps, and wasted time across Active Directory and Microsoft 365, according to Cayosoft’s guide, while automation and continuous governance keep access aligned with role changes and departures. The core issue is not provisioning speed but whether lifecycle controls stay current when identities, entitlements, and privileged access keep changing.
Editorial analysis by NHI Mgmt Group, based on content published by Cayosoft: “Joiner-Mover-Leaver Automation: How to Get It Right”.
By the numbers:
- Done manually, that process can take an IT admin 30 minutes or more per user.
Key questions
Q: What should teams do first when a user leaves and access must be revoked?
A: Start with an immediate full access shutdown for the user’s active accounts, then disable SSO, VPN, email, and privileged sessions, and revoke tokens, certificates, and password reset paths.
Q: Why do mover events create privilege creep so quickly?
A: Mover events create privilege creep because each internal change usually adds new access while removal is delayed, incomplete, or forgotten.
Q: How should organisations govern identity lifecycle changes across users and non-human accounts?
A: They should use the same governance discipline for both, but with actor-specific execution.
Practitioner guidance
- Map every identity trigger to an access outcome Define exactly what should happen for hires, transfers, promotions, leaves, terminations, contractor expiry, and role removal, then bind those events to downstream account and entitlement changes.
- Extend offboarding beyond employee accounts Create explicit ownership and revocation paths for service accounts, app registrations, workload identities, shared mailboxes, and automation identities that never appear in HR records.
- Remove prior-role access before adding new access Design mover workflows to revoke old group memberships, delegated admin rights, and direct cloud roles first, then provision the replacement access set for the new role.
Bottom line: Manual joiner-mover-leaver handling leaves organisations exposed to orphaned accounts, privilege creep, and incomplete audit evidence.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
JML is now a governance system, not a provisioning script. The old model treated joiner-mover-leaver as a ticket workflow for account setup and removal. That framing no longer holds when the same process must govern people, service accounts, app registrations, workload identities, and privileged cloud roles. The discipline is really about keeping access continuously aligned to business state, which means lifecycle control has to sit inside identity governance rather than beside it. Practitioners should treat JML as an enterprise control, not an admin convenience.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations govern identity lifecycle changes across users and non-human accounts?
A: They should use the same governance discipline for both, but with actor-specific execution. Joiner, mover, and leaver events should trigger authoritative provisioning and revocation, while service accounts and tokens should be tied to workload ownership and expiry. The goal is to prevent access from outliving the business need that created it.
👉 Read our full editorial: Joiner-mover-leaver automation closes lifecycle gaps in hybrid IAM