O3.07.1Remote device containmentdesignresearch

Remote locking and wiping need to be available

Aliases: remote lock · remote wipe · lost-device containment

What it is

Remote device containment lets an account owner use another trusted entry point to mark a device lost, lock it, revoke credentials, and—when conditions permit—delete sensitive local data. Locking rapidly stops use, while wiping reduces stored exposure. Neither substitutes for the other, and a requested command is not proof of delivery.

Why it happens

A lost device can retain authenticated sessions, notifications, offline files, and exportable keys. Remote commands queue through an account service and execute after the device reconnects and validates them; power-off, isolation, or modified software can delay or prevent execution. Strong default encryption with lock-protected keys reduces the theft window, while remote containment adds revocation and visible response.

Studying it

Use dedicated test devices to simulate locked, offline, SIM-changed, factory-reset, reconnected, and racing-command states. Measure report, server revocation, delivery, lock, and erase separately, then inspect notifications, offline data, sessions, and backups. Show users the difference among requested, delivered, and executed. A success checkmark on a web page does not prove device state.

Where it stops holding

Remote wipe cannot retrieve copied data and can conflict with shared ownership, forensics, employment boundaries, or preservation duties. Personal-device management must not permit arbitrary destruction of private areas; an enterprise container can erase work data only. A device may never reconnect, so local encryption, short sessions, and minimal offline data remain foundational. Confirm scope before irreversible erase and provide a short cancellation window where the platform permits; completed erase is usually not reversible, and restoring a backup does not undo it.

Applying it

  • Provide a “mark lost” route that does not require the missing device. Distinguish login and payment tokens from device-management trust for the specific platform, validate revocation order, and retain only the restricted management channel needed for containment until command receipt or an alternative control.
  • Separate device lock, account-credential revocation, workspace erase, and full-device erase by target, consequence, and reversibility.
  • Record request, authentication, delivery, execution, and failure states for each command and notify the owner through a safe channel.
  • Enable hardware-protected storage encryption by default and rehearse offline reconnection and conflicting commands, validating data scope rather than an API response.

Related

  • Same group: O3.07.2 Pre-unlock exposure · O3.07.3 Loss-recovery attack surface
  • Adjacent: O3.02.3 Authenticator-loss readiness · O3.17 Screen exposure
  • Search terms: remote device lock · remote wipe assurance · lost-device containment

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O3.07.1