By Yair Knijn · October 7, 2025

The employee who changed roles four times and kept every permission: the mover nobody deprovisions

The operations director signs off on the access-control program every quarter because the joiner numbers look clean and the leaver numbers look clean. New hires get provisioned inside a day. Departures get cut off the same afternoon HR closes the record. What never lands on that dashboard is the person who started in the service desk, moved to release engineering, moved to vendor management, then moved into finance operations, and is still holding the access from all four.

The wrong assumption is quiet and reasonable: role changes are handled, because access keeps getting granted. Nobody asks the second question. When this person stopped doing the old job, did the old job's access leave with them?

Why the mover is the access-control case nobody designs for

Joiner-mover-leaver is drawn as three equal stages, but only two of them have a clean trigger. A joiner is an empty account that gets filled. A leaver is a full account that gets emptied. Both are events someone owns. The mover is the awkward middle: the account already exists, the person is still here, and the transfer ticket arrives worded as "needs access to the finance system." So that access gets granted. The line item that should read "remove access to the release pipeline" was never written, because the manager raising the ticket is thinking about the new job, not the old one.

The mechanics make it worse. Provisioning is a request someone files. Deprovisioning the old role would require the previous manager to notice a person who is no longer their report and to remember exactly which entitlements to pull. Nobody is incentivized to do that work, and the system does not prompt for it. Access creeps upward every single transfer and never comes back down.

Permission accumulation and the segregation-of-duties violation it creates

Each individual grant passed an approval. That is the trap. The release-engineering access was approved when it was the job. The finance-operations access was approved when that became the job. No single approval was wrong, so no single approval gets flagged. The damage is in the combination: the same person can now push a change to a production system and approve the payment that touches it. That is a textbook segregation-of-duties conflict, and it exists even though every grant on its own was legitimate.

This is the failure mode IAM practitioners call privilege creep, and it is precisely the one segregation-of-duties controls are built to catch. SoD is usually expressed as a conflict matrix or a toxic-policy rule that blocks two entitlements from coexisting on one identity. The catch is that those rules fire cleanly at request time, when one entitlement is being assigned. They do not fire retroactively across four transfers nobody connected, so the toxic pair sits live in the directory until something forces a look.

Periodic access reviews: the control that finds what provisioning missed

The thing that forces the look is the access review, and it exists because provisioning cannot find its own gaps. A user access review is a scheduled certification where the manager or system owner confirms each person still needs what they hold. Run honestly, it is the only control that examines the standing state of an identity rather than the moment of a single change, which is why it is the one that catches movers.

• Pull the full entitlement set per identity, not the most recent grant.
• Flag anyone whose access spans systems that map to more than one job function.
• Run the standing access against the SoD conflict matrix, not just new requests.
• Make a named manager certify or revoke each line, with revocation as the default for anything tied to a role the person left.

Making the mover ticket revoke as well as grant

Reviews catch the accumulation after it has built up. The cheaper fix is to stop it building. A mover ticket should be structurally incapable of only adding access. When a transfer is logged, the workflow needs to read the prior role, compute the delta against the new one, and put the revoke lines in the same ticket as the grant lines so both get worked and both leave an audit trail. The transfer is not done when the new access is live. It is done when the old access is gone.

OpsDesk treats the mover as a first-class lifecycle event, not a request type that only grows access. When an identity changes role inside a workspace, the transfer generates both the grant and the matching revoke, runs the resulting standing access against your segregation-of-duties rules, and leaves the director an audit trail showing what was removed, not just what was added. See how the lifecycle workflow closes the mover gap before the next access review has to find it.