Every Access Review Stalls on the Same Three Accounts

Somebody exports the list of administrators. It goes to managers. Managers approve their people. The spreadsheet comes back complete, gets filed as evidence, and the organization is measurably no safer than it was a fortnight earlier.

The reason is not that the process is wrong. It is that the accounts creating the actual exposure are the ones the process is worst at handling — the ones with no manager to ask, no clear owner, and a quiet consensus that removing them would break something.

There are usually three.

The service account nobody can trace

Every environment has at least one. It has administrative rights, it was created years ago for an integration, and the person who set it up has left.

It never appears in a manager-driven review because it does not belong to a person. Nobody attests to it, nobody removes it, and its password has not changed since the day it was made — often because nobody is confident what would stop working if it did.These accounts tend to be the most over-permissioned things in the environment. They were granted broad rights during setup to get the integration working, with a plan to tighten them later that never happened.

The way through is not deletion. It is discovery: what does it authenticate to, when did it last sign in, and what breaks if it stops? A service account that has not authenticated in ninety days is a different conversation from one that runs payroll. Both need an owner's name against them — a human being who would notice, not a distribution list.

Ownership is the deliverable here, even before any permission changes. An account with a named owner gets reviewed next cycle. An unowned one is invisible again in six months, which is why this belongs in ordinary security operations rather than in a once-a-year project.

The break-glass account nobody dares test

Most organizations have an emergency administrative account for the day normal access fails. Fewer have used it. Fewer still have used it recently enough to know it works.This one is genuinely awkward, because both failure modes are real. An untested emergency account may not function when everything else is down — the credential is stale, the MFA method is tied to a phone that was replaced, nobody remembers where the password is stored. But testing it is also the moment of highest risk, since the whole point is that it bypasses the usual controls.

The compromise most mature environments settle on: test it on a schedule, in daylight, with two people present and the attempt logged. Note who holds the credential and where. Confirm the second factor still resolves to something that exists.

An emergency account you have never used is not a control. It is a belief.

The vendor's access nobody scoped

The third is the one that generates the most uncomfortable meetings.

Outside parties hold privileged access in nearly every environment — the software vendor who needs to troubleshoot, the implementation partner from a project that ended, the provider who administers a platform. Some of it is necessary and current. Some of it dates to work that finished eighteen months ago.The questions are ordinary and rarely asked: which vendors currently hold administrative access, is it standing or requested per incident, is it individually attributable or a shared login, is it logged in a way you could review after an incident, and does the contract say what happens to it when the engagement ends.

Shared vendor logins are the specific problem. When five engineers at a supplier use one account, an audit trail tells you the supplier did something, which is not the same as knowing who — and it is exactly the detail that matters afterward.

This extends further than people expect. Backup platforms are administered systems too, and access to them is access to your recovery path. Whoever manages backup and recovery should appear in the privileged inventory alongside everyone else.

Why approval-by-manager produces so little

Underneath all three is a design flaw in how reviews are usually run.Asking a manager to confirm their reports still need access produces a predictable answer. The manager does not know what the permission grants, has no incentive to remove it, and faces a real cost if they revoke something and their person cannot work on Monday. Approval is the safe default, so approval is what comes back.

Two changes make the same exercise informative. Show last-use data next to each entitlement — an account that has not exercised its administrative rights in six months answers the question far better than its manager can. And make the reviewer justify retention rather than tick a box: one line on why this access is still required for current duties. It takes slightly longer and produces something worth reading.

The other structural fix is separating daily identities from administrative ones. When the same account reads email and administers the tenant, every phishing message is an attempt on your most privileged credential. Separation makes reviews cleaner too, because administrative accounts become a small, legible population instead of a property hidden inside everyday ones.

What finishing actually looks likeA review is done when the exceptions have owners and dates — not when the spreadsheet is full.

Unanswered questions are the output, not a failure. The service account nobody could explain, the vendor login nobody could attribute, the emergency credential nobody had tested: each becomes an item with a name and a deadline against it. That short list of unresolved things is worth more than the hundreds of approved rows above it.

Everything else is evidence collection. Useful for the auditor, and largely beside the point for the risk — which was never really in the accounts that were easy to approve. It was in the three nobody wanted to open.

Technijian works with Orange County and Southern California organizations on cybersecurity, identity and access, backup, and managed IT — including the unglamorous review work that decides whether a control is real. Talk to the team here.

Listen to the related Technijian podcast episode: