Joiners, Movers and Leavers: Why Movers Break Your Permission Model

Every organisation has a joiners, movers and leavers process. Almost none of them run all three legs.

The joiner leg gets done well, because somebody is standing in reception on Monday morning unable to work, and that failure is loud, immediate and embarrassing. The leaver leg gets done adequately, because HR chases it, because there is a compliance driver, and because “ex-employee still had access” is the sort of finding that ends up in an audit report.

The mover leg is where it rots. Nobody chases it. Nothing breaks when it is skipped. And in any established organisation, movers are the majority of what actually happens.

Access is additive across a career

Think about someone with ten years’ service who has worked in six teams.

Every move added something. A new distribution list, a new set of SharePoint sites, a new security group, a shared mailbox, a line of business application, membership of a Team that turned into a site that turned into a document library nobody has opened since. Each grant was correct when it was made.

Now count what was taken away at each of those six transitions. In most organisations the honest answer is nothing, or near enough.

The reasons are mundane rather than negligent. Removing access creates risk of breaking something on day one in a new role, and the person doing the removing has no way to know what is still needed. There is usually a grace period, informally understood as “leave it for a bit”. The grace period has no end date because nobody set one. And critically, no single person owns the mover transition end to end. The joiner has a manager waiting for them and the leaver has HR behind them. The mover has a service desk ticket that says “add to the finance group”.

So the long-serving, well-connected, highly trusted employee ends up with the broadest access in the building. Not through any failure of policy, but through ten years of reasonable individual decisions and no counterweight.

Nobody has ever been taught to hand access back

Treating this as a technical hygiene problem misses most of what is actually going on. It is also a culture problem and an education one.

Think about how access is discussed in any organisation you have worked in. The conversation only ever runs in one direction. Someone needs something, so they ask for it. There is a form for that, a ticket queue for that, an approval chain for that, and a service desk metric measuring how fast it gets done.

Now try to remember the last time someone asked to have access taken away.

I have lost count of the times I have heard “I need the same access as Dave.” I have never once, in twenty years, heard “I have changed roles, can you take me off the HR folder.” Not because people are careless. Because nobody has ever suggested to them that it is a thing you would do.

There is no moment in anybody’s working life where handing access back is prompted, expected or rewarded. No form asks. No manager raises it in a one to one. No induction mentions it. The entire system is built to answer requests, and a request to remove access is not a request anyone has been taught to make.

The incentives run the same way. For the individual, giving up access is pure downside. Keeping it costs nothing, offends nobody, and might save raising a ticket in six months. For a manager, taking access away from someone creates friction and a conversation, while leaving it alone creates neither. Nobody has ever been criticised for access they failed to remove, because until something goes wrong there is nothing to see.

Cloning is how one bad grant becomes twenty

“The same access as Dave” deserves its own mention, because it does more damage than it looks like it does.

It is the fastest way to onboard someone and it is completely understandable. It is also how a single over-privileged account quietly becomes the template for a whole team. Nobody audits Dave before copying him. If Dave has picked up eleven years of accumulated access across four departments, the new starter inherits all of it on day one, and now there are two people with access nobody can justify. Do that a few more times and the original error has been laundered into a de facto standard, because everyone in the team has it and therefore it looks correct.

Access cloning does not just fail to fix sprawl. It industrialises it.

What would actually change it

The technical fixes above are necessary and they are not sufficient, because they all assume somebody initiates the removal.

What changes the culture is making handback normal and low cost. Access reviews help here for a reason that is not really about the review: they create a recurring moment where saying “I do not need this any more” is the expected answer rather than an admission. That reframing matters more than the tooling does.

The education piece is simpler still. People need to hear, once, that access is something you carry rather than something you own, and that carrying it has a cost to somebody even if it has no cost to you. Almost nobody has ever been told that. It is not in any induction I have seen.

Until that changes, every technical control you build is compensating for a system where the only verb anyone knows is “get”.

Why offboarding hygiene does not save you

Plenty of organisations have tightened up leavers considerably and believe they have therefore addressed access risk. They have addressed one part of it.

Disabling a leaver’s account stops that person using their access. It does nothing whatsoever about the state they left behind. The sites they created still exist. The sharing links they issued still work. The inheritance they broke on a library to solve a problem in 2021 is still broken. The external guest they invited to a project site is still a member of it.

Leaver processes remove people. They do not remove the sprawl those people generated, and the sprawl is the part that an agent will find.

What actually fixes the mover leg

The structural answer is to stop granting access to people and start granting it to roles.

Where access is attached to a role, and the role is attached to an attribute the HR system already maintains, a move changes the attribute and the access follows automatically. Removal stops being a decision somebody has to make and becomes a consequence of the data changing. That is the whole trick, and it is why identity governance work always ends up being a data quality project wearing a security hat.

Direct grants are the enemy here. Every time someone is added individually to a site, a group or a resource, you have created something that no attribute change will ever undo. Individual grants are fast and they are how the service desk clears a ticket in four minutes, which is exactly why they accumulate.

In the Microsoft world the relevant machinery is entitlement management for packaging access into things that can be requested, granted and expired, and access reviews for periodically making somebody confirm that access is still needed. Both are genuinely useful. Both are also licensed at a tier that a lot of organisations reading this will not have.

The version you can do without the licensing

If entitlement management is out of reach, the principle still holds and most of the value is available with discipline rather than product.

Grant through groups, always, even when a direct add would be quicker. A direct add saves four minutes today and costs you an unknown amount forever.

Make group membership derive from something authoritative where you can. Department, cost centre, job title, whatever your HR system actually maintains accurately, which is a shorter list than people assume.

Give project access an expiry from the day it is created. Not a review date, an expiry. The distinction matters, because a review date arrives and gets deferred, whereas an expiry arrives and forces a conversation.

Put the mover transition on somebody’s job description. It does not have to be automated to be owned, and unowned automation fails just as quietly as unowned process.

Run the data access governance reports on a schedule and actually read them. They are free with the tenant and they will tell you which sites are overshared without you buying anything.

Learning this without an enterprise tenant

You can build this whole model at home, and doing so teaches the concept far better than reading about access reviews will.

Stand up self-hosted identity. Create groups that represent roles rather than people. Attach access to the groups. Then move a test user from one group to another and watch carefully what happens to their old access.

The lesson lands hard, because unless you deliberately built removal into the model, nothing gets taken away. You will have moved someone and left everything behind, on a system small enough that you can see every permission at once. That is exactly the enterprise failure, at a scale where it is visible.

The same thing works at the operating system level if you would rather stay on the command line. Linux groups do this beautifully: add a user to a second group, then reason about what they can now reach and what would happen if you moved them again. File permissions and ownership are the same problem in a smaller box, and the mental model transfers directly to anything with an access control list.

This is the general pattern with a homelab, and it is why a homelab beats a course for this material: you cannot see an enterprise permission model in one screen, so nobody ever really understands it. You can see a homelab one, and once you understand the shape you recognise it at scale. A homelab teaches security basics the same way, by making consequences visible and cheap.

Why this matters more than it used to

None of this is new. Identity people have been saying it for twenty years, largely to rooms that were thinking about something else.

What changed is that the consequences used to be theoretical. A mover keeping old access was a finding on a report, not an incident, because nobody was ever going to go looking through the old team’s document library. That is no longer true. Agents index and retrieve rather than navigate, which turns every stale grant from a paper risk into something a colleague can stumble across by asking a question in plain English.

The permission model was always wrong. It just never had to be right before.

---

The rest of this series:

• Agent Access and the Permissions You Forgot You Granted
• Least Privilege in Practice: standing access, scope, and just-in-time
• The Permissions Work to Do Before You Deploy Copilot