Skip to content
Start with Identity
Join free
SWI-T016 · Identity lifecycle

Mover entitlement accumulation

An employee who changes roles keeps every entitlement from every prior role, because provisioning adds access automatically and nothing removes the old access automatically.

WidespreadHard to detect
First observed: 2008ATT&CK T1078 ↗

How it works

Mover entitlement accumulation is the access an account keeps from every job its owner used to hold. A transfer or promotion grants the new role's access, but the old role's access stays, so any attacker who compromises the account inherits the union of all of them.

Joiner, mover, leaver automation handles joiners and leavers reasonably well because both have a forcing event: a new hire cannot work without access, and HR marks a departure. The mover event has no equivalent forcing function on the removal side. The pattern runs like this:

  1. HR records the change. A department, job title, cost centre or manager attribute changes in the HR system and flows to the directory.
  2. Provisioning grants the new role. Attribute-based rules, birthright roles and dynamic groups add the access the new title needs, often on the same day, because someone is waiting to start work.
  3. Most of the old access does not depend on the attribute. Rule-based memberships recalculate when the attribute changes, but direct group assignments, approved access requests, application-level roles, shared mailboxes and admin grants were never tied to the old title. Nothing in the change says "remove these".
  4. Disconnected applications are invisible. Access held in apps that keep their own accounts and permissions, outside the identity provider, is a local login bypass for governance too. The IGA platform cannot revoke what it cannot see.
  5. The layers stack. After several moves, the account's entitlements record every job held rather than the current one, including combinations that segregation of duties rules would block for a new hire.
  6. An attacker inherits everything. Phishing, an infostealer or a help desk reset gives the attacker a valid account whose reach no current manager fully knows.

Why it works

Least privilege assumes access matches current job function. The assumption that fails is that granting and removing are symmetric processes triggered by the same event. They are not. A transfer is a positive event, and grants are easy to automate because the person asking is blocked. Nobody is blocked by too much access, so removal depends on a deliberate review catching what automation leaves behind.

The control frameworks know this. NIST SP 800-53 Rev. 5 has a dedicated control, PS-5 Personnel Transfer, requiring organizations to "review and confirm ongoing operational need for current logical and physical access authorizations" when people are reassigned, and to modify access to match. AC-2 requires account managers to be notified within a defined period "when users are terminated or transferred" and to "align account management processes with personnel termination and transfer processes". The gap is in carrying it out. A US Department of Homeland Security inspector general audit of USCIS (OIG-22-65, September 2022) found 864 people who transferred between USCIS offices in fiscal year 2021 without being formally tracked to confirm their access was still appropriate. The IT office relied on each new supervisor to review access on their own initiative, with no control to enforce it. USCIS had identified the gap in an internal review in May 2017 and still had not closed it in August 2022.

Periodic certification does not catch up on its own: reviewers shown raw group names approve them.

How to detect it

  • Grant without a matching removal (Entra audit log). Correlate an "Update user" audit event whose modified properties show a new department or job title with the "Add member to group" events that follow. Flag users with no "Remove member from group" events in the following weeks. Do the same for "Add member to role" and "Add eligible member to role" for privileged roles.
  • Same pattern in the Okta System Log. In Okta, look for user.account.update_profile followed by group.user_membership.add or application.user_membership.add, with no group.user_membership.remove or application.user_membership.remove. Watch user.account.privilege.grant and group.privilege.grant for admin rights that survive a move.
  • Peer distance. Microsoft Entra access reviews offer a User-to-Group Affiliation recommendation that scores each member's distance from the rest of the group in the reporting structure and recommends Deny for low affiliation. That is close to a mover detector. It needs an Entra ID Governance license, a populated manager attribute, and groups of 600 users or fewer.
  • Disuse. The inactive-user recommendation in Entra access reviews recommends Deny for users who have not signed in within 30 days, and for application assignment reviews it checks last activity in the app rather than the tenant. Entitlements unused since a role change most likely belonged to the old role.
  • Role baselines. Compare each account with the role-mined baseline for its current title and flag the outliers.
  • Campaign metrics. Certification campaigns with high completion and near-zero revocation suggest reviewers are approving without evaluating, not that access is clean.

Be honest about the limits: some roles legitimately need cross-functional access, peer-distance models flag deliberate exceptions, and disuse windows miss quarterly or annual tasks. None of these signals sees disconnected applications. Treat each result as a review prompt, not a verdict.

How to stop it

  1. Make the move itself a removal trigger. Microsoft Entra Lifecycle Workflows include mover tasks such as "Remove user from selected groups", "Remove all access package assignments for user" (in mover templates the default is scheduled removal after 15 days, which gives a handover window), "Send email to notify manager of user move" and "Revoke all refresh tokens for user". The feature requires Microsoft Entra ID Governance or Microsoft Entra Suite licenses. IGA platforms such as SailPoint and Saviynt can also run lifecycle actions on attribute changes; configure the removal side explicitly.
  2. Grant through packages and roles that expire. Access granted as a time-bound assignment, or tied to an attribute through RBAC or ABAC, falls away on its own when the attribute changes. Direct assignments do not.
  3. Run an event-driven review for the new manager. Send a targeted review when the move happens, rather than waiting for the annual campaign, and show last-use data next to each entitlement.
  4. Enforce SoD rules at grant time, so a toxic combination built from old and new roles is blocked or flagged automatically, independent of any review.
  5. Remove standing privilege. Privileged rights through just-in-time access or zero standing privileges cannot accumulate across moves.
  6. Connect or inventory every application, including ones with local accounts, so the removal reaches them.
  7. Track revocation rate, not completion rate, for access certification. See the identity governance program guide and what is IGA.

Seen in the wild

We have no publicly attributed breach in our catalog where an incident report traced the attacker's access specifically to unrevoked entitlements from a prior role. Mover accumulation is found in access reviews and audits, not named in post-mortems, so it shows up in audit reports rather than breach write-ups:

The sibling technique is orphaned account abuse, where the whole account outlives its owner rather than just part of its access.

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.