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.
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
Related on Start with Identity
- CVEOkta Verify for Windows local privilege escalation
Okta Verify on Windows could be turned into a local privilege escalation. The MFA app on the endpoint is part of the identity plane. Pair with Okta's 2024 FastP
- CVEVault root privilege escalation via policy-name normalization
Vault normalized policy names in a way that let a lower-privilege token become root. CVSS 7.2. Part of the August 2025 VaultFault set.
- RankingBest CIEM for Enterprises: Top 4 Cloud Entitlement Platforms
The best enterprise CIEM platforms in 2026: Wiz, Sonrai Security, Britive, and Microsoft Entra Permissions Management. Ranked for multi-cloud discovery, least p
- RankingBest CIEM for Multi-Cloud: Top 5 Entitlement Platforms
The best multi-cloud CIEM platforms in 2026: Wiz, Tenable Cloud Security, Prisma Cloud, Orca Security, and Sonrai Security. Ranked for cross-cloud discovery, le
- GlossaryEntitlement
A specific permission or right an identity holds over a resource. Governance and CIEM exist to keep entitlements understood, justified, and minimal. Entitlement
- ArticleTop 5 Cloud Infrastructure Entitlement Management (CIEM) Platforms in 2026
Compare the top 5 CIEM platforms, Ermetic (Tenable), Zscaler CIEM, CrowdStrike Falcon Cloud Security, Wiz, and Orca Security, to manage cloud permissions, reduc