There is a moment in almost every security program where someone confidently says, “We have a solid joiner, mover, leaver process.” It usually comes up in audits, board discussions, or when someone is explaining how identity is clearly under control. On paper, it looks great. New employees get access based on role. Transfers trigger updates. Departures result in access removal. Clean, structured, responsible. It feels like one of those foundational controls you can point to and say, we’ve got this part handled.

I’m not here to say that lacks in many organizations, and to be fair, many organizations do have a process. In my experience the problem is not the process, the problem is really everything that lives outside of it.

Because identity lifecycle management, in the real world, does not often behave like a neat flowchart. It behaves more like a group chat where half the people are talking, a few are responding late, and someone added a new participant without telling anyone.

This is where the joiner, mover, leaver process works beautifully… until it doesn’t.

Let’s start at the beginning of the process with joiners. New hires are usually well handled, because there is excitement, coordination, on-boarding checklists, and a general sense that everything needs to work on day one (or within the first few weeks). Access gets provisioned quickly, the accounts are created with permissions being assigned. In most organizations that I’ve seen, this is the most mature part of the lifecycle….Which is great, until you realize how much of that access is based on assumptions.

Role-based access sounds clean in theory, yet in practice, roles are often broad, outdated, or designed for convenience rather than precision (plus not zero trust friendly). New hires frequently receive more access than they need “just in case.”, to avoid any friction in their first days, it prevents delays and it keeps the on-boarding experience smooth…. but lets not talk about it quietly introducing risk on day one.

Now let’s talk about movers, and in my experience this is where things start to get interesting. Someone changes roles internally, Maybe it’s a promotion or lateral move or maybe they’re helping out another team temporarily. We all know that the expectation is that their access updates to reflect their new responsibilities. In reality, access rarely gets removed, unless it’s caught in a diligent manager doing access reviews.

Let’s be honest, most of the time it just accumulates.

The employee keeps what they had and gains what they need for the new role (maybe doing some work for their old role until the position gets back-filled..if ever) It feels efficient and avoids breaking anything. It supports flexibility and over time, it creates something far more powerful than intended.

The accidental superuser.

No one planned it, no one approved it as a strategy…it just happened over time, one role at a time.

If this sounds familiar outside of work, it should. It is the same pattern we see in streaming services. You sign up for one for one show, then you need another service for a different show and then another. At some point, you are paying for five platforms and only really watching two, but canceling feels like effort so it continues. I’ve seen to many ads for services to help you identity these services and cancel them.

Access behaves the same way, it is easier to keep the permissions than to remove.

Now let’s get to leavers, which is where most organizations feel confident again. Termination processes are usually well defined, accounts are disabled, badges are deactivated and VPN access is revoked. This is the part that gets the most attention, and rightly so from a security perspective.

Even here in this crucial process, gaps can exist. When we get outside of the normal termination process for employees, we can find issues because not all departures are clean. Contractors roll off without formal off-boarding or are controlled by a central team. Interns may finish programs but retain lingering access because someone forgot to mention to IT. Your third party accounts live outside traditional HR systems and may not have the best documentation are forgotten. Some shared accounts remain untouched because no one is quite sure who owns them. Service accounts continue operating because they are tied to systems, not people.

Those tend to be the “normal leavers” and then there are edge cases like the employee who transfers departments but remains in an old distribution group. The contractor whose access was extended “just for a few more weeks.” The project account that was never tied to an individual. The integration that still has active credentials long after the system it supported was retired.

I want to be clear these are not failures of intent, I’m just as guilty of some of these; they are failures of visibility. Identity lifecycle gaps rarely show up in clean process diagrams, as they exist in the gray areas, the in-between states or the “one time” exceptions. The things that do not fit neatly into joiner, mover, leaver.

And those are exactly the places attackers look (or stumble across). From an attacker’s perspective, identity is the easiest path forward. Why break in and trigger alerts…when you can just log in? Why exploit a vulnerability when valid credentials already exist? The more fragmented your identity lifecycle is, the more opportunities exist for access that no one is actively managing.

This is the part of my post where the conversation shifts from process to leadership. Most organizations treat identity lifecycle as an operational function. Something owned by IAM teams, supported by HR, and reviewed periodically. The impact is strategic, it affects risk posture, audit outcomes, incident response, and overall confidence in your environment.

You cannot claim strong access control if your identity lifecycle has gaps and closing those gaps is not just about tools (despite our hopes we can tool ourselves out of this problem)…like most things it is about mindset.

Leaders need to start asking different questions, not just “Do we have a joiner, mover, leaver process?” (or whatever you organization calls it) but “Where does it break down?”, not just “Are accounts disabled on termination?” but “What access persists outside that flow?”, not just “Who has access?” but “Why do they still have it?”. Because the most dangerous access is not the access you intentionally grant, it’s the access that no longer has a reason to exist.

This is where situational awareness intersects with identity, you need to understand not just identities, but how they evolve over time. What changes, what accumulates and what lingers. That requires visibility across systems, alignment between teams, and a willingness to challenge assumptions…and it also requires ownership.

Every identity, every entitlement, every integration should have a clear owner. Someone accountable for its existence and its lifecycle and understands that entitlement. Without ownership, access becomes orphaned, and orphaned access is one of the most consistent findings in both audits and incidents.

Another overlooked aspect is the human factor. People do not think in terms of entitlements and permissions. They think in terms of getting work done. If removing access creates friction, they will find ways around it. If requesting access is difficult, they will reuse what they already have. Identity programs that ignore this reality tend to create more shadow access, not less.

So the goal should not just be tighter control, but smarter control.

Make access easy to request and easy to expire, make temporary access truly temporary and make ownership visible. When it comes to your normal access review process make reviews meaningful instead of overwhelming and reduce complexity where possible. Translate technical access into business context, because if people do not understand what they are reviewing, they will default to approval.

all that and we are right back where we started.

The illusion of control.

Identity lifecycle gaps are not dramatic, they do not show up with flashing alerts or immediate impact…they build quietly, over time, across roles, systems, and processes…until one day, they are no longer gaps…they are pathways.

Controls are only as strong as their weakest exception….for all of the business functions but especially security. Whether we like it or not identity can full of exceptions. As leaders, we have to move beyond assuming the process works and start validating that it works in practice. That means testing edge cases, reviewing exceptions, challenging accumulated access and creating a culture where removing access is seen as responsible, not disruptive.

Because it is far easier to grant access again than to explain why it was never removed. So the next time someone says, “We have joiner, mover, leaver covered,” take a moment…then ask the follow up question…“What about everything that doesn’t fit into those three categories?” because that is where the real story lives.