Remote wipe on an offline device waits for the next connection
Aliases: remote wipe · wipe latency · pending wipe
What it is
A remote wipe is a queued command: while the device is offline, the instruction sits on the server until the device next connects and pulls it. Between "command issued" and "data protected" stretches one device check-in — that window is the first fact on the loss timeline, and disposition design must be built around it rather than pretend it away.
Why it happens
The wipe command is fundamentally a push message; delivery depends on the device calling home (push channel or heartbeat), and no network can reach through to a device that is not online — physics, not an engineering shortfall. Data during the window is covered by a second line of defense: encryption at rest. With device encryption and a strong lock-screen credential, data stays unreadable through the offline window and the wipe is a formality; without it, the waiting period is open exposure. The wipe's correct role is therefore the deterministic endpoint of disposition, not the first line of protection — a loss flow that treats wiping as the primary defense fails exactly in the offline scenario where it is needed most.
Where it stops holding
No latency can be promised: the command may take minutes or never execute (the device never reconnects). "Wipe command sent" is reassurance for the user, not a protection state — the interface must distinguish "issued" from "executed" honestly. Enterprise devices with hardware-escrowed keys can achieve network-isolated erasure (destroy the key and the data dies), which most consumer devices lack; the capability gap must not be smoothed over in documentation.
Applying it
- Ship encryption at rest plus a strong lock credential as default; position remote wipe as the backstop, and make the first action in a loss flow account-side containment, not the wipe command.
- While the wipe is undeliverable, freeze the account-side exposure: sign out all sessions, revoke payment tokens, flag the device as lost — capping the window's worst case at hardware loss instead of data breach.
- Present two states, "issued" and "executed," with a timestamp and network type on execution.
- Verification: drill a wipe against a device in airplane mode and log the delivery delay plus the state of every defense during the window — that timeline is the acceptance test for the loss-response flow.