The Mover Process: Automating Access Recompute

Of the three events in joiner-mover-leaver, the mover process access recompute is the one IT teams underestimate most. Joiners are simple: someone starts, you grant a known set of access. Leavers are simple too, at least in principle: someone leaves, you remove everything. Movers sit in between, and that middle ground is where most access sprawl actually comes from.

A mover is anyone who changes role, department, location, manager, or team without leaving the company. A support engineer promoted to team lead. A finance analyst who transfers from AP to FP&A. Someone who moves from the Rotterdam office to the Utrecht office and now needs a different set of shared drives. Each of these events should trigger a recompute of that person's access: add what the new role requires, remove what the old role no longer justifies. In practice, most organizations only do the first half.

This article looks at why the mover event is structurally harder than joiners or leavers, and how an attribute-driven recompute, combined with a short grace period, solves it without breaking anyone's workday.

Why the Mover Event Breaks Traditional Access Models

Joiners and Leavers Are Binary

Onboarding and offboarding are, at their core, on/off switches. A new hire starts from zero and access gets built up. A departing employee's account gets disabled and everything is revoked at once. Both are clean, auditable, and relatively easy to automate because there is a clear before-state and after-state.

The Mover Is a Delta, Not a Switch

A mover's access needs to change from set A to set B while the person is still actively working, often on the same day their new role starts. There is no natural "everything off" moment to anchor the change. Most ticket-based or manual processes only handle the addition: IT creates a request for the new groups the person needs, because someone will notice quickly if access is missing. Nobody files a ticket to remove the old finance group, because nobody notices access that is simply unused. That asymmetry is exactly how standing access and privilege creep build up over a career at one company.

Every Internal Move Is a Small Security Event

Each mover event quietly widens the blast radius of that account. Someone with three years of accumulated group memberships from four different roles is a much more attractive target, and a much bigger liability, than someone with access matched to their current job. Access reviews eventually catch some of this, but reviews are a detective control. The mover event is the moment a preventive fix is actually possible.

What Attribute-Driven Recompute Actually Does

Attribute-driven, or ABAC, access management ties group and role membership to attributes in Entra ID and on-prem Active Directory rather than to a person's history of manual requests. Typical attributes include:

• Department or cost center
• Job title or role
• Office location or country
• Manager or reporting line
• Employment type (employee, contractor, intern)

When any of these attributes change in the HR system or directory, the rules engine recomputes the full set of access that person should have, based on current attributes only. It is not "add the new team's groups" as a one-off action; it is a re-evaluation of the entire access profile against the current rule set.

Why Recompute Beats a One-Off Role Change

A one-off role change only adds what someone explicitly requests. A recompute compares the desired end-state (what the rules say this person should have, right now) against the actual state (what they currently have), and produces two lists: what to add and what to remove. That second list is the part manual processes almost never generate on their own.

Adding New Access Automatically

The addition side of a mover event is the easier half, and most organizations already do a version of it. With attribute-driven rules in place, it becomes fully automatic instead of ticket-driven:

1. The attribute change (new department, new title, new location) lands in Entra ID or the HR feed.
2. The rules engine matches the new attribute combination against existing group and role definitions.
3. The relevant Entra ID and on-prem AD groups are assigned immediately, so the person has day-one access in their new role without waiting on a helpdesk queue.

This is also where group mining helps before you even define the rules: by analyzing existing group membership patterns, you can see which groups actually correlate with department, title, or location, and turn those patterns into rules instead of guessing.

Removing Old Access Without Breaking Anything

Removal is where teams get nervous, and understandably so. Revoke access too aggressively and you risk cutting someone off from a file, mailbox, or application they still legitimately need mid-transition. That fear is exactly why so many organizations quietly decide not to automate removal at all, and instead leave it to an annual access review that catches the leftovers a year later.

The Grace Period

A grace period solves this without requiring a judgment call on day one. Instead of removing old access the instant the attribute changes, the recompute flags it for removal and holds it for a defined window, typically one to four weeks, during which the access still works but is marked as pending revocation.

Day	Event
Day 0	Attribute change detected, new access granted immediately
Day 0	Old access flagged as "pending removal", grace period starts
Day 0-14	Old access still functions; owner or the mover can request an exception if it's still needed
Day 14	Grace period ends, flagged access is automatically removed

This gives the mover time to wrap up handovers, finish documents in the old shared drive, or close out tickets still assigned under the previous team, while guaranteeing the access doesn't just quietly persist forever. It also gives group and resource owners a chance to flag a legitimate exception (a person keeping one specific group for a defined transition project, for example) before the removal executes.

Building a Safe Mover Workflow

A practical mover workflow, whether you build it yourself or run it through a platform, needs a few components working together:

• A reliable attribute source. HR data or Entra ID attributes need to be accurate and current, since the whole recompute depends on them.
• Rules that map attributes to access, ideally derived from real, observed group patterns rather than written from scratch.
• An addition step that runs immediately, so new hires and movers are never blocked by helpdesk queues.
• A removal step with a grace period, so old access is revoked reliably but not abruptly.
• An exception path for owners, so legitimate edge cases don't get steamrolled by automation.
• A log of every add and remove, so access reviews and audits have a clear trail of what changed, when, and why.

The access and group-membership side of joiner-mover-leaver maps directly onto this: as attributes change, membership follows. For organizations that also want the HR system to drive the account-level onboarding and offboarding steps, that is achievable on top of Azure automation accounts and runbooks, but the mover-specific value, the part that actually stops access creep, is the attribute-driven recompute itself.

ServiceChanger's ABAC engine runs exactly this pattern for Entra ID and on-prem Active Directory: it recomputes each mover's access automatically, adds what the new role requires the same day, and removes what's no longer justified after a configurable grace period, all logged for your next access review.

FAQ

What exactly counts as a mover event? Any change to an employee's department, job title, location, manager, or employment type while they remain employed. It's distinct from a joiner (new hire) or a leaver (departure), and it's usually triggered by an attribute change in the HR system or in Entra ID rather than by a single ticket.

Why not just remove old access immediately when someone moves roles? Immediate, hard removal risks cutting off access to files, mailboxes, or shared resources the person genuinely still needs during a handover. A short grace period keeps old access working for a defined window while it's flagged for removal, which is safer in practice and still closes the gap reliably.

Does attribute-driven recompute replace access reviews? No, it complements them. Recompute is a preventive control that keeps access aligned to current attributes automatically. Access reviews remain useful as a periodic check, but with recompute running continuously, reviews find far fewer stale permissions because most of the drift never accumulates in the first place.

Can this work with on-prem Active Directory as well as Entra ID? Yes. Mover events are common in hybrid environments where some groups live in on-prem AD and others in Entra ID. A rules engine that spans both keeps the recompute consistent regardless of where a given group or role actually lives.

If mover events are quietly building up standing access in your environment, it's worth mapping out how your current process handles the removal half, not just the addition half. See how ABAC-based access control compares to role-based models, or browse more on lifecycle automation and ABAC on the ServiceChanger blog.