What is the Joiner-Mover-Leaver process?
JML is a way of thinking about identity management through the lens of employee lifecycle events. Every employee goes through at least two of these events (joining and leaving), and many go through all three multiple times during their tenure.
Joiner: A new employee, contractor, or vendor starts at the organization. They need accounts, access, and equipment to do their job.
Mover: An existing employee changes roles, transfers departments, gets promoted, or takes on a new project. Their access needs change, but they are not new and they are not leaving.
Leaver: Someone departs the organization. Their accounts need to be disabled, access revoked, and data preserved or transferred.
The JML framework gives IT and HR a structured way to handle each event consistently. Instead of treating every personnel change as a one-off IT ticket, you have defined processes and (ideally) automation for each scenario.
Why does JML matter?
Without a defined JML process, access management is reactive. IT waits for someone to submit a request, then figures out what to do. This leads to delays, inconsistencies, and gaps that accumulate over time.
With a defined JML process, new hires are productive on day one because their access is ready. Role changes are handled cleanly, with old access removed and new access granted. Departing employees lose access promptly, reducing security risk. And every lifecycle event creates an audit trail for compliance.
For compliance frameworks like SOC 2, ISO 27001, and NIS2, having a documented and consistent JML process is practically a requirement. Auditors want to see that you have defined procedures for granting, modifying, and revoking access — and that you actually follow them.
The Joiner process in detail
When someone joins your organization, several things need to happen in sequence.
Before day one, HR enters the new hire into the HR system with their start date, department, job title, manager, and location. The provisioning system creates the Entra ID account. Licenses are assigned based on the role. Group memberships are configured to grant the right application access, Teams memberships, and SharePoint permissions. Equipment is prepared.
On day one, the employee logs in and has access to everything they need. Welcome communications and onboarding materials are accessible. Manager introductions and training are scheduled.
In the first week, any access that requires additional approval (elevated permissions, sensitive systems) is requested through a formal process, and the employee confirms they have the access they need.
The goal is zero IT tickets from the new hire. If everything is provisioned correctly based on their role, they should not need to ask for anything.
The Mover process in detail
The mover event is the one most organizations handle worst. When someone changes roles, the natural instinct is to add their new access. But the equally important step — removing the access from their old role — is frequently skipped.
This creates privilege creep. Over time, long-tenured employees accumulate access from every role they have held. A person who started in customer support, moved to sales, and then transferred to product management might still have access to the support ticketing system, the CRM with full sales pipeline visibility, and the product backlog tools. That is a lot of unnecessary access, and it violates the principle of least privilege.
A proper mover process works like this: HR updates the employee's role, department, or manager in the HR system. The IGA tool detects the change and evaluates the new role against the defined access model. New access is granted based on the new role's requirements. Old access is removed unless it overlaps with the new role. The change is logged for audit purposes.
In Microsoft Entra ID, this means updating group memberships, application assignments, and potentially license allocations. Dynamic groups handle some of this automatically when the user's department attribute changes — but dynamic groups alone do not cover everything. Application-level access and manual group memberships need to be addressed too.
The Leaver process in detail
The leaver process is the most security-critical of the three. When it goes wrong, the consequences can be serious: data breaches, compliance violations, and wasted license costs.
A thorough leaver process works like this: HR records the departure with the employee's end date. On the end date (or before, for involuntary terminations), the Entra ID account is disabled, active sessions and refresh tokens are revoked, and MFA registrations are cleared. Within a defined window after departure, the mailbox is converted to shared or email forwarding is set up, OneDrive files are transferred to the manager, group memberships and application access are removed, and licenses are unassigned and reclaimed. After the retention period, the account is permanently deleted.
Speed matters. The account should be disabled immediately when the person's employment ends. Everything else can follow a defined timeline, but that first step cannot wait.
How does JML connect to your HR system?
The most reliable JML processes use the HR system as the source of truth. When HR records a hire, role change, or departure, that data triggers the corresponding identity lifecycle actions.
This HR-driven approach eliminates the biggest failure point in most JML processes: the communication gap between HR and IT. When the joiner process depends on a manager emailing IT, and the leaver process depends on HR remembering to submit a ticket, things get missed.
Adcyma connects to your HR system and Microsoft Entra ID to automate the full JML lifecycle. HR data changes — new hires, role updates, end dates — automatically trigger the right provisioning, role updates, or deprovisioning actions in Entra ID. No manual handoffs, no forgotten steps.
Building a JML process from scratch
If your organization does not have a formal JML process yet, start by mapping your current state: document what actually happens today when someone joins, changes roles, or leaves, and identify the gaps and inconsistencies. Define role-based access profiles for each job function. Establish HR as the trigger, and work with HR to ensure that lifecycle events are recorded promptly and that the data IT needs is accurate. Automate the high-risk items first — account disabling for leavers and account creation for joiners are the most impactful. Then review and improve by running regular audits to check for orphaned accounts and privilege creep. These findings tell you where your JML process needs tightening.