Nothing is more permanent than temporary access
There are few things in IT more durable than a supposedly temporary permission.
- Temporary admin rights.
- Temporary group membership.
- Temporary access to a shared mailbox.
- Temporary access to the finance folder.
- Temporary access to that legacy system nobody really wants to own.
All of these have one thing in common: they were granted for a reason that probably made sense at the time.
The problem is not that temporary access exists. Sometimes temporary access is entirely reasonable. Projects happen. Migrations happen. Cover arrangements happen. Urgent work happens. Real environments are not tidy enough to pretend otherwise.
The problem is that temporary often arrives with no expiry, no owner, no review point, and no real plan for removal.
At that point, it is not temporary access.
Why it matters
This is one of those issues that gets normalised because the pain arrives slowly.
Nobody usually notices the exact moment access governance stops reflecting reality. It just becomes a little less clear over time. A little messier. A little harder to explain. Until one day the organisation is carrying a permission model that feels more archaeological than intentional.
The risk shows up in four places.
1. The blast radius gets bigger
If a user has more access than they need, then any compromise of that account has a wider impact.
That could mean:
- access to more data than intended
- the ability to change more settings than appropriate
- broader visibility of systems and services
- more opportunities for accidental damage
This is why least privilege matters. Not because it is fashionable security language, but because it limits the size of the mess when something goes wrong.
2. Access reviews become awkward and unreliable
Once access has been accumulated over time, nobody is completely sure what correct looks like anymore.
At that point, reviewing access becomes an exercise in institutional folklore:
- “I think they still need that”
- “They used to help with that process”
- “I’m not sure what breaks if we remove it”
- “Let’s leave it for now”
And there it is again. The deadliest phrase in IT governance.
If you do not have a clear model of what access should look like by role, every review becomes slower, less confident, and more political than it should be.
3. Leavers and movers become more dangerous
Most organisations are better at onboarding access than removing it. That makes sense since New Starters are visible and they are expected. There is a date, a manager, and a request to go along with it.
Leavers and movers are trickier. People change teams, take on extra responsibilities, or move between systems in ways that are not always formally reflected.
If access is not reviewed properly when roles change, then privileges accumulate. That is where the phrase they’ve always had that access starts doing real damage.
4. Audit and assurance become painful
Nothing exposes weak access governance quite like someone asking simple questions.
- Who has administrative access?
- Why do they have it?
- When was it last reviewed?
- Which shared accounts still exist?
- Which supplier accounts are still active?
- How quickly is access removed when no longer needed?
In well-governed environments, these are manageable questions.
In access environments shaped mainly by history, they become awkward very quickly.
The signs you already have a problem
If any of these sound familiar, you are probably living with privilege creep already:
- temporary admin rights with no clear expiry
- old project groups still populated years later
- shared accounts nobody wants to admit still exist
- leavers disabled in one place but still active somewhere else
- supplier or contractor access with unclear ownership
- permissions nobody wants to remove because “something might break”
- access reviews that rely more on instinct than evidence
None of this is rare. In fact, it is so common that many teams stop noticing how odd it is.
This is the problem.
Why organisations tolerate this
Because access tidy-up is important, but rarely urgent.
There is always a more visible priority:
- the outage
- the project
- the migration
- the procurement issue
- the user problem that arrived five minutes ago marked “critical” for reasons no one fully understands
Access debt accumulates because it is quiet. It does not usually announce itself dramatically. It just increases risk in the background while everyone deals with more immediate fires.
Also, and this matters, many organisations are still operating without a fully mature identity model. If role-based access is weak, if onboarding/offboarding is inconsistent, or if systems are not well integrated, then permissions become manual by default. Manual processes drift. They always do.
What good looks like
Good access management is not about making everything difficult.
It is about making access deliberate.
That usually means:
Role-based access where possible
People should receive access based on what their role requires, not on an improvised accumulation of historical permissions.
Clear joiner / mover / leaver process
Access should be created, changed, and removed as part of a controlled lifecycle.
Time-bound elevated access
If someone needs admin rights temporarily, then “temporarily” should mean something. It should expire, or at the very least be reviewed.
Separate privileged access
Administrative access should not just be layered onto everyday user activity and forgotten about. It should be treated differently, because the risk is different.
Regular review
Not a ritual. A real review. One that asks whether access is still needed, still appropriate, and still owned.
How to fix it without causing chaos
This is not a case for ripping everything apart in one glorious act of access absolutism.
That is how you break a business and make yourself unpopular in three departments before lunch.
A better approach is:
1. Start with privileged access
Administrative access creates the greatest risk. Review that first.
- Who has it?
- Why do they have it?
- Do they still need it?
- Is it tied to a named person?
- Is it separated from normal activity?
2. Identify the “temporary” access that no longer has a reason
Projects end. Cover arrangements end. Migrations end. Access should end too, unless there is a real reason for it to continue.
3. Build role baselines
If you do not know what “normal” access looks like for a job role, you will always be tidying exceptions rather than managing access.
4. Tie review to real operational moments
Access review should happen when:
- someone joins
- someone moves roles
- someone leaves
- a project ends
- a system changes
- a supplier relationship changes
5. Be willing to ask the awkward question
What is this access actually for?
Chances are you’re asking the above question because your documentation is a mess.
A surprising amount of governance progress begins there.
Final thought
Temporary access is not the problem.
- Unowned access is the problem.
- Unreviewed access is the problem.
- Inherited access nobody understands is the problem.
Nothing is more permanent than temporary access because organisations are very good at granting permissions and much less enthusiastic about retiring them.
And over time, that gap becomes risk.
If your access model is mainly a collection of historical exceptions that nobody wants to challenge, then you do not really have access governance.
You have access sediment. This is my new buzzphrase, access sediment. Maybe John Bercow works in IT.