Privilege creep

what it is

Privilege creep is the pattern where an account accumulates permissions over time because new access is added and old access is not removed. It happens through role changes, project assignments, temporary grants, and ad-hoc requests.

The result is accounts that hold far broader access than their current role or function requires. The person behind the account may not use most of it, may not even be aware of it, but it exists and can be used.

Privilege creep is a systemic outcome of environments where the default is to add access and the process for removing it doesn't run consistently. No single bad access decision causes it.

why it accumulates

The mechanics are simple. Access is added in response to requests. A user needs something; they request it; it's granted. The request is the trigger. Removal has no equivalent trigger in most environments. There's no request submitted when a need expires.

Role changes are the most common source. When someone moves from one team to another, they receive the access their new role requires. The access from their prior role should be reviewed and largely removed. In practice, the new access is added and the old access stays. Nobody owns the review step.

Temporary grants are another. A user needs elevated access for a specific task or project. It's given on the understanding it's temporary. The project ends; the access doesn't. There was no mechanism to set an expiry and no process to check when the need was gone.

Over a multi-year employment history, each of these layers compounds. An account can end up with permissions from three prior roles, two temporary projects, and several one-off requests that nobody has revisited.

what it costs you

The security implication of privilege creep is a wider blast radius if that account is compromised. Verizon's DBIR 2026 notes the use of stolen credentials was a factor in 36% of breaches. When the compromised account holds more than its current role requires, the attacker inherits all of it.

There's also an insider risk dimension. An employee who no longer has a legitimate reason to access a system can still reach it. That may be harmless most of the time. It's not always.

The compliance implication is that least privilege is a documented expectation in most security frameworks. SOC 2, ISO 27001, and DORA all address the principle. An environment with systematic privilege creep can't demonstrate it's being applied. Access reviews are the mechanism for surfacing and correcting it, but reviews are only effective if the data they work from is accurate and complete.

what works

The measurement that exposes creep is a comparison between what each account holds and what its current role requires, which presumes two artifacts: a current access export and a documented set of role definitions. Where the second doesn't exist, writing it is the real first step, because without role definitions every permission looks defensible.

Probability concentrates the work. People who have moved between teams or roles several times are the likeliest carriers of accumulated permissions, so they head the review queue. Function mismatches are the other strong signal: a marketing user with access to the engineering CI/CD system, an operations user holding admin rights in a finance tool. Access to systems outside the user's current function rarely survives an honest look.

Usage data settles the borderline cases. A permission unused for a defined period, typically 90 days, is a removal candidate regardless of whether it seems role-appropriate, on the simple logic that access nobody exercises carries risk and delivers nothing in return.

The durable fix sits in the JML process. Environments that stay lean treat the mover step as a real event: a role change triggers a review of the old role's permissions, and the unnecessary ones come off at the same moment the new ones go on. Periodic access reviews then catch whatever the mover step misses, instead of carrying the entire load alone.