Privilege Creep

Access is granted when someone needs it and almost never removed when they stop needing it. The asymmetry is structural: granting has an obvious requester and an obvious benefit; revoking has no requester, an unclear benefit, and a real risk of breaking someone's work.

Over years, a person who has moved through several roles holds the union of all of them. Nobody decided that; it is the accumulated result of many individually reasonable decisions.

Why it matters

It is the mechanism by which the actual access model diverges from the designed one. Least privilege becomes aspirational, and the blast radius of a compromised account is set by tenure rather than by role.

It also makes the whole permission model unauditable: with enough accumulated exceptions, "what can this person do" becomes unanswerable, and unanswerable models cannot be improved.

Implementation patterns

• Recalculate on role change, do not add. The mover case in joiner-mover-leaver is the one almost every organisation gets wrong, and it is where the accumulation happens. Access should be derived from the new role, not appended to the old set.
• Usage-driven access review. Reviewing thousands of grants annually is a rubber-stamp exercise; reviewing unused access — not exercised in ninety days — is short, evidence-based and defensible. Usage data is what makes revocation politically possible.
• Time-bound grants by default, with renewal requiring a reason. Access granted for a project expires with the project rather than outliving it by years.
• Just-in-time elevation for privileged access, replacing standing administrative rights with a short-lived, audited grant. This removes the highest-risk permissions from the permanent set entirely.
• Attribute-based rules where the population is large, so access derives dynamically from department, region and employment type rather than from an accumulated role set.
• Effective-access visibility first. Before any remediation, build the ability to answer "what can this user do, and why" — every remediation without it is guesswork.

Industry example

Large enterprise platforms with rich permission models are where this compounds most visibly: thousands of roles and profiles, effective permissions derived from a union of profiles, roles, groups, sharing rules and record-level exceptions, and nobody able to state what a given user can actually do.

The remediation that works there is incremental and evidence-led rather than a redesign. A big-bang rebuild breaks access for people who need it, discovered by them being unable to work, and the organisational consequence is a permanent freeze on touching the permission model.

The sequence that works: make effective access computable, remove unused access with usage evidence, consolidate duplicate roles, and prevent new sprawl by making the request path produce narrow, time-bounded, correctly-named grants with an owner. If asking for access is easy only when it produces a new bespoke role, no amount of review keeps up.

Failure scenarios

• Leaver processes that work and mover processes that do not, which is the common configuration.
• Contractors and service accounts excluded from review, becoming the largest accumulation.
• Reviews that approve everything, because reviewers lack the information to say no.
• Emergency access granted during an incident and never revoked.
• Group membership as the accumulation vector, invisible to a review that looks only at direct grants.

Trade-offs

Aggressive revocation breaks work and generates friction, and the friction is borne by people who did nothing wrong. Time-bound access adds renewal overhead. Just-in-time elevation adds a step to privileged work, which is resented precisely by the people who do the most of it.

The mitigating design is to make re-granting fast and self-service, so the cost of over-revoking is minutes rather than days. Where re-granting is slow, revocation will be resisted and the accumulation continues.

Interview question

"An engineer has been with the company eight years and moved through four teams. Describe what access they probably have, why, and how you would fix it without stopping them working."