It happens because role changes are often gradual, ambiguous, and cross-functional, while access governance assumes a clean handoff. If revocation is not explicitly tied to the move, legacy permissions remain attached and the account slowly accumulates history instead of reflecting current duties.
Why access creep appears during role changes
access creep is usually a process failure, not a one-time mistake. When people move between roles, managers and application owners often add new entitlements faster than old ones are removed, especially if the move is temporary, partial, or split across teams. The result is cumulative access that no longer matches job need, which is why Joiner-Mover-Leaver (JML) Guide matters so much in identity governance.
Role changes create ambiguity because the business thinks in terms of responsibilities, while access systems think in terms of entitlements. A promotion, lateral move, project assignment, or acting-back arrangement may justify new access immediately, but the old access often remains because no one owns the revocation step. That gap is where privilege creep starts.
Cross-functional moves make the problem worse. When an employee spans operations, finance, engineering, or support, each team may grant access based on its own local approval path. Without a clear authoritative source for the new role, entitlement cleanup becomes optional, delayed, or dependent on memory instead of policy.
How gradual transitions turn into lingering entitlements
Access creep is rarely the result of a single bad decision. It usually accumulates because each small exception seems harmless in isolation: a temporary report, a shared dashboard, a legacy admin role, or a dormant application account left in place for convenience. Over time, those exceptions stack up and become normalised access history.
The longer a role transition takes, the more likely legacy access survives. If the employee keeps old access “just in case”, the account stops reflecting current duties and starts reflecting past ones. That is why the strongest controls connect provisioning and deprovisioning to role change events, not to periodic housekeeping. A good IAM and IGA Basics model treats access review, entitlement management, and least privilege as lifecycle functions, not occasional audits.
Some organisations also miss inherited access paths. A changed role may bring new group membership, application roles, API permissions, or delegated admin rights, but downstream entitlements can remain attached through nested groups or indirect assignments. That is why the practical question is not only “what did the role add?” but also “what should the move have removed?”
What governance has to change to stop it
The control problem is often an ownership problem. If no single workflow owns mover events end to end, cleanup depends on ad hoc coordination between HR, line management, IT, and app owners. The cleaner the handoff, the less room there is for old access to survive. For role-based environments, careful use of Authorisation Models Guide can help teams distinguish role assignment from entitlement inheritance and spot where RBAC alone is too coarse.
Good governance starts by treating every move as a change to both granted and revoked access. That means comparing current duties against current entitlements, not simply appending new permissions. It also means validating exception access, because temporary access often becomes permanent when nobody sets an expiry date or return-to-owner date.
At scale, access creep is easier to detect when organisations reconcile role, manager, and entitlement data together. If a user’s active permissions still match a prior function more than the current one, that is a signal that the control model is drifting. In practice, this is where access review, entitlement rationalisation, and joiner-mover-leaver discipline have to work as one process rather than three separate activities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Role moves require ongoing account and entitlement updates to remove stale access. |
| AC-6 — Least Privilege | Access creep is the opposite of least privilege, leaving excess permissions in place. | |
| Recommendation — Tie role changes to account updates and revoke stale entitlements promptly. Continuously trim permissions to the minimum needed for the current job. | ||
| CIS Controls v8 | CIS-5 — Account Management | Mover events depend on disciplined account lifecycle and access removal control. |
| Recommendation — Maintain authoritative account inventories and remove unnecessary access during role changes. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Role changes need formal review and removal of access rights that no longer fit duties. |
| A.5.16 — Identity management | Mover events require identities to reflect the current role and scope of access. | |
| Recommendation — Review and revoke access rights whenever job responsibilities change. Keep identity records aligned to current responsibilities and ownership. | ||
Practitioner Guidance
What to verify: On every role move, verify both sides of the change, new access gained and old access removed. If your workflow only approves additions, you are creating structural creep even when individual approvals look valid.
Decision rule: If the move changes teams, duties, or reporting line, require an explicit entitlement revalidation before the change is considered complete. If the role is temporary, time-box the exception and set a revocation trigger up front.
What practitioners underestimate: The hardest part is not the new access request, it is the cleanup of “still needed” legacy access. That leftover access is what turns a normal transition into accumulated privilege.
Practitioner takeaway: Access creep is controlled best by making role change itself the trigger for entitlement subtraction, not just entitlement addition.
Related resources from NHI Mgmt Group
- How should organisations handle multi-affiliation access when employees move between roles or contracts?
- What is the difference between rotating a secret and revoking access?
- How should security teams prevent access from accumulating as employees move across roles and departments?
- How should organisations automate data protection when employees move between teams or roles?