Guide
What access creep is, and how to stop it
Also called privilege creep, entitlement creep, permission creep or privilege sprawl. Same problem, different vocabularies.
Every IT team has read the same ticket hundreds of times. It is the clearest symptom of a problem that compounds quietly for years.
Access creep is the gradual accumulation of permissions a person holds beyond what their current job needs. It happens because access is granted for a reason that ends, and removed for a reason that never arrives.
Nobody decides to over-permission a colleague. It is the sum of many individually reasonable decisions, none of which included an end date.
The same problem has five names
Which one you meet depends on whose documentation you read first, and none of them describes a different phenomenon:
- Privilege creep — the most widely used term, and the one most security vendors and glossaries lead with.
- Access creep — the same thing from the identity and joiner-mover-leaver side, where the unit being accumulated is access to a system rather than a privilege within one.
- Entitlement creep — common in identity governance, where an entitlement is the formal object being reviewed and certified.
- Permission creep — usually about application and file permissions specifically.
- Privilege sprawl or entitlement sprawl — the same accumulation described across a population rather than one person.
Some writers also use role creep, which is narrower: it means someone's responsibilities expanding, with the permissions following. That is a cause of the problem below rather than another name for it.
The distinction worth keeping is not between these words. It is between the accumulation itself and the thing that permits it: standing privilege — access that stays live whether or not it is in use. Creep is what standing privilege does over time.
The ticket that never stops arriving
The most recognisable symptom is a request that names a person instead of a permission:
“Hi, I just joined the payments project. Can you give me the same access as Dana? Thanks!”
This ticket is not written by a lazy requester. It is written by someone who has no way to describe what they need, because access is modeled as a pile of group memberships nobody can state in a sentence. Pointing at a colleague who can already do the job is the only accurate request they are able to make.
What makes this ticket expensive is not the work of fulfilling it. It is that fulfilling it correctly is impossible, and the failure is invisible:
- The request has no correct answer. Dana's memberships are a record of every project Dana has touched, not a description of the payments project. Copying them is over-granting by construction — and copying a subset requires knowing which subset, which is the thing nobody can determine.
- The engineer fulfilling it has no way to check. Group names rarely say what they grant. Working out what a membership actually permits means reading the far-end system's policy, which is a research task nobody has time for on a routine ticket.
- Over-granting produces no signal. If the requester gets too much, the ticket closes successfully and everyone moves on. If they get too little they come back within the hour. The feedback loop only pushes one way, and it pushes toward more.
- The template degrades. Dana was granted the same way, from someone else, years ago. Every round copies the previous round's excess forward and adds to it.
That last point is the one that turns a tidiness problem into a compounding one. The error is not just repeated — it is inherited, and it grows each time it is passed on. A team that has run this process for five years is not five years of tickets deep. It is five years of accumulated tickets deep, with each generation starting from the previous one's high-water mark.
The short version of this story is on our homepage, next to what the product does about it.
Why it is a security problem and not just an untidy one
Standing permissions are permissions that are live whether or not anyone is using them. An entitlement granted for a two-week migration and never removed is available to anything that can authenticate as that person — for the rest of their time at the company. That includes:
- A compromised account. An attacker gets everything the account has accumulated, not the subset it currently needs.
- An honest mistake. Someone with production write access they forgot they had is one command away from using it.
- Automation and agents. CI jobs, MCP servers and coding agents authenticate as a person and inherit every group that person belongs to.
The exposure is best measured in time. A standing group membership is live 8,760 hours a year. A grant that expires after four hours is live for four. Nothing about the permission changed — only how long it existed.
Why access reviews do not fix it
The usual answer is a periodic access review — also called access certification, or user access review: export the entitlements, send them to managers, ask them to confirm. Reviews are worth running, and they are also the reason access creep survives in organizations that run them diligently. Three reasons:
| What reviews assume | What actually happens |
|---|---|
| A reviewer can tell whether an entitlement is still needed | The entitlement is a group name with no description, granted by someone who has left. The safe answer is to approve it. |
| Reviewing quarterly is often enough | The two-week project's access is over-granted for the eleven and a half weeks between reviews, every quarter. |
| Removing access is low-risk | Revoking something in use breaks a colleague's day, so reviewers err toward keeping it. Over-approval has no visible cost; over-removal does. |
A review is a periodic correction applied to a process that produces the error continuously. It can reduce the backlog. It cannot stop the accumulation, because it does not change the moment where the accumulation happens — the grant with no end.
What actually stops it
Access creep ends when expiry is part of the grant rather than a separate task. The change is small to state and structural in effect: instead of granting access and filing a reminder to remove it, grant access that removes itself. The usual names for this are just-in-time access (JIT), time-bound access and zero standing privilege — and unlike the five names above, these genuinely are different ideas: JIT is about when access is granted, time-bound is about when it ends, and zero standing privilege is the state you are left in once both hold.
All three are ways of enforcing least privilege over time rather than only at the moment of granting, which is the part conventional least-privilege policy tends to leave out.
If a person leaves the company, goes on leave, or simply stops working on the project, does their access end without anyone doing anything? If the answer depends on somebody remembering, the approach does not stop access creep — it schedules it.
In practice that means four things:
1. Name the access, so nobody has to point at a person
Bundle the groups a task actually needs into something with a name and a description — "deploy to payments staging", not four group ids. Once the thing is nameable, the ticket that names a colleague stops being the only accurate request someone can write.
2. Make it self-service, with approval where it matters
Most access requests are high-volume, low-judgment work whose only real decision is which groups to copy. Where a human decision genuinely is needed, route it to someone who can make it — and where it is not, stop pretending a queue adds safety.
3. Give every grant an expiry at the moment it is created
This is the load-bearing one. A grant with a window is self-correcting: over-granting costs hours instead of years, and nobody has to notice the mistake for it to be fixed.
4. Make removal as reliable as granting
Every system that can add a member has to be able to remove one, and the removal has to be as monitored as the grant. A product that grants reliably and revokes unreliably has simply moved where the creep comes from.
What this looks like day to day
The ticket above stops being a ticket. Someone joining the payments project sees the same named packages their colleagues can request, asks for the one they need, and gets it — with an approval step if the package requires one. The access ends on its own, and joining a second project is not another archaeology exercise.
The person who was being copied stops being a walking template for everyone else's permissions, which is how the compounding stops.
Time-bound access does not remove the need to decide who should have what. It removes the need to remember to undo it. Deciding is the part worth a human; remembering is the part that always eventually fails, and it is the part that produced the creep.
How TemprBac approaches it
TemprBac grants access as time-bound packages: a named bundle of groups across the systems you already run — Entra ID, Okta, Google Workspace, GitHub, AWS IAM and Active Directory — requested by the person who needs it, approved if the package requires it, provisioned into your directory, and revoked automatically when the window closes. The removal is recorded alongside the grant, so "who had access to what, and when" is a query rather than an investigation.
One rule shapes the whole product: nothing may block revocation. No plan limit, no quota, no billing state stops access from expiring. A cap that could stop revocation would convert every temporary grant into a permanent one, which is the exact problem this page is about. Pricing covers what the limits do affect, and single sign-on is included on every tier.