Third-party joiner-mover-leaver is the lifecycle model used to govern non-employees whose access changes with a contract, assignment, or vendor relationship. It extends standard JML thinking to external users, with stronger emphasis on onboarding speed, access scoping, and immediate offboarding.
What Third-Party Joiner-Mover-Leaver Means in Practice
Third-party joiner-mover-leaver is the operational lifecycle for external people and organisations whose access changes as contracts, assignments, or vendor relationships change. Its purpose is to keep non-employee access aligned to current business need, not historical trust.
Unlike employee JML, third-party JML must account for sponsor ownership, vendor handoffs, variable start and end dates, and access that may span multiple systems or business units. The central question is not only who the person is, but who is accountable for their access at each stage.
Why Third-Party JML Is More Demanding Than Employee JML
Third-party access is often created quickly because delivery pressure is high and the relationship is temporary, but it is harder to govern because the organisation does not control the full employment lifecycle. That makes onboarding speed, scope precision, and termination discipline equally important.
Contractor and supplier access can also be fragmented across identity systems, SaaS tools, VPNs, shared workspaces, and privileged admin channels. NHIMG’s Third-Party, B2B and Contractor Access Guide is useful because it shows how sponsorship, least privilege, and time limits support this model.
When third parties are treated like long-term internal users, access creep starts to accumulate. IAM and IGA Basics helps frame why entitlement governance and access review matter here, even when the account holder is outside the workforce.
Core Lifecycle Stages and Control Expectations
Joiner means a third party is sponsored, scoped, and provisioned only for the specific work, environment, and duration approved. Mover means the access set is adjusted when the vendor role, project scope, or support obligation changes. Leaver means access is removed promptly when the relationship ends, not when someone notices the account is idle.
This lifecycle is usually driven by authoritative events such as contract start and end dates, statement-of-work changes, ticket approvals, or vendor offboarding notices. The control value comes from binding those events to real account changes, including revocation of sessions, tokens, keys, and delegated access paths.
Where organisations have repeatable third-party patterns, a structured lifecycle model reduces orphaned accounts, excessive permissions, and lingering credentials. NHIMG’s Joiner-Mover-Leaver (JML) Guide is the clearest companion for the lifecycle mechanics, while NHI Lifecycle Management Guide shows the same lifecycle logic applied to identities and credentials that must be discovered, rotated, and retired.
Common Failure Modes and Governance Boundaries
The main failure mode is stale access that survives the business relationship that justified it. Another common failure is mover events being handled as informal exceptions, which leaves third parties with broader entitlements than their current task needs. A third is poor ownership, where business teams assume procurement, IT, or the vendor will clean up access.
Third-party JML is also where governance often breaks between people management and system reality. A contract may end cleanly on paper while SSO sessions, API tokens, admin roles, file shares, and support portals remain active. Top 10 NHI Issues is relevant here because third-party access frequently intersects with unmanaged credentials, overprivilege, and delayed offboarding.
Good governance therefore requires a named owner for sponsorship, entitlement scope, review cadence, and termination confirmation. Without those boundaries, third-party JML becomes a process of assumptions rather than enforcement.
Risk and Threat Considerations
Third-party JML creates exposure because external access is often broader than necessary, harder to monitor, and slower to remove than internal access. If a vendor account, token, or support privilege is not retired on time, the relationship itself becomes an attack path.
Failure mechanism: stale sponsor records, weak offboarding, and excessive standing access leave third-party accounts usable after the business need has ended. Attackers can exploit that gap through stolen credentials, compromised integrations, or abandoned privileges.
Impact: unauthorised access can persist undetected, enabling data theft, lateral movement, privilege abuse, or misuse of trusted vendor paths. In the worst case, a terminated relationship becomes a durable foothold into production systems or sensitive records.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Third-party JML depends on issuing, rotating, and revoking credentials for external accounts. |
| AC-2 — Account Management | JML is fundamentally about creating, modifying, reviewing, and disabling accounts across the lifecycle. | |
| AC-6 — Least Privilege | Third-party JML must constrain external access to the minimum needed for the approved task. | |
| Recommendation — Manage third-party authenticators so access is revoked or rotated when the relationship changes. Tie third-party account creation, change, and disabling to the approved business relationship. Limit third-party entitlements to the smallest set required for the current assignment. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Third-party JML is an identity management process for external users and their access changes. |
| A.5.18 — Access rights | External access must be provisioned, adjusted, reviewed, and removed as relationships change. | |
| Recommendation — Maintain a controlled identity lifecycle for third parties from onboarding through offboarding. Review and revoke third-party access rights when scope or relationship changes. | ||
Practitioner Guidance
Governance implication: third-party JML should be owned as a lifecycle control, not treated as a one-time onboarding ticket. The sponsor, service owner, and access approver need a clear handoff model so that mover and leaver events trigger actual entitlement changes.
What to watch for: accounts without expiry dates, access that outlives the contract, and third parties retaining admin or integration privileges after scope changes. Those are usually the earliest signals that the lifecycle model is failing in practice.
Practitioner takeaway: the quality of third-party JML is measured less by how fast access is granted and more by how reliably it is narrowed, reviewed, and removed when the relationship changes.
Related resources from NHI Mgmt Group
- Why do third-party application credentials create residual risk after a Joiner-Mover-Leaver event?
- Why do service accounts and API keys complicate joiner-mover-leaver processes?
- How can organisations use access profiles in joiner-mover-leaver workflows?
- How should security teams automate joiner-mover-leaver workflows?