Start with Identity
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 to detect
First observed: 2008ATT&CK T1078

How it works

Joiner, mover, leaver automation handles the joiner and leaver events reasonably well, because both have a clear trigger: a new hire needs access to start, and HR marks a departure that triggers removal. The mover event, an internal transfer or promotion, has no equivalent forcing function on the removal side. The new role's access gets added, usually automatically through role-based provisioning tied to the new title or department, but the old role's access is rarely revoked in the same motion, because nothing in most provisioning systems treats "no longer in this role" as an event that requires action.

Over a career inside one organization, this produces employees whose entitlements are a layered record of every job they have held rather than a reflection of the job they currently hold. An attacker who compromises such an account, through phishing, credential theft, or any other initial access method, inherits not just the current role's access but the accumulated access of every prior role, often including systems the current manager does not know the employee can still reach and would not think to review.

Why it works

Least privilege depends on access matching current job function, and the control assumption that fails is that provisioning and deprovisioning are symmetric processes triggered by the same event. They are not: a transfer is a positive event that triggers granting, and grants are easy to automate because someone is waiting to work. Revocation has no equivalent urgency, nobody is blocked by an account that has too much access rather than too little, so it depends entirely on a deliberate review catching what automation does not remove on its own. Where that review does not happen, or happens against raw entitlement lists a manager cannot meaningfully evaluate, the accumulation goes uncorrected indefinitely.

How to detect it

  • Comparing an account's current entitlements against a role-based baseline for its current title and flagging anything outside that baseline as a candidate for review.
  • Entitlements with no usage in the several months following a role change, which is a strong signal the access belonged to the prior role and was never exercised in the new one.
  • Access certification campaigns with high completion rates and very low revocation rates, which auditors read as evidence that reviewers are approving without evaluating rather than as evidence access is clean.

Be honest about the limits: some roles legitimately need broad, cross-functional access, and not every accumulated entitlement is a mistake. Detection has to separate deliberate cross-functional grants from unreviewed leftovers, which requires usage data and role context, not a simple entitlement count.

How to stop it

  • Trigger a full access review at every mover event, treating a transfer the same as a new hire for review purposes rather than only for granting new access.
  • Show reviewers usage data, not entitlement names, since a reviewer shown "this access has not been used in 180 days" revokes it, while a reviewer shown only a group name approves it.
  • Enforce segregation of duties rules so that an accumulated combination of entitlements that should never coexist on one person is blocked or flagged automatically, independent of any scheduled review.
  • Time-box high-risk entitlements so they expire and require re-justification rather than persisting indefinitely once granted.
  • Track revocation rate, not completion rate, as the metric that actually indicates whether certification campaigns are catching mover accumulation. See access certification.

Seen in the wild

We have no publicly attributed breach in our catalog where a named incident report specifically traced the attacker's access back to unrevoked entitlements from a prior role. Mover accumulation is a well-documented audit finding, not a technique post-mortem investigators tend to name in public writeups, likely because it is discovered in access reviews rather than incident response. See ITGC audits and identity: the access certification evidence auditors accept for how auditors surface it.

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 [email protected]. 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.