How should organisations manage joiner-mover-leaver processes across employees and contractors?

They should use a single lifecycle model that applies the same governance rules to employees, contractors, and contingent workers, while still allowing role-specific entitlements. The key is authoritative triggers, consistent approvals, and automatic removal when access is no longer justified. Separate regional processes usually create delays, exceptions, and weaker audit evidence.

Why This Matters for Security Teams

A joiner-mover-leaver process only works when it follows the identity lifecycle, not the employment category. Employees, contractors, and contingent workers all create access that must be granted, changed, and removed from the same authoritative workflow. When organisations split these paths, access reviews become inconsistent and revocation often lags behind business change. That is exactly where audit gaps and over-privilege accumulate. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often lifecycle discipline breaks down in practice. See the broader lifecycle view in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the governance baseline in NIST Cybersecurity Framework 2.0. In practice, many security teams encounter lingering access only after a contractor has already left or moved roles, rather than through intentional lifecycle control.

How It Works in Practice

A practical JML model starts with one intake path and one control model, even if downstream entitlements differ by workforce type. The key is to make the authoritative trigger the source of truth. HR events, vendor management records, contract end dates, and manager approvals should all feed the same identity governance workflow, then drive provisioning, modification, and deprovisioning automatically. That is consistent with the lifecycle and audit emphasis in NHI Lifecycle Management Guide and the control logic in NIST Cybersecurity Framework 2.0.

At minimum, the workflow should distinguish who approves access, who certifies it, and who can revoke it. Best practice is to automate those transitions wherever possible:

• Joiner: create the identity from an authoritative source, assign the minimum required baseline access, and issue approvals before activation.
• Mover: recalculate entitlements when role, team, location, or contract scope changes, then remove access that no longer maps to the new context.
• Leaver: disable accounts immediately, revoke sessions and secrets, and confirm removal from downstream systems, not just the directory.

This matters because lifecycle failures are not limited to human directories. Secrets, API keys, service accounts, and shared operational access often survive long after a worker leaves. NHI Mgmt Group’s Top 10 NHI Issues highlights how often excess privilege and poor visibility turn simple lifecycle errors into persistent risk. Organisations should also align approvals with least privilege and zero standing access where feasible, so temporary work does not leave permanent access behind. These controls tend to break down when contractor onboarding is handled outside the core identity platform because revocation then depends on manual notice, not system-enforced termination.

Common Variations and Edge Cases

Tighter lifecycle control often increases process overhead, requiring organisations to balance revocation speed against operational friction. That tradeoff is most visible with contractors, agencies, and cross-border workers, where local legal rules, procurement workflows, and sponsor approvals can slow down changes. Current guidance suggests the answer is not a separate JML model for each group, but a shared control framework with role-specific exceptions that are documented, time-bound, and reviewable. For audit purposes, the exception should be the entitlement, not the process.

There is no universal standard for how much autonomy managers should have in granting access to contingent workers, but current practice favours strong central controls for activation and deactivation, with business owners supplying the justification. Organisations should also ensure that access removal covers downstream systems such as SaaS apps, VPNs, code repos, and credential stores, because directory deprovisioning alone rarely closes the risk. For deeper regulatory and evidence considerations, see Ultimate Guide to NHIs — Regulatory and Audit Perspectives. The hardest cases are short-term contractors with broad emergency access, because urgent work often bypasses normal approval and leaves incomplete offboarding evidence.

Related resources from NHI Mgmt Group

• 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 organisations automate joiner mover leaver access changes?
• What breaks when joiner, mover, leaver processes are handled differently for technical accounts?