How MSPs Can Manage Client User Leaver Requests

A client user leaver request is an instruction from an authorised business contact to end or change a person's access to managed systems at an agreed point. For a managed service provider, the work is not complete simply because the primary login has been disabled. The same individual may have cloud sessions, independent supplier accounts, privileged roles, delegated access, mobile devices and responsibility for services that must continue operating. The provider must revoke the access the client has authorised it to manage whilst protecting business records and preserving a clear record of decisions.

The practical difficulty is timing and ownership. A request may arrive from an unfamiliar colleague, specify only a name or say 'remove everything immediately' without establishing which systems the MSP actually supports. Acting on incomplete instructions could interrupt legitimate work or expose confidential information. Ignoring an urgent and valid instruction can leave access open. A dependable intake process separates confirmation of authority, identification of accounts, effective timing, technical execution and verified closure. It should also distinguish an ordinary scheduled departure from a suspected security incident, which follows its own escalation rules. These are related but different obligations.

Verify the client instruction before changing access

Receive the leaver request through the agreed service channel and identify the business contact who is entitled to authorise it. The request should have a stable case reference, the correct client's organisation, the user's verified identity, the effective date and time, and the scope of action. A familiar name in an email signature is not sufficient proof of authority for a high-impact account change. Follow the client's authorised contact register and verification process, especially if a caller asks for an exceptional or immediate action. Do not substitute an MSP technician's opinion about why somebody is leaving for the client's actual instruction.

Keep employment circumstances out of ordinary IT notes unless they are genuinely necessary for an authorised technical decision. The service desk usually needs to know which account to affect, when to act and who can approve data or equipment decisions. It does not need rumours, allegations or private personnel records. If an instruction is ambiguous or appears to conflict with the contract, refer it to the proper client owner rather than choosing a plausible interpretation. For urgent cases, the pre-agreed escalation route should provide a way to obtain confirmation without bypassing the identity checks that protect the customer.

Document any change to the instruction. A scheduled departure can become immediate, or a manager may approve limited access until a documented handover is completed. Capture who authorised the revision, the time and the systems affected. Preserve the original record for auditability; do not rewrite it as if the later decision had always been in place.

Set the effective time and understand service coverage

Time is a control, not a cosmetic ticket field. Record the date, exact time and time zone requested, and clarify whether the instruction is to stop sign-in, revoke sessions, remove specific permissions or complete the entire offboarding process. A user working an evening shift may legitimately need access until the end of that shift. Equally, an urgent security instruction may require immediate containment under approved incident procedures. The MSP should not assume that midnight is the correct default for every client.

Confirm whether the provider has the contracted support coverage and technical access required at the specified time. If a departure is scheduled outside normal hours, identify the permitted automation or on-call arrangement and the owner who will verify execution. A workflow configured to run at a future time is not proof it has run successfully. A request sitting in an unstaffed queue is not active incident response. When the requested timing cannot be met safely, escalate the gap to the authorised client contact early, explain the actual options and retain a factual decision trail.

Use the correct time zone when a client has offices in different countries. Different identity and application systems may process changes at different intervals, so the requested cut-off and the observed final loss of access can differ. Record that limitation honestly rather than promising simultaneous revocation across independent suppliers.

Map the user's access beyond the main account

Start with the identity or personnel reference authorised by the client and establish the relevant managed footprint. A person may have an ordinary user account, a separate privileged account, virtual private network rights, a cloud tenant login, mailbox delegation, shared system roles and vendor-hosted applications. A disabled primary directory account does not necessarily remove access to software with independent local credentials or ongoing browser sessions. Use current inventory, access-group records and approved service documentation to find each relevant target; do not guess that two accounts with similar names belong to the same person.

Record systems outside the MSP's contractual authority rather than silently attempting to modify them. A client may own a finance portal or supplier relationship whose access only its internal administrator can revoke. Provide a specific action and accountable client owner for such systems. Distinguish direct permissions from permissions inherited through groups. Removing one group membership may leave another route to the same resource, so a completed task should be checked against effective access in the target platform where appropriate.

Identify sensitive privileges and external collaboration accounts explicitly. Administrator access, remote support tools, API tokens and security keys may require specialist handling. A routine leaver ticket should not reveal those secrets to every support worker. Link restricted evidence through the approved system and make only the necessary outcome visible to the general service-desk queue.

Understand account disablement, sessions and automated workflows

Microsoft's guidance for Entra ID distinguishes blocking an account from revoking refresh tokens and from sessions controlled by an individual application. Its documented administrator procedure can disable an account and invoke session revocation, but an application that issues its own cookie may continue to control its session until its own rules take effect. Some connected SaaS applications must be separately deprovisioned. Therefore the statement 'Entra account disabled' is valuable evidence for that identity system, not proof that every third-party session ended at the same instant.

Microsoft Entra Lifecycle Workflows can automate supported joiner, mover and leaver tasks under configured conditions, including disabling accounts and removing selected memberships. They depend on identity attributes, workflow scope, the correct licence and actual task execution. A workflow being scheduled does not establish that every configured task completed, still less that an unconnected supplier application was updated. Review execution history and failures. If the client uses another identity platform, follow its documented contract instead of borrowing Microsoft-specific steps by analogy.

In practice, an MSP may use direct authorised administrative actions for an exceptional urgent revocation and configured lifecycle workflows for predictable scheduled offboarding. Neither method removes the need for access inventory, approvals and downstream verification. The correct choice depends on the client's infrastructure and risk, not which approach offers the tidiest dashboard.

Protect business information and operational dependencies

Removing a person's access and deciding what happens to their company data are separate decisions. Mailbox delegation, cloud-file ownership, shared calendars, customer records and retention may require approval from a business or information owner under the client's policies and applicable obligations. An MSP should not grant a manager unrestricted mailbox access simply because they requested account disablement. Confirm the lawful business purpose, access scope, recipient and approved method before transferring anything. Keep private employee information away from general operational discussion.

Check whether the departing user owns automated processes, service integrations or scheduled reports. A long-lived workflow running under a personal identity can stop when the account is disabled. That is a reason to identify and migrate the dependency through an authorised process, not a reason to keep the former employee's unrestricted interactive account alive. Document which service must continue, who will own it, what credentials or permissions will change and how the result is tested. Where this cannot be resolved before the effective time, escalate the business-continuity risk and agree a controlled mitigation.

Licence recovery is another distinct step. Reclaiming a seat may be appropriate after an account is disabled, but timing and data-retention features can depend on the vendor's terms. Never remove a licence or delete a user object as a shortcut without checking the service's actual data and retention consequences. An audit trail must show what was changed and which related tasks remain open.

Coordinate equipment, authentication factors and suppliers

Identify client-managed laptops, phones, security tokens, smart cards and specialist peripherals assigned to the user. The MSP may be responsible for technical disablement and asset records whilst the client's HR or facilities team arranges physical collection. Distinguish 'collection requested', 'courier booked', 'device received' and 'ready for reuse'. None is equivalent to another. Record the actual custody evidence, not a hopeful status update. If an important device cannot be recovered, follow the client's security and asset procedures without automatically alleging theft or data loss.

Reassignment requires more than changing the name in an asset register. Where appropriate, preserve authorised business information, remove previous sessions, check management enrolment and apply the approved sanitisation and redeployment process. Do not wipe a personally owned device or destroy information that must legally be retained without explicit authority. Device-management tools can report actions sent to a device that has not connected; verify the effective result when possible and keep unresolved cases assigned.

For services operated by suppliers, record the support entitlement, secure case route, affected account and supplier confirmation. An acknowledgement from a portal is not evidence that permission was removed. Where the MSP cannot directly view the final state, identify the client owner who can obtain the necessary verification. Keep customer and personnel information proportionate when communicating with outside parties.

Verify, report and close without concealing exceptions

Use a scoped action register that lists each managed identity, service or device, the approved action, the owner, actual time of execution, observed result and next check. Verify the primary account status and the relevant supported session actions, and review independent application outcomes as appropriate. Do not test a former employee's password by attempting unauthorised sign-in. Prefer approved administrative evidence, supplier confirmations and controlled access checks performed by authorised staff. For automated workflows, distinguish task scheduled, task executed and target state confirmed.

Give the authorised client a factual summary: actions completed, effective timing, services outside the MSP's remit, outstanding supplier work, device return status and any business-data decisions awaiting approval. A ticket can show completed technical tasks whilst linked exceptions remain under separate ownership; the summary should not present this as a universal access-removal guarantee. Where the client changes its instruction, keep the new authorisation and related execution evidence connected to the original case.

Finally, review the recurring causes of slow or uncertain leaver requests. Missing access inventory, forgotten supplier accounts, scheduled jobs tied to personal identities and unclear authorisation can all begin long before somebody leaves. Improve the joiner and mover processes accordingly. A good MSP leaver workflow is one in which the right access is removed under verified instruction, legitimate service continuity is maintained and all remaining uncertainties are visible to the people responsible for them.

Original evidence: Microsoft Learn — Revoke user access in Microsoft Entra ID, Microsoft-specific account, token and session behaviour (accessed 29 October 2026); Microsoft Learn — What are lifecycle workflows?, Entra ID Governance leaver automation and licensing scope (accessed 29 October 2026). These first-party technical references do not establish the employer's instructions or the MSP's contractual service boundary.