Nobody removes the prior access when the justification changes. After three years, the user has access that reflects every role they have held, every project they have touched, and every system they have been temporarily granted access to — not their current role and not what they actually need. Technology did not cause this. Process did.
The Mechanics of Accumulation
Access rights in most enterprise environments are additive. When a user is assigned to a new role, they receive the access that role requires. When they move to another role, they receive that role's access. The prior access is removed only if a specific revocation step occurs. That revocation step requires that someone knows the prior access was granted, that the prior role is no longer appropriate, and that removing access is worth the friction it creates with a user who may still occasionally need the prior access for historical context or transitional responsibilities.
In practice, those conditions are rarely all met simultaneously. The provisioning system that adds access is often automated. The revocation that should accompany role changes often depends on manual steps in an HR-driven offboarding or role-change process that may not capture every access grant made outside the formal provisioning workflow. Access granted for project purposes — temporary elevation, guest access to a shared workspace, read access to a system for a specific deliverable — is frequently not removed when the project ends because there is no trigger in the process that links access grants to project timelines.
The provisioning half of the joiner-mover-leaver process runs automatically. The revocation half depends on humans completing process steps at the right time with the right information. The asymmetry is where privilege creep lives.
Why Access Reviews Do Not Solve It
Access reviews ask managers to confirm whether their direct reports' access is appropriate. The review is only as good as the manager's knowledge of what access the user has and what they actually need. Managers who are not security practitioners typically do not know the full scope of access their reports hold. They know the access relevant to the user's current role. They may not know about access grants from prior roles, project-based access grants, or access granted by other managers or system owners.
The access review that asks a manager to confirm whether 'all access listed below is appropriate for this user's current role' against a list of hundreds of access grants is an access review that is difficult to complete meaningfully. The rational response to an overwhelming list under time pressure is to confirm the access and move on. The review completes. The privilege creep persists.
The Process Fixes That Work
Access Grants Tied to Justification Expiry
Every access grant should have an associated justification and an expiry condition. Role-based access expires when the role changes. Project access expires when the project concludes. Temporary elevated access expires on a defined date. Access that has no expiry condition should be the exception rather than the rule, and that exception should require explicit justification. When access grants carry expiry conditions, revocation becomes a scheduled automated event rather than a manual step that depends on humans remembering to act.
Role Changes That Trigger Access Reconciliation
When a user changes roles, a reconciliation process should determine what access the new role requires, what access the prior role required that is no longer needed, and what access should be removed as part of the transition. This is different from the standard joiner-mover-leaver process, which typically provisions the new access without formally revoking the prior access. Role change access reconciliation requires that the transition is treated as a provisioning event for the new role and a deprovisioning event for the prior role simultaneously.
Exception Access That Is Visible and Time-Bounded
Access granted outside normal provisioning channels — for emergencies, for temporary projects, for troubleshooting — should be tracked as an exception with a defined duration and a designated owner responsible for revocation. Exception access that is not tracked is access that will not be removed when it is no longer needed. The exception management process does not need to be complex. It needs to capture what was granted, when, why, and when it should expire.
Access Reviews Designed for Meaningful Review
Access reviews that present managers with annotated access lists — showing when each access was granted, under what justification, from which role, and whether it is consistent with the user's current role — produce more meaningful reviews than access reviews that present raw access lists. The annotation requires work from the identity governance team. It produces reviews from managers who have the context to make informed decisions rather than reviews that confirm existence rather than appropriateness.
The Organizational Discipline Required
Addressing privilege creep requires organizational discipline that does not exist naturally in most environments. The people who grant access are not the people who remove it. The people who remove it need information they may not have. The people who have the information are not always required to provide it at the right time. Building the process that connects these dependencies requires explicit governance design, not better technology.
The technology exists to support every process fix described above. Expiry conditions on access grants, automated role-change triggers, exception tracking workflows — these are capabilities in modern IAM platforms. The reason they are not universally implemented is not technical limitation. It is that implementing them requires process design decisions, organizational coordination, and acceptance of additional friction in access management workflows. Those are governance decisions, not technology decisions.
Fix the process. The technology will follow. Privilege creep is a governance problem that governance must solve.
Audit the access your longest-tenured users actually have against what their current role actually requires. The gap is the privilege creep. The process that produced it is the governance investment priority.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.