Joiner-Mover-Leaver (JML) Guide

Joiner-mover-leaver (JML) processes decide how access is granted when people arrive, changed when they move and removed when they leave, and when they fail, access outlives the reason it was granted. Leavers whose accounts stay active, movers who keep every entitlement from every role they have held, and contractors whose access outlives their contracts are some of the most common audit findings and a frequent route for insider misuse. JML also shapes non-human identity (NHI) risk: when an employee leaves, the service accounts, API keys, tokens and AI agents they created or knew the secrets for often stay behind. This guide is for identity and security teams who design or run lifecycle processes, for people and for the NHIs attached to them.

Key takeaways

• Start from an authoritative source: HR for employees and a non-employee system of record for contractors and partners, linked to identities by a unique matching attribute such as employee ID.
• Automate the routine path: provisioning, attribute updates and disablement should run from HR events, with tracked tasks for the applications that cannot be connected.
• Movers are the hardest case: remove access tied to the old role on a schedule, not just add access for the new one, and check for segregation of duties conflicts.
• Leaving means more than disabling an account: revoke sessions and refresh tokens, deprovision downstream accounts, rotate shared secrets and reassign or retire the NHIs and AI agents the person owned.
• Measure and reconcile: track time to deprovision, orphaned accounts found in reconciliation and leaver-owned NHIs, and compare every application against the authoritative source on a schedule.

The JML lifecycle at a glance

Every lifecycle event has a trigger, a set of actions and someone accountable for the result. Microsoft's description of lifecycle workflows uses the same three phases: a joiner enters the scope of needing access, a mover moves between boundaries within the organisation, and a leaver leaves the scope of needing access. The table summarises what each event should do.

Microsoft's HR provisioning planning guide asks teams to decide before go-live how rehires, future-dated hires and employee-to-contractor conversions are handled. Write the answers down; they are design decisions, not defaults.

Joiners

A good joiner process gives people what they need on day one and nothing more, and creates an identity the later events can act on.

• Create from HR, before day one: generate the identity from the HR record ahead of the start date, kept disabled or unusable until the start date. Microsoft's provisioning service matches HR records to accounts by employee ID by default, so that value must be present and unique.
• Grant birthright access by role: base default access on role, department and location, using well-defined roles rather than copying another user's access. CIS Safeguard 6.8 asks organisations to define and maintain role-based access control and to review it at least annually. See the Role Mining and Role Design Guide.
• Issue the first credential securely: NIST SP 800-53 IA-5 requires verifying the identity of whoever receives the initial authenticator. A time-limited onboarding credential, such as the Temporary Access Pass that Microsoft's pre-hire workflow template generates, should lead straight to phishing-resistant enrolment. See the Passwordless and Passkeys Guide.
• Route extra access through requests: anything beyond birthright goes through a request with approval and an end date where appropriate, not ad hoc administrator grants. AC-2(e) requires approvals for requests to create accounts.
• Record the owner and dates: CIS Safeguard 5.1 says the account inventory should at a minimum contain the person's name, username, start and stop dates, and department.

Movers

Movers accumulate access because adding is easy and removing needs someone to decide. NIST SP 800-53 PS-5 asks organisations to review and confirm the ongoing need for current access when people are reassigned or transferred, and to modify access to match the change. AC-2(h) adds that account managers must be notified when users are transferred or when need-to-know changes.

• Trigger from HR attributes: job, department, manager, location and employment type changes should each raise a mover event, not wait for the next access review.
• Recalculate birthright access: add what the new role grants and remove what the old role granted, in the same transaction.
• Schedule removal of requested access: access the person requested for the old role should either expire after a short grace period or go to the old and new managers for a decision. Microsoft's "Employee job profile change" template, for example, notifies the manager and schedules removal of all access package assignments, defaulting to 15 days. See the Access Reviews Guide.
• Check segregation of duties: old and new access combined can create conflicts that neither role allows on its own. AC-5 and ISO/IEC 27001:2022 Annex A 5.3 both cover separation of duties. See the Segregation of Duties Guide.
• Transfer ownership: service accounts, app registrations, automations, AI agents and data the person owned in the old role need a new owner before the person's attention moves elsewhere. Microsoft now ships a mover template that transfers AI agent sponsorships to the manager when a sponsor changes roles.

Leavers

NIST SP 800-53 PS-4 sets out the leaver baseline: on termination, disable system access within a defined period, terminate or revoke any authenticators and credentials associated with the individual, retrieve security-related property, and retain access to the information and systems the person controlled. CIS Safeguard 6.2 asks for a process, preferably automated, that disables accounts immediately upon termination, and notes that disabling rather than deleting may be needed to preserve audit trails.

Disable, then revoke what is already issued

Disabling the primary account stops new sign-ins, but it does not end every session that already exists. Microsoft's guidance on revoking access explains why: access tokens it issues last one hour by default, and applications that issue their own session cookies keep controlling access until they send the user back to the identity provider. Microsoft Entra ID cannot directly revoke a session token issued by an application. The table shows what each layer needs.

The OpenID Continuous Access Evaluation Profile defines a "session revoked" event so that an identity provider can tell cooperating applications that a session has ended, which helps close that gap. See the Token and Session Security Guide.

Privileged leavers

Remove privileged role assignments, check out and rotate any vaulted credentials the person retrieved, and rotate shared administrative passwords they knew. Give privileged leavers a shorter deadline. See the Privileged Access Management Guide.

The non-human side of leavers

People create and hold NHIs. When they leave, those NHIs become orphaned or remain usable by someone who should no longer have access. OWASP lists this as NHI1:2025 Improper Offboarding and describes three causes: the service is retired, the original owner departs without a new owner being designated, or an administrator or developer who was exposed to the credentials leaves. OWASP's prevention advice is to review all NHIs associated with departing employees, decommission those no longer required, transfer ownership of the rest and rotate any credentials the person could access.

The Coupang Breach 2025 shows the cost. According to The Record, the perpetrator was a former employee who had developed Coupang's alternative authentication system and stole the signing key behind it before leaving at the end of 2024. CSO reported a lawmaker's office saying the signing information was not updated when the employee in charge left. Coupang said 33.7 million customer accounts were notified.

AI agents add a new leaver dependency. Microsoft Entra Agent ID requires at least one sponsor for each agent identity and says sponsorship should be maintained to ensure succession when a sponsor moves or leaves. Its lifecycle workflow templates now include "Transition agent sponsorships when a sponsor leaves", which transfers sponsorships to the manager. Whatever the platform, every leaver run should name a new accountable person for each agent.

Contractors, partners and other non-employees

Non-employees often sit outside the HR system, so the leaver trigger that protects employees never fires for them. NIST SP 800-53 PS-7 requires external providers to notify the organisation of transfers or terminations of their personnel who hold credentials, badges or system privileges, within a defined period.

• Sponsor every non-employee: each contractor, partner user or guest has an employee sponsor accountable for their access, and sponsorship moves with the sponsor's own JML events.
• Set end dates on every identity: access expires automatically unless the sponsor renews it. Microsoft's entitlement management, for example, lets a policy set an expiry such as 180 days and can block and then remove a guest account once its last access package assignment ends.
• Use a system of record, not spreadsheets: CIS Safeguard 5.1 expects start and stop dates in the account inventory; a vendor management system or non-employee register provides them.
• Write offboarding into contracts: CSF 2.0 GV.SC-10 covers activities that occur after a partnership or service agreement ends. Require suppliers to report leavers and to return or destroy credentials.

See the Third-Party Access Guide.

Automation and reconciliation

Manual steps are where delays and gaps appear. NIST SP 800-53 AC-2(1) supports managing accounts with automated mechanisms, and PS-4(2) covers automated actions on termination.

Connect sources and targets

• Lifecycle engine: connect HR and non-employee systems to an IGA platform or IdP lifecycle engine. See the IGA Buyer's Guide.
• SCIM for applications: RFC 7643 defines the SCIM user attribute "active" as the user's administrative status, where false typically means the account is suspended, and RFC 7644 defines deletion with DELETE, after which the service provider must return 404 for the resource. Decide per application whether leavers are deactivated or deleted. See the SCIM Provisioning Guide.
• Disconnected applications: generate tracked tasks with an owner and a deadline, and treat overdue tasks as findings.
• Schedule awareness: provisioning runs in cycles, not instantly. Microsoft states its app provisioning typically runs every 20 to 40 minutes, so urgent leavers need an on-demand path as well.

Reconcile regularly

Reconciliation compares the accounts in each application with the authoritative source to find orphaned and unauthorised accounts. CIS Safeguard 5.1 asks for active accounts to be validated as authorised at least quarterly, and Safeguard 5.5 asks the same of service accounts, with an owner, review date and purpose recorded. Disable dormant accounts too: CIS Safeguard 5.3 sets 45 days of inactivity where supported, and Microsoft's "Offboard inactive users" template defaults to 120 days.

Detection and monitoring

JML controls fail quietly, so monitor for evidence of failure. AC-2(4) asks for automatic auditing of account creation, modification, enabling, disabling and removal, and AC-2(12) for monitoring accounts for atypical usage.

• Sign-ins after the leave date: any successful authentication by an identity whose HR record shows it has left, including through tokens, API keys or SSH keys linked to that person.
• NHI use after the owner leaves: activity from service accounts, keys or agents whose owner has left and that have not been reassigned.
• Access added outside the process: direct grants to groups or roles without a matching request or role change.
• Unusual activity in the notice period: bulk downloads, new tokens or new OAuth grants created by people who have resigned. Coordinate with HR and legal. See the Insider Threat and Identity Guide.
• Lifecycle job failures: provisioning errors and overdue manual tasks mean leavers are not being processed.

See the ITDR Guide.

Common failure patterns

• Disabled but not revoked: the directory account is disabled but refresh tokens, application sessions and personal access tokens keep working until they expire.
• The dormant account nobody disabled: in the Colonial Pipeline Ransomware Attack 2021, Mandiant said the VPN account used was no longer in use but had not been disabled, and it had no MFA. Reconciliation and dormancy rules exist for exactly this.
• Movers who keep everything: access is added for each role and never removed, so long-serving staff hold the widest access.
• Keys that leave with the engineer: the person who built a system knew or held its secrets and nobody rotated them, as in the Coupang Breach 2025.
• Contractors with no end date: non-employee accounts are created by hand, have no sponsor and no expiry, and survive the contract.
• Disconnected apps forgotten: applications outside SSO and SCIM rely on an email to an administrator that nobody tracks.
• Automation running on personal credentials: scripts and AI agents run under a person's account, so disabling the leaver breaks a business process and the team re-enables the account. OWASP calls the reverse pattern NHI10 Human Use of NHI; both blur accountability.

Framework mapping

Mappings were checked against the published control text of each framework.

Metrics that show progress

Measure the speed and completeness of each event, and report privileged users and NHIs separately.

Implementation roadmap

If a leaver's credential has been used, see the Leaked Credential Response Playbook.

Practitioner checklist

• Use HR and non-employee systems of record as authoritative sources, with a unique matching attribute.
• Document rehire, future-dated hire and worker conversion handling.
• Automate joiner provisioning with role-based birthright access and a secure first credential.
• Remove old-role access for movers on a schedule and check SoD conflicts.
• Disable leavers promptly, revoke sessions and refresh tokens, and deprovision downstream accounts.
• Rotate shared and group credentials the leaver could access.
• Include NHIs in leaver processing: tokens, keys, OAuth grants, owned service accounts and AI agents.
• Transfer NHI and AI agent ownership or sponsorship on mover and leaver events.
• Set sponsors and end dates for every non-employee identity.
• Track manual deprovisioning tasks for disconnected applications to a deadline.
• Reconcile applications against authoritative sources at least quarterly and disable dormant accounts.
• Monitor for sign-ins and NHI use after the leave date.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls (AC-2, PS-4, PS-5, PS-7)
• NIST: The Cybersecurity Framework (CSF) 2.0
• ISMS.online: ISO/IEC 27001:2022 Annex A Controls
• CIS: Controls Assessment Specification, Safeguard 6.2 Establish an Access Revoking Process
• OWASP: NHI1:2025 Improper Offboarding
• OWASP: Top 10 Non-Human Identities Risks 2025
• IETF: RFC 7644, SCIM Protocol
• IETF: RFC 7643, SCIM Core Schema
• Microsoft Learn: Lifecycle Workflows templates and categories
• Microsoft Learn: Plan cloud HR application to Microsoft Entra user provisioning
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• GitHub Docs: Reviewing and revoking personal access tokens in your organization

Related NHI Mgmt Group resources: IAM and IGA Basics · Workforce Identity Security Guide · NHI Lifecycle Management Guide · Access Reviews Guide · Human vs Non-Human Identity