Joiner-Mover-Leaver Automation: Governed Changes with Avatier

Joiner-mover-leaver (JML) automation runs every change to a person's access, when they join, move, or leave, as a governed identity action: requested, checked against policy, approved, applied, and recorded. Joiners and leavers get the attention. Movers are where access piles up.

A joiner who waits for a laptop login gets noticed on day one. A leaver with a live account is an audit finding. A mover who keeps last year's access may cause no complaint at all, which is why it can last.

The three lifecycle moments

Each moment changes something different, and each has a different failure.

Moment	What changes	What goes wrong
Joiner	Accounts created, starting groups and roles granted	Late access on day one, or a copy of someone else's access
Mover	Role, team, manager, or location changes; access should follow	New access added, old access never removed
Leaver	Accounts disabled, access and roles removed	An account outlives the person

Joiners and leavers have a clear start and end. The joiner arrives; the leaver goes. A mover has neither. The person stays, the account stays, and only the need changes, so nothing forces anyone to decide what the old access is for.

Joiners get access, leavers lose it, and movers need both at once: the old role's access comes off as the new role's goes on.

Why movers accumulate access

The mechanism is simple: add without remove. A move creates a visible need. The new team needs a shared drive, a finance app, a different group. Someone requests it and it gets granted. Removal has no requester. The old manager has moved on to other work, the person may still need some old access during a handover, and no date is set to take it away.

Do that once and the person holds two roles' worth of access. Do it three times and they hold four. This is privilege creep. The Identity Attack Ledger describes over-provisioned standing access the same way: "Privilege creep and entitlements nobody revoked."

Public breach data will not show you how much of it you have. Avatier's Identity Attack Ledger reads 2,161 breach notifications filed with the California Attorney General from January 1, 2023 through August 14, 2026. None of them names over-provisioned standing access as the attack vector, and none names orphaned or dormant accounts. The ledger is explicit that this is about what notification letters disclose, not about how often those attacks happen. Sizing the risk from disclosures alone would put it at zero.

A move adds the new role's access. Unless someone removes the old role's access in the same change, the person keeps both.

Run every lifecycle change as a governed identity action

The fix is not a faster ticket. It is one governed path that every joiner, mover, and leaver change takes. As general practice:

1. Start from a request tied to a person and a role. Not a free-text ticket. The request names who changes and what they are changing to.
2. Treat a move as one change with two halves. Removal of old access and grant of new access belong to the same request, not two tickets weeks apart.
3. Route each half to the right approver. The new manager approves what is added. The old manager confirms what, if anything, stays, and for how long.
4. Put an end date on anything kept for handover. Temporary access should expire, not wait for someone to remember it.
5. Apply the change across accounts, groups, and roles together. A role change that misses group membership is a partial move.
6. Record the outcome. Who asked, what changed, under whose authority, which policy allowed it, and the result.

Step 2 matches what NIST asks for in SP 800-53 Rev. 5 control PS-5, Personnel Transfer: when people are reassigned or transferred, "review and confirm ongoing operational need for current logical and physical access authorizations," and modify access "to correspond with any changes in operational need." The control treats the move itself as the moment to review old access.

Evidence: what each change should leave behind

An auditor asking about a mover can ask what access the person held before, what changed, who approved it, and why the remaining access is still justified. If the change ran through a ticket and a manual edit, that answer gets reconstructed from emails. If it ran as a governed action, the answer is the record.

Evidence also makes the leftovers findable. Access reviews catch what the move missed, but only if reviewers can see when access was granted and for which role. Leaver changes need the same record, which is the subject of our guide to automated deprovisioning. Where lifecycle events come from your HR system, HRIS-driven identity lifecycle covers the integration side, and access governance with user lifecycle management covers how reviews reason against lifecycle state.

What Avatier ships for lifecycle changes

Avatier has run lifecycle and password management for customers for more than 20 years. In Avatier Identity Anywhere 2027™, lifecycle changes are one of the Secure Outcomes: completed, verified, policy-compliant activities.

Avatier Actions exposes more than 50 identity outcomes as MCP tools across eight modules. Two map directly to JML work:

• Lifecycle Management: request and remove access and roles, workflow participation, rehire, and transfer.
• User Management: enable, disable, delete, rename, profile and direct-report updates, organizational-unit moves, account expiration, and proxy of authority.

Group Management, Access Governance (campaign management and review), and Workflow Approval (pending requests and history) cover the groups, reviews, and approvals around them. An employee or manager asks in Teams, Outlook, Claude, or Copilot, and the outcome runs through the customer's existing policies, approvals, and roles. Nothing bypasses governance, because the assistant is the interface, never the authority. Setup is one administrator connection, with permissions inherited from Microsoft Entra ID, Active Directory, Okta, and Ping.

Avatier Ledger turns every outcome into evidence. Each Secure Outcome records the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result. The security team's Persona Briefing is built around exposure, dormant and orphaned access, privileged activity, and the vishing surface at the help desk. Under Pay Per Identity Action™, customers pay only for completed, verified, policy-compliant outcomes.

For the invitation-only preview, see the Avatier Identity Anywhere 2027™ site. For credential lifecycle, see Credential Governance. For the company, see avatier.com. For compliance, see the Avatier Trust Center: SOC 2 Type II audited with no exceptions noted, and ISO/IEC 27001:2022 certified.

Getting started with Avatier

Lifecycle changes are a natural first workload for Avatier Identity Anywhere 2027™, because joiners, movers, and leavers already run through policies and approvals you own. Avatier Actions connects once at the administrator level, and permissions are inherited from Entra ID, Active Directory, Okta, or Ping. The assistant is the interface, never the authority. Pricing follows Pay Per Identity Action™: customers pay only for completed, verified, policy-compliant outcomes. Getting started is free, deployment is included, and a 45-day money-back guarantee applies. For the full terms and the invitation-only preview, see Identity Anywhere 2027.