Why the Biggest Access Risk Isn’t Onboarding or Offboarding. It’s Everything In Between.

Most access control programs are built around two moments: the day someone joins, and the day someone leaves. Onboarding checklists provision the right access. Offboarding checklists revoke it. Both get real attention, because both are easy to define, easy to audit, and easy to point to when someone asks whether access control is being taken seriously.

The actual erosion of least privilege almost never happens at either of those moments. It happens in the years in between, one reasonable-sounding access request at a time, until nobody can fully account for why a given employee has the permissions they currently hold.

Prefer to read the full breakdown? Keep scrolling. Prefer to watch? Full video above.

How Ordinary Access Turns Into Excess Access

Picture a typical four-year run for an employee who is good at their job and never sets off a single red flag. They start in one department with a baseline set of permissions appropriate to the role. Eighteen months in, they get pulled onto a cross-functional project and are granted temporary access to a system outside their normal scope. The project wraps up. The access doesn’t get removed, because removing it was never anyone’s assigned job, and nothing broke because it stayed.

A year later, they move to a different team entirely, a lateral move, not a promotion or a termination, so no offboarding workflow ever triggers. Their old department’s access stays in place because nobody’s process was built to catch a transfer. Their new department adds fresh permissions on top. Somewhere in year three, they get folded into an audit response effort and receive short-term access to a reporting system “just for the audit.” The audit closes. The access doesn’t.

By year four, this is an employee with no disciplinary history, no suspicious behavior, and no reason anyone would flag them, who is quietly sitting on permissions that map to four different roles they’ve held, only one of which is current. If that account is ever compromised, an attacker doesn’t gain access to one job’s worth of systems. They gain access to four.

Why the Usual Safeguards Don’t Catch This

Most organizations believe this is already handled, because a formal control exists on paper: the periodic access review. In practice, this control frequently fails quietly. A manager receives a spreadsheet listing forty employees and their current permissions, is asked to certify that each one is still appropriate, and clicks approve on the entire list in under five minutes. The review happened. Nothing was actually evaluated.

This isn’t a story about a lazy or negligent manager. It’s a structural problem. Evaluating whether a specific permission is still necessary requires understanding what that permission actually grants and whether the employee’s current responsibilities still require it, knowledge a manager often doesn’t have and was never given time or training to develop. The control assumes a level of judgment it doesn’t equip anyone to exercise.

Two other gaps compound this. Temporary and project-based access almost never has a built-in expiration date, so removing it requires someone to remember, notice, and act, three separate failure points for something that should be automatic. And service accounts, credentials created to support an integration or automation rather than tied to an individual person, frequently outlive the human who originally set them up entirely, since nothing about an employee’s departure triggers a review of the automated processes they once configured.

What Actually Closes the Gap

Fixing the onboarding and offboarding moments is necessary but insufficient. The organizations that actually contain this risk build in three additional habits.

Access tied to a project or a temporary need gets a default expiration date at the moment it’s granted, not a manual step someone has to remember to perform later. If it’s still needed when the expiration hits, renewing it is a five-minute action. If it’s not, it disappears without anyone having to notice.

Lateral moves trigger the same kind of review that offboarding does. An employee changing teams should prompt an actual comparison between their old access and their new role’s requirements, not just an addition of new permissions on top of whatever they already had.

Access reviews get restructured around specific, answerable questions rather than a blanket approval. Instead of “does this list look fine,” the review asks “what does this person’s current role actually require, and does their current access match it.” That’s a meaningfully harder question to rubber-stamp.

The Uncomfortable Truth About This Kind of Risk

Nobody decided that the employee in this story should have four roles’ worth of access. No single approval was unreasonable in isolation. Every individual grant made sense given the context at the time it was requested. The risk accumulated entirely through the absence of a removal process, not through any one bad decision.

That’s precisely what makes it dangerous, and precisely why it stays invisible until an audit, an investigation, or a breach forces someone to finally ask the question nobody had been asking: does this access still make sense, and if not, how long has that been true.