How do I stop privilege creep when employees change roles?

How privilege creep starts when roles change

Privilege creep usually begins with a practical shortcut: a new role is granted the permissions needed for the next job, but the old role is left intact. Over time, that creates accumulated access that no longer matches the employee’s current responsibilities, which weakens least privilege, complicates audits, and expands the blast radius of a compromised account.

In mature access governance, the move event should be treated as a reset point. The access model should compare the employee’s current entitlements against the target role and remove anything that is no longer justified, rather than assuming the new access set can simply be layered on top.

That discipline is why joiner-mover-leaver handling is central to preventing creep, and why Joiner-Mover-Leaver (JML) Guide belongs in the operational playbook for role changes.

Which access controls actually stop it

Role-based access control is useful only if roles are maintained as living job profiles, not as historical bundles of “extra” permissions. When role design drifts, the permission set becomes a record of past exceptions instead of current need, which is exactly how privilege creep becomes normalised.

Access recertification matters because it creates a formal checkpoint where managers and access owners must confirm whether each entitlement still fits the current position. The review should be evidence-based, not ceremonial: if nobody can explain why an access path still exists, it should be removed or re-approved against the current role.

For inherited administrative rights, PAM should sit above the general access model so that elevated access is time-bounded, traceable, and more tightly controlled than ordinary business access. NHIMG’s Least Privilege Techniques Guide is a useful companion when you need to right-size accumulated access without breaking legitimate work.

Access governance also works better when the role catalogue, entitlement inventory, and approval path are visible in one place. IAM and IGA Basics helps connect those governance pieces to the practical question of who should keep what after a move.

How to remove the old access safely

The hardest part is not granting the new access, it is removing the old access without disrupting legitimate work. A good mover workflow starts with identifying the destination role, comparing it to the current entitlement set, and revoking anything not required by the new function before broadening access further.

That sequence matters because it prevents overlap from becoming permanent. If you add the new role first and defer cleanup, the employee can continue carrying the old permissions indefinitely, and the exception often survives because there is no second, explicit review point.

Some access is not safe to treat as ordinary business entitlement. Administrative rights, privileged group membership, and long-lived delegated access should be handled as exceptions with tighter approval, expiry, and logging. Where role changes touch shared systems or elevated accounts, the control should also verify whether tokens, sessions, or standing admin paths need to be reissued rather than merely edited in place.

The same principle applies when role change affects cloud or platform administration. CyberArk Security Hardening Guide is relevant where the mover process intersects with privileged credential handling and vault-backed admin workflows.

Practitioner Guidance

What to verify: Make the mover workflow compare current entitlements against the target role, then require explicit justification for every retained exception. If the retained access is not tied to a current business need, treat it as removable, not as “legacy access.”

Decision rule: If the move introduces a new role with broader access, first remove obsolete permissions, then add only what the destination role requires. If privileged access is involved, route it through a separate approval and expiry path instead of folding it into the normal move process.

What good looks like: Each role change produces a visible delta, with removed access recorded as deliberately as granted access. Managers, access owners, and PAM administrators should all be able to explain why an entitlement survived the move.

Practitioner takeaway: Privilege creep is rarely caused by one bad grant, it is caused by failing to make role changes a removal event as well as an addition event.

Related resources from NHI Mgmt Group

• How should security teams handle NHIs when employees leave or change roles?
• How should federal teams manage identity access when employees change roles or locations?
• Who should be accountable for SSH access when employees leave or change roles?
• How should organisations handle access when employees change roles internally?