The joiner-mover-leaver (JML) process is the set of steps an organization follows to give a person the right access when they join, change that access when they move to a new role, and remove all of it when they leave. Joiners need the access their job requires on day one, movers need new access added and old access taken away, and leavers need every account disabled quickly and completely. Automating it usually means a single source of truth, typically the HR system or the company directory, that drives accounts in every application through a standard such as SCIM. Movers and leavers are where most problems show up, because they are the cases where something has to be removed, and removal is the step people forget.
This post explains each stage in plain terms, shows how teams automate it, and covers what it means if you build a SaaS product whose customers expect their own JML process to reach your application.
What do joiner, mover and leaver mean?
The three words describe the three moments in an employee’s time at a company when their access has to change.
- Joiner: a new employee, contractor or guest starts. They get the access that comes with their role from the first day, which is often called birthright access (email, chat, the company directory and the tools everyone in that team uses).
- Mover: an existing person changes role, team or location. Access for the new role is added, and access for the old role is removed.
- Leaver: the person leaves the company or the engagement ends. All their accounts are disabled or deleted, their sessions and tokens are ended, and anything they owned is handed to someone else.
The same process applies to contractors and external guests, with the added question of who is responsible for them, since they often have no HR record.
Why are movers the hardest part?
When people change roles, adding the new access is obvious and removing the old access is not. Nobody raises a ticket to take things away, so access accumulates, a pattern often called privilege creep. A person who has moved through three teams over four years may hold the combined access of all three, which breaks the principle of least privilege and is exactly what an auditor looks for in an access review. If you want the review side of this, see what a user access review is.
Why are leavers the audit finding?
A departed employee whose account still works is the clearest example of an access control failure, and it is easy for an auditor to find: they compare the list of leavers with the list of active accounts. Those leftover accounts are often called orphaned accounts. Frameworks ask for timely removal explicitly. SOC 2 includes criteria on removing access when it is no longer needed (the AICPA Trust Services Criteria under CC6.2 and CC6.3), and ISO/IEC 27001:2022 covers access rights in Annex A control 5.18 and responsibilities after termination or change of employment in control 6.5. You will usually be asked to show evidence, such as a ticket or log entry with a timestamp, and not merely to describe your policy.
What is the source of truth for the lifecycle?
Automation needs one place that decides who is in the company and in what role. In most organizations that is the HR system (HRIS) or, for smaller teams, the company directory. A hire, a role change or a termination recorded there starts the process, and nothing else is allowed to create or remove people independently.
The source of truth feeds the identity provider, and the identity provider carries the change to each application. Some platforms package this as ready-made joiner, mover and leaver workflows, such as Microsoft’s Lifecycle Workflows in Entra ID Governance, which schedules tasks like enabling and disabling accounts around HR dates. The protocol that carries it is usually SCIM (System for Cross-domain Identity Management), defined in RFC 7643 for the data model and RFC 7644 for the protocol. It gives applications a standard way to receive “create this user,” “update this user” and “deactivate this user” requests. For the background, see our posts on what SCIM is and user provisioning.
How do you automate joiners, movers and leavers?
A workable automated process has five parts, and you can build it up one at a time.
- HR to identity provider. A new hire, role change or termination in the HR system creates, updates or disables the matching account in the identity provider.
- Identity provider to applications through SCIM. The identity provider pushes those changes to every application that supports SCIM, so a disable in one place disables access everywhere. Where an application has no SCIM support, a connector or a manual checklist fills the gap, and that manual list is where leavers get missed.
- Role and group mapping. Access is assigned through roles or groups tied to job function, not person by person. When someone moves, changing their group changes their access, and the old group’s access goes with it. This is the practical fix for privilege creep, and role-based access control explains the model.
- Approval workflows for access beyond birthright. Access to sensitive systems goes through a request and approval step, with an expiry date where possible. We describe this in identity governance workflows for access requests.
- Periodic access reviews. A manager or system owner confirms on a schedule that each person still needs what they have. Reviews catch what the automation missed.
The difference between provisioning on a schedule and provisioning at first sign-in is worth knowing, because a SaaS product can do either. JIT provisioning compared with SCIM covers why JIT creates accounts but does not remove them, which matters for leavers. The broader question of how identity management and governance relate is covered in IAM compared with IGA.
What about guests and contractors?
External users are the group most likely to fall outside the process, since they rarely have an HR record. A good pattern is to give every guest a sponsor (an employee who is responsible for them), an expiry date set when the account is created, and a review that asks the sponsor to confirm or end the access. Governance products support this with features such as access reviews and access that expires on a set date. Whichever platform you use, the principle is the same: no external account should exist without an owner and an end date.
What do auditors ask about JML?
They ask for evidence that the process ran, not a description of it. Typical requests include the list of leavers in a period alongside the date each account was disabled, a sample of role changes showing that old access was removed, and the output of your most recent access review. Automation helps because every step leaves a log entry with a timestamp. A manual process works too, but it needs a ticket for every step, and gaps in the tickets become findings.
Decide on a target for how quickly leavers are removed and write it into your policy. Same business day is a common target, and stricter environments set shorter ones. The number matters less than choosing one you can meet and measure.
What does JML mean for a B2B SaaS product?
If you sell to companies, your customers run their own JML process, and they expect it to reach your application. A customer’s security team will ask whether a person disabled in their directory loses access to your product, and how fast. The two features that answer that question are SSO, so that disabling someone in their identity provider blocks new sign-ins, and SCIM, so that their account in your product is deactivated as well.
SSO alone does not close the gap. A person who is already signed in can keep a valid session until it expires, and anyone with a local password or an API key may still have access after they leave. That is why customers ask for SCIM and for session limits. Offering both is a common requirement in enterprise deals, as we explain in what to do when a prospect asks for SSO. If you run your login layer on Keycloak, our guide to using SCIM 2.0 with managed Keycloak shows the setup, and the SCIM feature page and user management page describe what is supported.
A JML checklist and sample timeline
Use this as a starting point and adjust the timings to your policy.
Joiner
- The HR record is created before the start date.
- The identity provider account is created and placed in the role’s groups.
- Birthright access arrives through SCIM or group assignment, and MFA enrollment happens on the first day.
Mover
- The HR system records the role change with an effective date.
- The new groups are added on that date and the old groups are removed on the same date, not at the next review.
- The manager confirms any extra access that should stay, with a reason and an end date.
Leaver
- Termination is recorded in the HR system.
- The identity provider account is disabled at the agreed time (for example, the same day) and sessions and tokens are revoked.
- SCIM deactivates the account in each connected application, and a short list covers any application that has no SCIM support.
- Files, projects and shared accounts are reassigned, and the evidence (timestamps and ticket) is stored for the audit.
Frequently asked questions
What is the difference between JML and onboarding and offboarding?
Onboarding and offboarding are broader HR processes that include equipment, payroll and training. JML is the access management part of those processes, and it adds the mover case, which neither onboarding nor offboarding covers.
Do small companies need an automated JML process?
A small team can run it with a checklist and a monthly review, and many do. Automation becomes worth the effort when the number of applications grows, when a customer or auditor starts asking for evidence, or when you notice that the checklist has been missed more than once.
Is SCIM required for JML?
No, but it is the standard way to automate the application side. Without it you need connectors that are specific to each application or a manual process, and manual removal is the step most often missed.
Where does JML fit with access reviews?
They are complements. JML handles each change when it happens, and access reviews check on a schedule that the result is still correct. Reviews find the cases JML missed, such as access granted outside the normal process.