Published 2026-09-04 · LuckyMDM Blog
Short answer: a returned device is not a sellable asset until four things have happened in a fixed order: release the activation lock, unenrol it from the MDM server, erase it to a recognised standard, then grade and verify it. Activation lock and MDM enrolment are two independent systems - clearing one does not clear the other, and doing them in the wrong order is how a working handset becomes a brick or stays managed without anyone noticing. This page sets out the four-step chain, where NIST SP 800-88 Rev. 1 (Clear / Purge / Destroy) fits and which of the three applies to a remarketed fleet unit, why residual value is usually the largest single line in a device subscription P&L, and a seven-point acceptance checklist for the returns bench. Nothing here guarantees an outcome: capabilities vary by brand, model, OS version and enrolment route.
In a device subscription or DaaS business, the monthly fee is the visible number and the residual value is the one that decides whether the model works. A handset bought for USD 1,000 and returned after 24 months at a 45% residual contributes more to the unit's total contribution than several months of subscription income combined. Move that residual to 30% and a portfolio that looked sound on paper stops being sound.
What makes this awkward operationally is that residual value is not determined at sale time. It is determined on the returns bench, by whether the unit can be cleared, graded and resold as a normal device. A fleet that is perfectly managed during the term can still destroy a large share of its residual value in the last forty-eight hours, purely through offboarding sequence.
The single most common failure is treating device lock as one thing. It is at least two, and they are administered in different places.
| System | What it protects | Where it lives | Who can release it | What happens if it is missed |
|---|---|---|---|---|
| Activation Lock (Find My / FRP) | Anti-theft, tied to the end user's account | The vendor's activation service | The account holder, or the organisation via ABM-managed activation lock controls | Device cannot be set up by anyone else; effectively unsellable |
| MDM enrolment | Organisational management, tied to the serial number | Your MDM server plus the vendor's enrolment record | The MDM administrator | Device re-enrols on every reset; buyers discount it heavily or refuse it |
Two consequences follow directly. First, wiping a device clears neither of them - that is the point of both designs. Second, removing management does not touch activation lock, and vice versa. A returns process that only does one is shipping devices that look fine and are not.
The order below is not stylistic. Each step depends on the previous one having completed.
Confirm the renter has signed out of the device account and turned off Find My (or the Android equivalent), and verify it rather than assume it. Where devices were enrolled through Apple Business Manager or Android zero-touch, the organisation also holds server-side controls over activation lock - use them, and reconcile against the account state afterwards.
Do this first because every later step is blocked by it. Attempting a wipe before activation lock is released produces a device that is erased, unrecoverable by you, and still unusable by anyone else.
Issue the unenrolment command, confirm the device processed it, and confirm the profile is gone from the device itself. Then release the serial number inside ABM or the equivalent vendor portal.
The release step is the one most often skipped, and it is the reason devices "come back". If the serial number is still assigned to your organisation, the next activation will re-enrol the unit regardless of what the previous user did. This is also the step with the clearest audit value: an unreleased serial is a device you are still nominally responsible for.
Not "wipe it and check it looks clean". Name the standard, because it determines whether you can defend the process to an enterprise customer or an auditor.
Grade cosmetic and functional condition, verify the unit is clean through a full activation (not just a wipe), and record the result against the serial number. The record is what makes the residual value claim defensible later - a grade with no evidence behind it is an opinion.
NIST Special Publication 800-88 Revision 1, Guidelines for Media Sanitization, defines three sanitisation outcomes. Fleet operators regularly use the wrong one in both directions - over-sanitising units that are being remarketed, and under-sanitising units that are being retired.
| Outcome | Definition | Applies to | Typical method on a mobile device |
|---|---|---|---|
| Clear | Logical erasure that protects against simple, non-invasive recovery | Devices leaving your control while still functional and being reused | OS-level factory reset on an encrypted device, with the encryption keys discarded |
| Purge | Physical or logical erasure that protects against laboratory-level recovery, including cryptographic erasure | Devices leaving your control permanently with sensitive data, or where the storage cannot be verified as encrypted | Crypto erase by destroying the keys, or vendor purge tooling |
| Destroy | Physical disintegration so the media cannot be reused | Failed units, and any device where Clear or Purge cannot be verified | Shredding, disintegration, incineration |
The practical rule for a rental or subscription fleet: Clear is the default for remarketed units, because the device still has value and the data was already protected at rest by full-disk encryption - the reset discards the keys, which is what makes the data unrecoverable. Purge applies when the unit is retiring rather than reselling, when the device could not be confirmed as encrypted, or when a customer contract requires it. Destroy applies when neither can be verified, which in practice means hardware failure.
One detail that catches people out: on a device where encryption was never enabled, a factory reset is not equivalent to Clear. If you cannot evidence that encryption was active, treat the unit as needing Purge.
Running the four steps in the wrong order produces four distinct failure modes, and each has a different price.
All four are process failures rather than technology failures, which is why the fix is a checklist and a record rather than another tool.
This is what the returns bench should be able to answer for every unit, with the answer recorded against the serial number.
Point 5 is the one worth insisting on even under time pressure. A device that cannot complete a clean activation is not a graded asset; it is an unresolved incident. Shipping it moves the problem to the buyer.
The four-step chain is not difficult, but it is long enough that it will be skipped on a busy week unless the system forces the order. Two properties matter when evaluating tooling:
LuckyMDM is built around that: enrolment state, activation lock status, last check-in and command history sit on the same record as the asset, so offboarding runs from a screen rather than from four separate consoles. As always, the specific capabilities available depend on brand, model, OS version, enrolment route and network conditions - confirm against the compatibility list and your own bench test.
Only if the device was encrypted at rest, which discards the keys and makes the data unrecoverable - the Clear outcome under NIST 800-88. If encryption cannot be evidenced, a reset alone is not sufficient, and the unit should be treated as needing Purge. It is also not enough on its own for resale: activation lock and MDM enrolment survive a reset by design.
No, and over-applying it costs real money. Purge generally means the device will not be remarketed, which writes off the residual value. The default for a functioning unit going back into circulation is Clear; reserve Purge for retirement, for devices where encryption is unverified, or where a contract requires it.
Quarantine them as incidents, not as stock. Most failures trace back to a serial number that was never released or an activation lock that was never cleared - both recoverable with the right records. Units that cannot be recovered after escalation belong in the Destroy path, and the write-off belongs in the residual value model rather than being absorbed silently.
Two places. Residual value assumptions should be set from achieved resale prices on units that passed the full chain, not from list prices on the secondary market - the difference between the two is usually the cost of offboarding shortcuts. And phantom inventory should be reconciled monthly: devices still showing as enrolled after they left are both a reporting error and a support liability.
Yes, with more variation. Android Enterprise provides equivalent unenrolment paths and Factory Reset Protection plays the role of activation lock, but the exact steps and the server-side controls differ by OEM and management mode. Write the checklist per device family rather than once for the whole fleet.