← Back to insights

Managed service providers · 19 August 2026 · 4 min

The employee didn't stop existing when you disabled the account

Offboarding in Entra ID is not about disabling an account. It is about everything left behind afterwards — and for a managed service provider, the problem multiplies by the number of client tenants.

Ask a technician what happens when an employee at one of your clients leaves, and the answer comes quickly: the account is disabled, the license is reclaimed, the ticket is closed. Then ask what happened to the group memberships that granted access to shared resources, the device that was never wiped, or the Autopilot registration still pointing at a machine nobody can locate — and the answer comes more slowly.

This is ghost access: remnants of an employment that outlive the employment. In a single tenant, they are an annoyance. For an MSP with fifty or a hundred client tenants, they are a structural problem, because no manual checklist scales to a hundred variants of "remember to clean up."

The core of the problem is that Entra ID gives you no consolidated, queryable view of what an identity actually leaves behind. The information exists — scattered across users, groups, devices, Intune, Autopilot and license assignments — but it has to be actively extracted, tenant by tenant, usually with scripts somebody wrote three years ago and one person maintains.

Entra Logic attacks this with a sync service that continuously maintains a searchable copy of the entire Entra ID and Microsoft 365 estate per client tenant: users, groups, devices, Autopilot registrations, licenses. When someone leaves, the question "what is this identity still holding?" is a lookup, not an excavation. Rule-based cleanup checks systematically catch what the checklist was supposed to remember: devices that were never wiped, registrations that were never removed, memberships that were never ended.

And because the cleanup runs through the same order-and-approval flow as every other change, you get something a checklist never gives you: documentation. Who found the leftover, who approved the removal, what was actually executed. The next time a client — or the client's auditor — asks how you handle leavers, the answer is not a process description. It is a trail.

For an MSP, this is also a commercial point. Offboarding quality is something your clients can actually measure you on, and something your competitors can rarely document. A systematic removal process is, moreover, a standalone argument under the GDPR's data minimisation requirements: retaining unnecessary access to personal data after someone's role has ended is itself a compliance problem for your client as data controller.

Start where it hurts: run a review of one client tenant and count the leftovers. The number tends to argue for itself.

RELEVANT SOLUTION

See how this is handled in practice:

Norwegian version: Les artikkelen på norsk