Movers keep everything

Joiners get provisioned. Leavers get disabled. Movers keep everything. Of the three identity lifecycle events, the move is the one that breaks least privilege without anyone noticing. This note looks at why, and at what Entra ID can take away on its own.

How access piles up

Someone transfers from finance to operations. Their new access is added the day they start. Their old access stays, because nobody filed a ticket to remove it and the old manager assumes IT will. Two or three moves later, that account can reach more than anyone in either department.

Microsoft's own definition of a mover expects the add: someone who moves between boundaries inside the organization, in a change that might require more access. The removal is the half that needs a decision.

Fix the attribute where it starts

I ran joiner, mover, and leaver workflows tied to HR inputs for a 4,300-user tenant, with dynamic groups keyed on HR attributes. If HR data lands in Active Directory and Entra Connect syncs it up, correct the department or job code there and let dynamic groups follow the attribute, instead of editing cloud groups by hand.

That works because of how dynamic membership is evaluated. When a user's attributes change, Entra checks every dynamic group rule in the directory. A user who now matches a rule is added, and a user who no longer matches is removed. Nobody can add or remove members of a dynamic group by hand, so a group built on a rule such as user.department -eq "Finance" stays equal to whoever HR says works in finance.

Dynamic groups need an Entra ID P1 license for each unique user in them, and they only cover access granted through those groups. Access granted any other way, such as a direct app assignment or a group someone manages by hand, still has to be removed.

Decide what a move takes away

Treat a transfer as a removal event as well as an add, and decide in advance what a move takes away. Lifecycle workflows can carry out that decision. The Employee job profile change template is a mover workflow that runs when a user attribute or a group membership changes, and its tasks include:

• Send an email to tell the manager about the move.
• Remove the user from selected groups and from selected Teams.
• Remove all of the user's access package assignments, on a schedule that defaults to 15 days.
• Request an access package assignment for the user.

Lifecycle workflows need a Microsoft Entra ID Governance or Entra Suite license, and a tenant can have up to 100 of them. The template doesn't know what a move from finance to operations should remove, though. That list has to come from the business.

Review anyway

Access reviews catch what the first two steps miss, and two of their decision helpers fit movers.

With the inactive-user helper on, a review shows each user's last sign-in and recommends Deny for anyone who hasn't signed in for 30 days. In a review of app assignments, the check uses the user's last activity in that app rather than in the whole tenant. That's the version that can catch a mover, who still signs in every day, just not to the old team's app. The sign-in date and the recommendation are set when the review starts and don't update while it runs.

The user-to-group affiliation helper looks at the reporting structure instead. A group member who sits far from the rest of the group in the org chart gets a Deny recommendation, which describes a mover still in the old department's group. It needs a Microsoft Entra ID Governance license, a manager attribute on each user, and a group of 600 users or fewer.

Either way, a recommendation isn't a removal. The reviewer still decides.

When someone changes departments in your organization, who removes the old access?