in one linePrivilege creep is the gradual accumulation of permissions that were never revoked when the reason for them ended.
the numbers
- 82:1machine identities per human one, nearly half privilegedCyberArk Identity Security Landscape, 2025
- 62%of breaches involved the human elementVerizon DBIR, 2026
- 36%of breaches involved stolen credentialsVerizon DBIR, 2026
1what 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.
2why 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.
3what 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 it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedCash App / Block, 2022howThe person logs back in from home, weeks after leaving.what leavescustomer lists and reportswho ends up with itthe former employee and whoever they work for next
- it happenedColonial Pipeline, 2021howThe forgotten account's password turns up in a breach dump.what leavesa working way into the networkwho ends up with ita ransomware crew
- it happenedCloudflare, 2023howA key or token set up for old work keeps working after everyone forgets it.what leavesinternal systems and documentswho ends up with itwhoever tries the key first
4what 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.
on the record
your turn
what you can do about it
this week
Pick three people who changed roles this year and compare their access with their new job.
Remove what the new role does not need.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →