The mobile device lifecycle in a 1:1 program: five stages most trackers only handle two

A 1:1 device program — one device per student, issued for the school year — looks from the outside like a deployment problem: hand out devices, fix the ones that break, collect them at the end. That's two of the five stages the program actually runs through, and most device-tracking tools are built almost entirely around those two, which leaves the other three running on manual process, institutional memory, or nothing at all.

The five stages

• Procurement and enrollment: devices arrive, get asset-tagged, imaged, and enrolled into MDM before a single student sees one — the stage where a device becomes a trackable, policy-managed asset instead of a box.
• Deployment and check-out: the stage most trackers are built for — assigning a device to a student, recording who has what, capturing a baseline condition.
• In-service support: breakage, loss, insurance claims, loaner swaps while a device is repaired — the stage that generates the most tickets and the most ambiguity about who's responsible for what.
• Collection and check-in, end of term or end of year: the mirror of deployment, with the same condition-comparison problem check-out systems solve for the outbound leg but often skip on the return leg.
• Retirement and refresh: end-of-life wipe, data destruction, and disposal or resale — the stage with the highest compliance exposure and the least tooling attention of any of the five.

Why the missing stages are the risky ones

Deployment and in-service support get the most attention because they're the loudest — a broken laptop generates a ticket, a lost device generates a phone call. Procurement/enrollment and retirement are quiet by comparison, which is exactly why they're where risk accumulates unnoticed. A device provisioned without a clean enrollment record is a device that's hard to locate, reimage, or wipe remotely later. A device retired without a documented data-destruction step is a FERPA exposure sitting in a surplus bin or, worse, resold with student data still recoverable on it — and "we're pretty sure IT wiped it" is not a record that survives a compliance question.

The chain-of-custody problem compounds across the full loop, not just within one stage. A device that was cleanly enrolled but sloppily retired still creates exposure. A device that was carefully wiped at retirement but never had a clean enrollment record in the first place is hard to even confirm was fully accounted for. The lifecycle only closes if every stage hands off a clean record to the next one.

Deployment and repair are loud, so they get built for. Enrollment and retirement are quiet, which is exactly why they're where the compliance risk accumulates.

A full five-stage lifecycle view — with retirement and data-destruction tracking as a first-class stage rather than an afterthought — is on our build path for Nexus, built off the same custody and condition tracking described in the asset check-out workflow, but we're not going to claim the retirement and disposal compliance tracking is fully live in our own practice today, because it isn't yet. If you're running a 1:1 program right now, the useful audit isn't "do we have a device tracker" — it's "can we produce a clean data-destruction record for every device we retired last year," and for most programs, honestly checking that question is worth doing on its own, independent of any tool.