The joiner-mover-leaver lifecycle: getting access right at every stage
Joiner-mover-leaver, or JML, is the path access takes through a person's time at a company. They join and get provisioned. They change roles and their access should change with them. They leave and it should all be removed.
Most teams are decent at the joiner step, because onboarding is visible and someone owns it: a new person cannot work without access, so it gets done. The mover and leaver steps are where it breaks, because nothing stops working when they are skipped. A role change that adds new access without removing the old one still lets the person do their job. A leaver whose apps stay open still looks fine from the inside. The failures are invisible until an audit, an incident, or a review surfaces them.
Treating JML as one lifecycle, rather than three separate tasks owned by different people, is what keeps access matching reality over time. It is the backbone of least privilege and the control every framework leans on.
- Access has a lifecycle: granted at the joiner step, changed at the mover step, removed at the leaver step. The three only work as one system.
- Most teams are decent at the joiner step because onboarding is visible and owned. The mover and leaver steps break because nothing stops working when they are skipped.
- The mover step is the engine of privilege creep: almost everyone adds the new role's access, almost nobody removes the old role's. Fix the mover first.
- Around 40% of departing employees keep access to at least one business application under manual offboarding, and 65% of manual offboarding processes miss shadow SaaS entirely (Reco, 2025-2026).
- Service accounts, API keys, and integrations have no joiner-mover-leaver process at all, and often hold the broadest access in the environment. Give each one an owner and review them on a cadence.
- JML works when it is a system: HR is the trigger, provisioning is automated where it can be via SSO and SCIM, the gaps are owned manually, and recurring access reviews catch what the process misses.
the joiner: provision to role, not to "everything the last hire got"
Good onboarding gives people what they need on day one without handing them more than their role requires. The common anti-pattern is cloning: a new hire is provisioned by copying a similar colleague's access. It is fast, and it is how privilege creep is seeded from the first day, because the colleague's access already includes years of accumulated extras.
What good looks like:
- Role-based access. Define what each role needs, and provision to the role rather than to a person's memory of the last setup. You do not need a perfect role model to start; even rough role templates beat cloning.
- A request and approval path with a record. Access is granted through something that leaves a trail, so you can later prove who approved what. This is the evidence auditors sample.
- Birthright versus requested. Separate the access everyone in a role gets automatically from the access that needs a specific request and justification. Keep the automatic set minimal.
the mover: the step that creates most of the mess
When someone changes role, two things should happen: they get the access the new role needs, and they lose the access the old role needed. Almost everyone does the first. Almost nobody does the second.
That single gap is the engine of privilege creep. Over a few moves, a person accumulates the union of every role they have held. The finance analyst who once covered procurement still has procurement access. The engineer who did a stint on-call still has production rights. None of it is malicious, and all of it is risk.
What good looks like:
- Role change triggers an access review, not just an access addition. The question is always "what should they no longer have," not only "what do they now need."
- The mover event is owned. Someone, usually with HR as the trigger, is responsible for the removal side, the same way someone owns the joiner.
- Sensitive transitions get extra scrutiny. Moves into or out of privileged roles, or between teams with different data access, deserve a closer look.
If you fix one thing in your whole JML process, fix the mover. It is the cheapest place to stop creep before it starts.
the leaver: close every door, not just the directory
When someone leaves, the directory account gets disabled reliably, because IT owns it. The failure is everything below it: the SaaS apps with direct logins, the OAuth grants, the API tokens, the shared-account passwords they knew, the service accounts they owned.
The headline numbers are stark: most former employees retain access to at least one company app after leaving, around 40% of departing employees keep access to at least one business application under manual offboarding, and 65% of manual offboarding processes miss shadow SaaS entirely (Reco, 2025-2026). The directory closes; the apps outside it stay open. The principle: offboarding has to cover every system the person could reach, not just the one IT controls directly. The full deprovisioning scope and sequence are a dedicated job in their own right, and the leaver step is kept short here because it is the largest of the three.
the non-human lifecycle nobody runs
Human JML at least has HR as a trigger. Service accounts, API keys, and integrations have no joiner-mover-leaver process at all. They are created when a project needs them and persist until someone notices. There is no leaver event when the service they served is decommissioned, and no review when a key has not been used in months.
Bring non-human identities into the lifecycle deliberately: give each one an owner, record why it exists, and review them on a cadence, because they often hold the broadest access in the environment and answer to no HR system.
making it repeatable
JML works when it is a system, not a set of good intentions:
- HR is the trigger. Joiner, mover, and leaver events should start from the system of record for people, so access changes when employment changes.
- Provisioning is automated where it can be. Connecting apps to your identity provider via single sign-on and SCIM means access follows the directory automatically, which shrinks the manual surface for all three stages.
- The gaps are owned manually. Apps outside single sign-on, and non-human identities, need a named owner and a checklist, because automation will not reach them.
- Reviews catch what the process misses. Recurring access reviews are the safety net for everything JML lets slip.
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there
+48 783 762 997
julian@unshadowit.com
