Most conversations about mobile device management focus on the moment a device arrives: unboxing, enrollment, configuration, and getting it into someone’s hands ready to work. Far fewer conversations focus on what happens when that same device leaves.

An employee changes roles. A device breaks. Someone leaves the company. A tablet gets lost in a delivery truck, or a phone stops working after two years of daily use in a warehouse. In every one of these situations, a device that was once carefully enrolled and configured suddenly needs to be un-enrolled, wiped, tracked down, or replaced. If there isn’t a real process for that, it usually doesn’t happen cleanly.

Why offboarding gets skipped.

Deployment gets attention because it’s visible and time-bound: a new hire starts Monday, a new store opens next quarter, a fleet expands and needs devices right away. Offboarding is less visible. There’s rarely a hard deadline forcing anyone to deal with a returned device today rather than next month, so it tends to pile up, both literally, in a drawer somewhere, and procedurally, as a growing list of devices nobody has formally accounted for.

That gap creates three separate problems.

The first is security. A device that still has an active MDM profile, corporate email access, or stored credentials is a live risk the moment it leaves an organization’s control, whether that’s because an employee left on good terms and forgot to return it, or a device was lost or stolen. Every day a device stays enrolled and unaccounted for is a day it can be used to access systems it shouldn’t.

The second is asset visibility. Organizations that carefully track devices during deployment often lose that discipline once a device changes hands or gets swapped out. Over time, that produces a widening gap between how many devices IT thinks it owns and how many actually exist, in service, in a drawer, or gone entirely.

The third is cost. A device that could have been wiped, refurbished, and redeployed to someone else instead sits unused, or gets replaced by a new purchase because nobody tracked down the old one. At scale, that’s not a rounding error. It’s a recurring, avoidable expense.

What good offboarding actually involves.

A device offboarding process, done properly, needs to handle a short list of triggers consistently:

• An employee leaves the company or changes roles that no longer require the device
• A device is damaged, lost, or stolen
• A device reaches the end of its planned refresh cycle
• A device fails and needs to be swapped for a working replacement

For each of those triggers, the mechanics are fairly consistent regardless of which one applies. The device needs to be removed from mobile device management, whether that means a full wipe or removing a managed work profile, depending on whether the device is company owned or a personal device enrolled under a bring-your-own-device policy. Corporate accounts, email access, and any stored credentials need to be revoked. If the device is being physically recovered, that needs a real reverse logistics plan: someone responsible for collecting it, a process for shipping or returning it, and a clear record of where it ends up. And the asset record needs to be updated immediately, not eventually, so IT’s inventory reflects reality rather than a snapshot from months ago.

Apple’s Business Manager and Android Enterprise both support remote un-enrollment and remote wipe as standard mobile device management capabilities, so the technical piece of offboarding usually isn’t the hard part. The hard part is making sure it actually happens every time, for every device, without depending on someone remembering to do it manually.

Signs the process already has gaps.

• IT can’t say exactly how many devices are currently enrolled versus how many were ever purchased
• Returned devices sit in a drawer or storage room for weeks before anyone processes them
• Former employees’ accounts get deactivated, but nobody confirms their device was wiped and un-enrolled
• Device counts in the MDM console don’t match device counts in the asset management system
• Offboarding happens only when someone remembers, rather than as a defined, owned responsibility

The case for automating the trigger, not just the process.

Most organizations that struggle with offboarding aren’t missing the technical tools. They’re missing the trigger. If a device’s offboarding process only starts when someone in IT happens to notice a device should be retrieved, the process will always run late and inconsistently.

The organizations that handle this well typically connect offboarding to an event that’s already tracked somewhere else: an HR system marking an employee as terminated, a helpdesk ticket logging a lost or damaged device, or a scheduled refresh cycle that flags devices reaching end of life. When device offboarding is triggered automatically by one of those existing events, instead of relying on someone remembering to start it, the whole process becomes dramatically more consistent.

Why this matters more as fleets grow.

An organization with a dozen devices can manage offboarding informally and probably get away with it. An organization with hundreds or thousands of devices across multiple locations cannot. At that scale, a handful of ungoverned offboarding events each month compounds into a meaningful population of devices that are unaccounted for, still enrolled, or quietly costing money sitting unused.

This is often where growing organizations discover a gap they didn’t know they had. They invested real effort in getting zero-touch deployment right: fast enrollment, consistent configuration, devices ready to work on day one. But device retrieval never got the same attention, because it never had the same urgency. By the time the gap becomes visible, usually through a security audit, a lost-device incident, or simply not being able to account for how many devices are actually in the field, it’s already an expensive problem to untangle.

The other half of lifecycle management.

Managed mobility is often described as getting the right device to the right person, configured correctly, on time. That’s true, but it’s only half the lifecycle. The other half is getting that same device back, cleanly and on a predictable schedule, whether it’s headed to a new person, a refurbishment queue, or responsible disposal.

A deployment program that only accounts for devices going out, and not devices coming back, isn’t actually managing the full lifecycle. It’s managing half of it, and hoping the other half takes care of itself.

If your organization is trying to get a handle on device offboarding, whether that’s building a retrieval process from scratch or tightening up gaps in an existing one, reach out to ConnectUs to talk through what that looks like for your fleet.