promoted three times. access revoked zero times

Sarah was hired as a junior product manager in 2021. She shipped well, got promoted to senior in 2023, to group manager in 2024, to director in 2025.

With each promotion, she got new access. A few new Jira projects. The Looker dashboards her new scope required. Confluence spaces for teams she now owned. A seat on the finance planning tool after she took over roadmap. A Salesforce login when she joined the quarterly revenue sync. A production-adjacent GitHub org because she was helping a deployment during an incident in April 2024 and someone said “give her admin so we can finish this, we’ll revoke it on Monday.”

Nobody revoked it on Monday.

By 2026, Sarah has access to things she forgot she had access to. She has admin on a tool her old team retired eighteen months ago. She’s still listed as an owner on a SharePoint site for a project that died in its pilot. She has production read on a service she hasn’t thought about since the reorg. Her access badge, if it were a physical object, would be a keyring too heavy to carry.

Sarah, by every conventional measure, is one of the best people at the company. She’s loyal, effective, trusted. She will never exfiltrate anything, never misuse what she has, never do anything that would show up in a security review.

She is also the thing the industry systematically ignores: a long-tenured, high-performing employee whose access has quietly expanded for five straight years, across four systems of record, through three reorgs, and not once has anyone run the reverse operation.

This essay is about that quieter problem. The one that doesn’t show up in the statistics about leavers. The one that lives in your top performers and your tenured engineers and your directors who’ve been there long enough to have forgotten what they used to have access to.

It’s about the people who stay.

the industry optimizes for leavers

If you’ve read anything about identity security in the last three years, you’ve read about former employees. Surveys of departed employees who still have access got turned into conference talks, vendor landing pages and a dozen LinkedIn posts about ghost accounts. The problem is real and it is bad.

It is also the easier problem.

Leavers are a bounded event. Someone leaves on Friday. You know they left. HR has a record. There is a named person to offboard. The question is only: did you find every system they had access to and did you actually remove them from each one? The math is ugly, the average mid-market company has somewhere between forty and two hundred SaaS apps, most of which don’t flow through SSO, but the question is well-formed. You can measure whether you got it right. You can put a number on how many systems you missed.

Stayers are an unbounded problem. Sarah got promoted instead of leaving, which triggered nothing, because no workflow in the company watches for that case. Her previous role dissolved into her new role. The access from the previous role dissolved into the access of the new role. Nobody noticed, because on paper nothing was removed, and what wasn’t removed was never “owned” by anyone in particular to begin with.

The entire apparatus of identity security, the vendors, the runbooks, the checklists, the compliance frameworks, is built around the moment of departure. SCIM deprovisioning. Offboarding SOPs. Access reviews that compare today’s list against last month’s. Every one of these controls assumes that removal is triggered by a named event. An employee leaves. A contract ends. A vendor is sunset.

What happens when nothing ends, and access just keeps accreting? The answer, in practice, is: nothing. The access accretes. The controls are silent, because their trigger condition was never met.

This is survivorship bias, applied to access management. The industry counts the people who left while ignoring the growth of what the people who stayed accumulated along the way.

how a stayer's access adds up

1. 1hiredThe day-one bundle for the first role.
2. 2promotedNew access for the new job. The old access stays.
3. 3"two weeks of admin"Granted for an incident, never removed.
4. 4promoted againAnother layer on top.
5. 5todayOne login holds every job this person has had.

RBAC was supposed to fix this. it doesn’t.

Role-based access control is one of the most successful ideas in enterprise security, and one of the most consistently betrayed by reality.

The theory is clean. A role is a named bundle of permissions. An employee is assigned one or more roles. The role, not the person, owns the permissions. When the person’s role changes, you change their role assignment, and the permissions change automatically. When someone new joins, you assign the role, and they inherit the permissions. When someone leaves, you de-assign the role, and the permissions vanish.

In a clean environment, this works. Small companies, new deployments, tightly scoped systems, you can run RBAC as designed for a while. It’s elegant. It’s auditable. It’s what every IAM vendor’s marketing diagram depicts.

Then something happens in month nine. A director asks if Sarah can have read access to the finance dashboard for a quarter-end review. The admin has two choices: create a new role, add Sarah to it, schedule its removal, or just add Sarah directly to the dashboard. The direct grant closes the ticket in eleven seconds. The role creation would take forty minutes. The admin picks eleven seconds, every time.

Month eighteen, the VP of engineering wants the platform team to have limited production access during incidents, but only incidents, not normal operations. The team argues about how to model this. They end up making a new group called platform-incident-responders, which initially has five members and six months later has thirty-eight members, including two people who left the platform team, one contractor whose engagement ended, and a product manager who was on-call one weekend in 2024.

By year three, RBAC has decayed into what it always becomes in practice: PBAC. Person-based access control. The role model still exists on paper, but most people’s actual access is a combination of their official role, seven ad-hoc grants, two legacy group memberships from reorgs past, and a direct assignment someone made during an incident that nobody remembers the context for.

Nobody decides this happens. It happens the way any system drifts, through the accumulation of individually reasonable exceptions, each of which costs nothing at the moment it’s granted and costs everything collectively five years later.

The diagnostic test: pick one long-tenured employee. Look at every group they’re a member of. For each group, ask “why is this person in this group?” and “who decided that?” If you can answer both questions for more than half the groups, you’re doing better than most companies. If you can answer them for all of them, I don’t believe you.

the two-week admin that became a two-year admin

There’s a specific failure mode that accounts for more of the access creep problem than any other: the temporary grant that was never rolled back.

It sounds like this. Sarah needs elevated access to finish an urgent thing. The urgent thing has a deadline. The admin says: “I’ll give you admin for two weeks, revoke it after.” Everyone nods. The grant is made. The deadline passes. The urgent thing ships. Two weeks later, nothing happens, because “revoke after” lived in the admin’s head, not in a system.

A tiny fraction of companies have a formal process for time-bound access. Most don’t. The ones that do mostly bolt it onto Active Directory group memberships with expiration dates, which works for exactly the systems that are integrated with Active Directory, which is not most systems.

Time-bound grants need to be the default. Every privilege elevation should expire unless explicitly renewed. Every temporary group membership should have a calendar-aware removal. Every “give me admin so I can finish this” should write a ticket that closes itself.

Almost nobody does this. And so every urgent moment, every incident, every deadline, every “just for this project” becomes a permanent grant. The archaeological layers of your company’s access model are mostly these grants, each one reasonable in its moment, none of them walked back, all of them still in force.

The specific operational cost of this shows up in incident postmortems. Somebody asks “who had access to this system at the time of the incident?” and the answer is a list of thirty people, only six of whom should have had it, twenty-four of whom had it because of some past elevated grant that was never revoked, and three of whom had it because they were still members of a group that stopped doing the thing that group was originally for. This is access archaeology. It is always a bad sign.

the insider threat baseline is not about bad people

Most writing about insider threat assumes the threat is intent. A disgruntled employee. A bribed contractor. A spy. These exist, and they are real, but they are the exceptional case.

The baseline insider risk is surface area, how much damage one compromised account, through phishing or credential reuse or session token theft, can do in your environment, given everything that account can reach.

Sarah’s account is fine in steady state. Sarah is fine. But Sarah’s account, if it gets compromised through a phishing link she opens at 11 pm on a Tuesday, is whatever the five-year accumulation of her access is. The attacker inherits every permission she’s ever been granted, across every system her identity is still valid in, which is almost always more than the role she holds today.

This is the part the industry has historically under-counted. When Verizon’s 2025 Data Breach Investigations Report puts credential abuse at 22% of breaches as the initial access vector, that’s a statement about initial access. The interesting question is the blast radius once that initial access exists. The answer is: whatever the oldest active account with the most accumulated access has. Which is almost never the account of a recent hire. It is almost always the account of a long-tenured employee whose access has been quietly growing.

You cannot harden against phishing. You can only reduce the consequence of phishing. That reduction lives entirely in access minimization, a continuous practice, run against the natural drift of the system back toward accumulation.

Every company that has been breached in the last decade has had this conversation in the postmortem. None of them was surprised, at that point, by what the compromised account could reach. They had always known, in some sense. They had just not done the reduction.

reviews don’t work. drills do.

Most companies attempt to address this with access reviews. Some do them quarterly. Some do them annually. Almost all of them do them because SOC 2 or ISO 27001 requires it.

Access reviews have a specific failure mode. A manager is presented with a list of their direct reports and, for each report, a list of systems that person has access to. The manager is asked to approve or deny each line. The manager, who has twenty reports and one hour, approves everything. There is no tool or UI that can overcome the fact that the manager does not actually know what each system does, cannot evaluate whether the access is still required, and has no incentive to deny anything because denying means friction with a report.

The review rubber-stamps the existing state. The existing state includes every accumulated grant from the last five years. The review, as performed, entrenches the problem it was designed to solve.

A reduction drill is a different thing. It inverts the default.

The drill: pick a random sample, five people, once a quarter. For those five people, suspend all non-essential access for forty-eight hours. “Non-essential” is defined narrowly and in advance: core email, core chat, the one or two systems their current job description explicitly names. Everything else goes dark temporarily.

Then you watch what happens. In most cases, nothing happens, because most of the access the person had accumulated was genuinely unneeded. In some cases, the person complains that they can’t do their job, and the conversation becomes: “what specifically do you need, and why?” In those cases, you restore the needed access, document the reason, and now you have a justified grant instead of an archaeological one.

The value of the drill is that the default is inverted. Access is assumed unnecessary unless proven necessary, which is the opposite of the default that produced the accumulation problem in the first place. Running the drill quarterly is the only known mechanism that actually reduces long-tenure access creep over time.

This is uncomfortable. It requires buy-in from leadership, tolerance for temporary friction, and willingness to be occasionally wrong about what someone needs. No vendor sells it, because it’s a practice rather than a product. The companies that run it quarterly have, without exception, better access hygiene than the ones that don’t.

reviews and drills test different things

access reviews

a manager clicks approve

• Long lists, little context
• Approving is faster than investigating
• Measures that a review happened

drills

remove it and see

• Take away access the role shouldn't need
• Watch what the person asks back for
• Measures what the job requires

the longest-tenured person in your company

Here’s the test, the one I’d actually ask you to run after reading this.

Find the person on your engineering or operations team who’s been at the company the longest. Three years, five years, eight years, whatever the top of your tenure distribution looks like.

Ask for a report of every group, every role assignment, every direct permission grant, every service account that person owns, across every system you can pull from. SSO is only a starting point, include the repositories, the cloud consoles, the observability tools, the internal admin panels, the legacy systems nobody logs into anymore but that still exist.

Look at the list. Ask, for each line, whether the current version of their job requires it. Not whether they need it. Not whether removing it would annoy them. Whether their current job, as defined today, strictly requires it.

The gap between what they have and what they need is your access creep surface. It will be larger than you expect. It will be larger than they expect. It will be larger than anyone would have planned, because nobody planned it. It accreted.

That gap is what the leaver statistics point to without being able to say directly. Leavers are just the subset of people whose access creep finally gets measured, because their departure forces the measurement. Stayers are the rest, the silent majority of the problem, and their access creep never gets measured, because nothing ever forces the question.

Force the question.

Do it on your longest-tenured person first. Then the second longest. Then the third. Keep going until the gap stops being embarrassing.

That’s the work.