Our use of cookies 
Joiner-Mover-Leaver (JML): The access lifecycle process
The Joiner-Mover-Leaver (JML) process governs how organisations grant, modify, and revoke access to systems throughout an identity’s lifecycle.
It helps organisations maintain least-privilege access while reducing security and compliance risks.
This guide explains how the JML lifecycle works, who is responsible for it, and how organisations manage access securely.
Contents:
- What is the Joiner-Mover-Leaver (JML) process?
- How the Joiner-Mover-Leaver lifecycle works
- Maintaining governance across the JML lifecycle
- Roles and responsibilities in a controlled JML process
What is the Joiner-Mover-Leaver (JML) process?
The Joiner-Mover-Leaver (JML) process is a framework used by organisations to maintain least-privilege access to systems over time.
It is the framework that ensures users and integrations within a system are always assigned the appropriate level of access, permissions and privileges.
For example, preventing a contracted software developer from retaining access to a Git repository after a project ends, or ensuring an application API is disabled when it is no longer in use to prevent a backdoor to sensitive customer data.
JML can apply to all identities across systems, including networks, cloud applications, databases, APIs, service accounts, and automated tools.
The JML process covers the three key stages of an identity’s lifecycle:
- Joining: When a new identity is created and granted initial access. Includes new employees, contractors, temporary project staff, integrations, service accounts, and recently automated agents such as AI tools.
- Moving: When an identity changes role, department, or responsibilities. Access permissions must be updated so that the identity only retains permissions required for the new role.
- Leaving: When an identity no longer requires access. For example, when an employee leaves, a contract ends, a project finishes, or a system integration is retired. Access must be removed or disabled across all relevant systems.
JML policies are implemented through various technologies and platforms, depending on the organisational context.
For example, small teams can have an effective JML process by using simple admin dashboards in Microsoft 365 or Google Workspace, as long as they consistently review access.
In larger organisations, integrations and automations between HR systems, the identity platform and other applications are required to deploy JML across hundreds of people.
How the Joiner-Mover-Leaver lifecycle works
The Joiner-Mover-Leaver process is event-driven, meaning it is triggered when identities join a system, change roles and ultimately leave. Here is what happens in detail during each:
Joining
Joining occurs when a new identity needs access to business systems. This typically happens when a new employee starts work, a contractor begins a project, or a system integration requires authorised access to internal services. The joining stage ensures the identity is created correctly and receives the appropriate permissions from the start.
Key steps in the joining process include:
- Creating the identity: A new identity record is created in the organisation’s central identity system. This record represents the user or service across connected platforms and becomes the reference point for managing permissions and activity.
- Recording identity attributes: Basic attributes are attached to the identity, such as name, department, role, manager or system owner. These attributes help determine which systems and data the identity can access.
- Assigning access through roles or groups: Access is normally assigned using predefined roles or groups. These roles map to job functions or operational responsibilities and automatically grant the permissions required for that role.
- Applying least-privilege access: The identity receives only the access needed to perform its function. This reduces the risk of unnecessary system permissions being granted at the start of employment or integration.
- Centralised identity provisioning: In smaller organisations, identities may be created manually in platforms such as Microsoft 365 or Google Workspace.
Larger organisations often automate this process through identity platforms or HR system integrations, ensuring access is provisioned consistently across systems.
Moving
Moving occurs when an identity changes role, department, or responsibilities within the organisation.
This stage is often the most operationally complex part of the Joiner-Mover-Leaver lifecycle because access must be both granted and revoked across multiple systems.
These may include email platforms, cloud applications, internal databases, collaboration tools, business VoIP phone systems, and other business resources.
The key steps involved in the mover stage include:
Updating identity attributes
The identity record is updated to reflect the new role, department, reporting manager, or operational responsibilities. These attributes determine what level of access the identity should have across business systems.
Adding and removing access
Permissions must be updated to match the new responsibilities. In organisations with well-implemented role-based access control (RBAC), changing the assigned role can automatically grant and revoke the required permissions.
However, many environments still require manual coordination across multiple systems. This may involve approval workflows, service desk requests, or updates performed by different IT teams where access control is not fully centralised.
Access change review
To prevent privilege creep, the role change should be reviewed to confirm that permissions have been correctly updated across all systems.
This review should include business applications, niche tools, legacy platforms, and any systems that are not fully integrated with the organisation’s identity or access management platform.
Leaving
Leaving occurs when an identity no longer requires access to organisational systems. This may happen when an employee leaves the organisation, a contractor’s engagement ends, or a system integration is retired.
The objective is to revoke access quickly and completely.
Deactivating the identity
The identity record is marked as inactive or disabled in the identity platform. This prevents the identity from authenticating to organisational systems.
In most environments, turning off the identity automatically blocks access to connected applications.
Revoking system access
Once the identity is disabled, system permissions must be removed to reduce the risk of unauthorised access after employment or integration ends. This involves:
- Removing application access
- Revoking identity group memberships
- Disabling VPN or remote access
- Removing privileged or administrative roles
Securing credentials and sessions
Any credentials associated with the identity must also be handled to ensure that access cannot continue through indirect authentication paths or previously issued credentials. This involves:
- Terminating active sessions
- Rotating API keys or service credentials
- Transferring ownership of shared resources
Maintaining governance across the JML lifecycle
Joiner, mover, and leaver events drive identity changes, but organisations must maintain oversight of access and permissions over time.
This JML governance process relies on three ongoing controls that ensure access remains appropriate and traceable:
Periodic access reviews
Periodic access reviews confirm that identities still require the permissions they hold. This is a key opportunity to identify and correct mistakes in systems of all sizes and levels of complexity.
In smaller organisations with manual JML processes, reviews help identify human errors in access changes. In larger environments with automated provisioning, reviews serve as a governance safeguard, helping reveal misconfigurations or faults in JML workflows.
Reviews should be cross-departmental and involve the key functions responsible for identity governance, including HR, IT, security, and relevant department or project managers who validate that access remains appropriate.
The review frequency varies between organisations, but should balance maintaining security oversight with the need to avoid unnecessary operational overhead.
Logging and audit records
A key component of compliance with regulations and standards such as GDPR and ISO 27001 is the ability to demonstrate that appropriate controls are in place for identity lifecycle management.
For this reason, JML processes must maintain clear records of lifecycle events and access changes, including:
- The trigger event that initiated the lifecycle action
- Identity updates and approval decisions
- Provisioning actions performed across systems
- Confirmation that access was removed during offboarding
These records create an audit trail that allows organisations to demonstrate that identity governance policies are being followed.
In larger organisations or high-security environments, lifecycle records are often correlated with wider security telemetry from systems such as next-generation firewalls, Endpoint Detection and Response platforms, and business antivirus tools within a central SIEM platform.
This enables security teams to investigate incidents and trace how changes in identity may have contributed to a security event.
Continuous identity monitoring and alerts
While periodic reviews validate access at defined intervals, modern environments also require ongoing visibility into how identities are actually used.
Continuous monitoring analyses identity activity across systems to detect abnormal behaviour, policy violations, or signs of compromised accounts. This may include identifying:
- unusual login patterns
- unexpected privilege escalation
- access to systems outside an identity’s normal role
- suspicious activity from service accounts or automated agents
Security teams often analyse this activity through centralised monitoring platforms. Large organisations will have JML events tracked across a SIEM, while smaller teams get event-driven alerts from their identity platforms.
Continuous monitoring is expected to grow in importance as organisations continue to adopt increasing numbers of cloud services, APIs, automations, and now AI agents. Keeping track of them in real-time is crucial for security.
Roles and responsibilities in a controlled JML process
Since the JML process involves coordination between various teams, effective Joiner-Mover-Leaver (JML) lifecycle management depends on clearly defined responsibilities across HR, IT, security, and operational management.
Without clear ownership, access control errors can accumulate over time, creating a compounding attack surface across organisational systems.
For a controlled JML process to work effectively, responsibilities must be appropriately distributed among the teams involved.
Human resources (HR)
HR acts as the authoritative source of employment status and role information. JML events relating to human identities (employees, contractors, and third-party personnel) typically originate from HR systems or HR communications.
In larger organisations, HR data often serves as the primary trigger for identity lifecycle events within identity and access management (IAM) systems.
Therefore, responsibilities may include:
- Recording new hires, internal role changes, and employee departures
- Maintaining accurate job titles, departments, and reporting lines
- Triggering joiner, mover, or leaver workflows within HR platforms (in larger organisations)
- Providing effective start and end dates for employment or contract changes
Department and project owners
Managers within departments or projects play a key role in determining what access a user actually needs to perform their role.
They define what constitutes least-privileged access for each employee, so they should understand the importance of JML and broader identity security practices. For this reason, many organisations include managers in regular cybersecurity awareness training.
In technical environments, managers may also need to approve the creation or use of system identities, such as automation accounts, service accounts, system integrations, or AI agents used by their teams.
Namely, the responsibilities of these managers usually include:
- Approving access requests for new employees, contractors, or system integrations
- Confirming required systems and applications for a role
- Reviewing the access of their teams during internal role changes
- Validating that permissions are removed when responsibilities or system requirements change
IT teams
IT teams are responsible for implementing and maintaining the technical identity lifecycle across organisational systems. In practice, they carry out the operational execution of the JML process.
Typical responsibilities include:
- Creating and managing digital identities in directory services.
- Provisioning accounts across core platforms such as email, collaboration tools, VPNs, and business applications.
- Updating permissions when employees move roles and integrations change.
- Disabling or deleting identities when employment ends and platforms change.
- Maintaining integration between HR systems, cloud apps and IAM platforms.
Identity security and compliance teams
Security teams provide governance and oversight for the JML process. They are responsible for defining policies and monitoring the management of identities and permissions across the organisation.
In smaller organisations, these responsibilities usually sit within the IT department and are combined with operational security tasks.
More specifically, their role typically focuses on:
- Defining access control policies and security standards
- Monitoring privileged access and segregation-of-duties conflicts
- Auditing joiner, mover, and leaver events
- Identifying privilege creep and dormant accounts
- Ensuring regulatory compliance with standards such as ISO 27001 or Cyber Essentials
Security teams also monitor high-risk system identities, particularly privileged service accounts or automation accounts that may have persistent access to multiple systems.
Operational support teams
The final operational layer of JML often sits with teams responsible for coordinating day-to-day access requests between HR, managers, IT, and security.
In large organisations, this is handled by a dedicated IT service desk. At the same time, in smaller businesses, it is an operational responsibility assigned to an IT administrator or identity security specialist.
The more manual the JML process, the more important this coordination role becomes.
Typical responsibilities include:
- Processing access requests and service tickets (key in manual and semi-automated systems)
- Initiating provisioning workflows within IAM systems
- Coordinating access updates during role changes
- Supporting account suspension or recovery requests
Why does the JML mover stage create the highest access risk?
Within the Joiner-Mover-Leaver lifecycle, the mover stage typically poses the greatest access governance risk because it involves modifying existing permissions and granting new ones, increasing the likelihood of access errors.
However, this is only problematic when JML deployments have the following flaws:
Lack of a formal mover process
Many organisations implement structured onboarding and offboarding procedures, but treat internal role changes more informally.
This is particularly common in growing SMEs, where HR updates job roles, but there is no formal trigger to reassess system permissions. As a result, access changes may be applied inconsistently or not reviewed at all.
Weak integration between HR and IT in larger organisations
In larger organisations, role changes are usually recorded first in HR platforms. Access updates depend on how well these systems integrate with identity and access management platforms.
Where integration is weak, updates rely on service desk tickets, emails, or manager requests that may be delayed or overlooked. This creates a gap in which employees retain permissions that no longer align with their responsibilities.
Manual access management
In small teams without dedicated identity management tools, access updates are often handled manually by an ad-hoc administrator.
If new permissions are added during a role change without reviewing existing ones, users can gradually accumulate privileges. Regular access reviews can help reduce the risk created by these more improvised JML processes.
Manual identity management can create similar risks for service accounts and integrations, particularly in environments where credentials are created or modified outside formal identity governance processes.
Poor role definitions in RBAC systems
Organisations that implement role-based access control (RBAC) can still experience mover-related access issues if roles are poorly defined.
This often occurs in organisations that have grown quickly or inherited legacy systems, where permissions were added incrementally rather than mapped to clearly structured job roles.
Hybrid environments where some systems sit outside the IAM platform
Some organisations operate a mixture of cloud services, legacy platforms, and specialist business applications that cannot be fully integrated with the central identity and access management environment.
When this occurs, mover-related access updates may be applied only to core systems, leaving permissions active on disconnected or overlooked platforms. This is particularly common in organisations that rely on older line-of-business software or niche operational tools.
Temporary or delegated access that is not tracked
Permissions granted for short-term projects, delegated responsibilities, or interim cover arrangements may be managed informally. This is especially true in high-pressure environments or start-ups.
If these permissions are not documented or reviewed during a role change, they may remain active long after the task or project has ended. Over time, this can create hidden access paths that go unnoticed during routine permission updates.
Joiner-Mover-Leaver (JML) FAQs
Our business identity security experts answer commonly asked questions about the Joiner-Mover-Leaver (JML) process:
Is Joiner-Mover-Leaver an HR process?
No. HR triggers JML events for human identities, but JML is a cross-functional identity security process that involves HR, managers, IT, security, and operational support.
Who owns the Joiner-Mover-Leaver process?
Except for very small teams where one person takes full responsibility for JML, ownership is normally shared across departments.
HR manages employment data, managers define required access, IT executes identity changes, and security provides governance and oversight.
What causes privilege creep in JML processes?
Privilege creep is a consequence of inappropriate JML. It happens when access is added during role changes, but old permissions are not removed due to ad hoc manual access changes, poorly defined RBAC models, or systems outside the IAM platform.
How quickly should access be removed after an employee leaves?
Access should be removed as quickly as possible, ideally immediately upon the end of employment or contract access. Privileged and remote access should always be revoked without delay.
Does JML apply to contractors and temporary staff?
Yes. JML should apply to all human identities, including contractors, temporary staff, partners, and other third parties who are granted access to organisational systems.
What are collision scenarios in JML?
Collision scenarios occur when multiple identity lifecycle events overlap or happen in quick succession, causing access changes to conflict or be applied incorrectly.
For example, a user may receive new permissions during a role change. At the same time, their previous access is not removed, or an account may remain active if a departure occurs before a mover update is processed.
These situations can result in incorrect permissions, delayed access removal, or unintended privilege accumulation.
How can we strengthen the JML process?
Organisations strengthen JML by introducing clearer governance and stronger system integration. These measures typically scale with the complexity of the organisation’s systems and access environment.
High-impact strengthening actions include:
- Defining formal workflows for joiners, movers, and leavers.
- Integrating HR systems with identity and access management (IAM) platforms so that identity changes can automatically trigger access updates where possible.
- Improving role-based access control models so permissions align with defined job functions rather than being assigned individually.
- Maintaining application inventories and conducting periodic access reviews to ensure permissions remain accurate across all systems, including those not fully integrated with the central IAM platform.
Back to blog
