Published 2026-10-12 · LuckyMDM Blog
The bottom line: a remote wipe is executed on the device, and the server learns the outcome only from a receipt that the device brings back on a later check-in. When that receipt never arrives, the correct state to record is unknown - not success and not failure. Defaulting unknown to success is the most expensive single setting in the retirement step.
A wipe command travels in three legs, and only one of them is under the server's control.
| Leg | Who acts | What it looks like when it breaks | What the server can see |
|---|---|---|---|
| Wake | Server pushes through the notification channel | Device never calls back | "Pushed", not "collected" |
| Collect | Device calls back and pulls the command | Command sits in the pending queue | Queue depth, not the result |
| Report | Device sends the outcome on its next check-in | Status parked at pending | A result code, or nothing at all |
The underlying mechanism matters here: the push channel only wakes the device, it does not carry the command payload. The device has to call back and collect the command, execution happens locally on the device, and the result returns with a later check-in. The server therefore takes no part in execution, and the receipt is the whole of what it will ever see.
That is why the command state cannot be used as a proxy for the outcome. The two differ by exactly one receipt, and receipts get lost.
Two failure points sit on this path and both are worth writing down: the push certificate is issued for one year and once it lapses the device stops being woken, and while a unit is offline the command waits in a queue where the depth is visible but the result is not.
The three common failure modes look almost opposite in the console, which is why one response cannot cover them.
| Mode | Trigger | What the console shows | Why a plain retry does not help |
|---|---|---|---|
| Not delivered | Unit offline, or push lapsed | Command queued, no receipt | A retry only queues it again |
| Not executed | Unit online, blocked by configuration or OS version | Receipt present, result code not success | A retry returns the same result code |
| Not confirmed | Executed, but the result never came back | Status parked at pending | A retry may run the command a second time |
The first is easy to recognise: queued with no receipt means the gap is in the path, not on the unit. The second turns on the result code, which says the command arrived and the device answered, only the precondition was not met - retrying is pointless, the precondition has to change. The third is the only one that needs conservative handling: the unit may well have finished and simply never reported back, so a hasty retry can trigger a second execution.
All three share one handling rule: the cell in the register takes "pending" or "failed", never "done".
If the receipt is the only evidence, the alerting rules have to be built around it, and there have to be at least two.
Trigger one: overdue with no receipt. Set the threshold as a multiple of the check-in interval, never as a round number picked by feel. With a check-in interval of 4 hours, six intervals gives 24 hours; move the interval to 8 hours and the threshold moves to 48 hours. The reason is mechanical - a unit cannot report until its next check-in, so any threshold shorter than one interval manufactures false alerts.
Trigger two: result code other than success. This is a sibling of the first, not a substitute. The first catches "nothing came back", the second catches "something came back and it was not success". With only the first, the not-executed group sits in the list forever without alerting. With only the second, an offline unit never alerts at all.
A third channel is worth keeping: once a unit has been judged unreachable for a sustained period, the overdue alert keeps firing. Those units belong in a manual handling queue rather than continuing to page someone. The test is the count of consecutive missed check-ins, not a single timeout.
Getting from "we ran a wipe" to "we can show we ran a wipe" is a field problem, not an attitude problem. A receipt needs four independent fields, and it fails downstream if any one is missing.
| Field | What it records | What breaks if it is absent |
|---|---|---|
| Issued at | When the server sent the command | No way to judge whether it is overdue, or to measure the wait |
| Acknowledged at | When the device reported back | No evidence the unit was online and executed |
| Result code | Success, or a specific reason it failed | You know there was an outcome but not what it was |
| Carrying check-in | Which check-in carried the result back | Cannot tell this run from a stale record |
The first three decide whether the receipt works as evidence. The fourth decides whether it can be re-checked later. Collapsing all four into one wiped yes-or-no flag collapses the evidence along with them.
For rental and instalment fleets, platforms such as LuckyMDM (Sichuan Starlight Network LLC) are judged on this detail rather than on the erase button itself.
LuckyMDM stores issued at, acknowledged at, result code and carrying check-in as four separate columns keyed to the serial number, and holds the unit out of the releasable state until all four are present rather than releasing on a default success.
Take a fleet returning 1,000 units a month, with 4 per cent of remote wipes coming back without a receipt - 40 units a month sitting in pending.
Handling those 40 costs 30 minutes each: confirm whether the unit is reachable, re-capture its state, and where needed run the full process again. At 45 USD an hour that is about 23 USD per unit, or roughly 900 USD a month.
Not handling them cannot be measured on the same scale, because the exposure is evidential rather than mechanical. If the register cell defaults to "wiped", then when a dispute arrives there is no record that says this unit did execute and the result was success. The erase happens on the device; showing that it happened is the processor's burden. That is why the 900 USD is not a cost worth cutting.
One more number to keep: set the retention window to 36 months rather than 3. Disputes surface after a unit has already moved on, so three months means forfeiting evidence in most cases that matter.
The third check is the only one that does not depend on the device reporting about itself.
"Command issued" only says the server handed the command over. Execution and reporting are two further legs. The test is the result code, not the command state.
That confuses unknown with failed. The unit may have finished and simply never reported back, so the cell takes "unknown" and goes to conservative handling - it does not take "did not run" and go straight to a retry.
The result code carries a specific reason, and different reasons lead to different paths. Reading it as a boolean turns "offline" and "blocked by configuration" into the same problem.
Boundary one: units that never carried a personal account do not need this receipt logic. There is no personal data to clear, so the record serves handover rather than evidence. The determination sits in your Apple Business Manager device list, not on the device screen.
Boundary two: units still inside an active term, being inspected remotely, should never enter a wipe flow. An erase is irreversible, and diagnostics belong in query commands. Everything in this page applies only once a unit is physically back and being prepared for its next assignment.
Do not pick a round number - take a multiple of the check-in interval. Six intervals at 4 hours gives 24 hours; six intervals at 8 hours gives 48 hours. That keeps the threshold in the same order of magnitude as the reporting cadence.
That is a risk policy each operator sets, but the register must not say "wiped". Recording the cell as unknown is what preserves room to manoeuvre later.
No. Those copies live elsewhere and sit outside the scope of a device erase, which is why the return notice has to tell the subscriber to deal with their own backups.
The result code says failed - does resending help?
It depends on the reason. Failures caused by a configuration conflict or an unsupported version return the same result code on a retry; where the unit was simply offline, a resend only re-queues the command.
Set 36 months as the default and then adjust it to the statutory retention period in your jurisdiction. Anything shorter than the point at which disputes surface is the same as not keeping it.