What should teams do when a user moves from one role to another and keeps old access?

Treat the move as an identity lifecycle event, not just a permissions update. Role changes are where access creep turns into SoD conflict, because previous rights may now overlap with new responsibilities in ways that break separation. Offboarding obsolete access at the same time as role transition is the control point that matters.

When a role change happens, what control should own the access cleanup?

A role move should be handled as a joiner-mover-leaver style lifecycle event, not as a casual permissions tweak. The practical control is to compare the old and new role side by side, remove access that no longer has a business need, and verify that any residual rights do not create separation of duties conflicts or hidden privilege creep.

That means the question is not only “what should this person gain?”, but “what must be removed now that their duties have changed?”. If teams only add the new entitlements and leave the old ones in place, the user can accumulate overlapping access that is technically functional but operationally unsafe.

For identity governance teams, the key output is a clean transition record: old role, new role, retained access with a reason, and removed access with evidence. This is the point where IAM and IGA Basics becomes operational, because role transition is where entitlement hygiene and SoD enforcement have to work together rather than as separate processes.

Why old access becomes a problem after the move

Old access becomes risky because it often reflects the previous job, not the current one. A mover may keep approver rights, elevated application access, or access to sensitive data paths that are no longer justified, and those rights can conflict with the responsibilities of the new role.

The main failure mode is privilege accumulation. When retained access is never re-evaluated, the user’s effective permissions become a composite of several jobs over time. That creates access creep, makes reviews noisy, and can leave a person able to both request and approve activity in the same workflow, which undermines separation of duties.

This is also where review processes can fail silently. If the organisation treats role change as a spreadsheet update instead of a lifecycle event, old entitlements survive until the next audit or incident. Access Reviews and Certification Guide is relevant here because mover events are one of the best times to close the loop on stale access instead of waiting for periodic recertification.

How to make the transition safe without slowing the business

The safest pattern is to make the new role the trigger for entitlement reconciliation. Start from the destination role’s minimum access, then add only the explicit exceptions the person still needs, with an owner and expiry where possible. That keeps the review focused on business necessity instead of historical convenience.

Teams should also distinguish between direct entitlements and inherited access. If a user’s old permissions came through group membership, application role mapping, or delegated workflow rights, those paths need to be removed at the source, not just masked in a ticket. Otherwise the same access can reappear on the next sync or provisioning cycle.

Role changes are also the point to re-check whether the user can still reach systems they should no longer influence. In environments with RBAC, ABAC, or mixed models, the transition should be validated against the actual authorisation model rather than assumed from the HR title alone. Authorisation Models Guide helps because the cleanup logic depends on how entitlements are granted and evaluated.

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 sets 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 timely removal of obsolete account access.
	AC-6 — Least Privilege	Moved users should retain only access justified by the new role.
	AU-6 — Audit Review, Analysis, and Reporting	Transition records and exceptions need reviewable evidence of cleanup.
Recommendation — Reconcile entitlements on role change and disable access no longer needed. Trim retained permissions to the minimum needed for the new duties. Review mover-event logs for lingering access and unresolved exceptions.
ISO/IEC 27001:2022	A.5.18 — Access rights	Access rights must be removed or adjusted when job duties change.
	A.5.15 — Access control	Role transitions must enforce current-authority access decisions.
Recommendation — Revoke obsolete access promptly when roles change. Apply access control rules to rebaseline entitlements after a move.

Practitioner Guidance

What to verify: Confirm that the post-move access set is role-appropriate, not merely smaller. The important check is whether any retained entitlement creates SoD conflict, approver-to-requester overlap, or access to data and systems no longer needed for the new job.

Decision rule: If the old access is not clearly required in the new role, remove it now and document the exception only when the business owner can name a concrete need and an expiry date. If the entitlement grants privileged or cross-function access, treat it as high priority for immediate removal and validation.

What good looks like: The mover process produces a before-and-after access comparison, a removal record for obsolete rights, and a short list of justified exceptions. At scale, the goal is consistency, every role change should converge toward least privilege instead of accumulating legacy access.

Practitioner takeaway: The risk is rarely the new access alone, it is the combination of old and new rights after the role move. Teams should make access removal part of the transition itself, because that is where privilege creep and SoD conflicts are actually prevented.