The first question is what state the phone was in

Everything that follows depends on whether the device was locked, unlocked, or taken by someone who knows the passcode. A locked phone with modern platform protections is a substantially different situation from an unlocked one handed over under duress.

Decide which case you are in before acting, because the right sequence differs — and one of the available actions is irreversible.

Use the platform's lost-device controls first

Both Apple and Google provide lost-device tooling that can locate a device, mark it as lost, display a message, and remotely erase it. Marking the device lost is generally safe and reversible; erasing it is neither.

Record the device's last known status when you mark it, since that information becomes relevant to both insurance and any later assessment of what was exposed.

The remote-erase decision

Remote erase reduces the chance of future access to the device's contents. It also ends any remaining possibility of recovering data that existed only on that phone.

If your vault content is covered by a tested backup held elsewhere, this decision is straightforward. If it is not, you are weighing exposure risk against permanent loss, and there is no answer that is correct for everyone. Make it deliberately rather than in the first ten minutes of panic.

Secure the accounts whose sessions lived on the phone

A stolen phone is rarely just a stolen phone. It is a set of logged-in sessions — mail, messaging, cloud storage, banking, and any service that trusted the device.

Change credentials for exposed accounts and revoke sessions rather than only changing the password, since an active session may survive a password change on some services. Prioritise accounts that can be used to reset others.

The order that limits damage

  • Mark the device lost through the platform's own tooling and record its last known status.
  • Change credentials on exposed accounts and revoke active sessions.
  • Weigh the remote-erase decision against any local-only data you have not backed up.
  • Restore onto a trusted replacement device from an independent, tested backup.
  • Rotate any secret that was reused between the phone and another system.

Scams that target this exact moment

People who have just lost a phone are a known target. Messages claiming to have found the device, and asking you to sign in to confirm ownership, are a common credential-phishing pattern.

  • Posting the device identifier or your contact details publicly.
  • Entering account credentials into any link that arrives claiming to have found the phone.
  • Assuming a recovery phrase contains your files — it authorises recovery, it does not store content.

What this reveals about the backup you had

A theft is an unplanned restore test. Whatever you can recover now is the true measure of the backup arrangement you had, rather than the one you intended to have.

Once the immediate response is finished, it is worth writing down honestly what was recoverable and what was not, and fixing the gap while the memory is fresh.

A fictional example

Eli starts with a non-sensitive test: “Mark the device lost and record its last known status.” Next, Eli follows the second check: “Change exposed account credentials and revoke suspicious sessions.” This fictional scenario demonstrates the decision process; it is not a report of product testing.

Common mistakes

  • Posting the device identifier publicly
  • Entering credentials into messages claiming to find the phone
  • Assuming a recovery phrase contains local files

What this workflow does not change

  • Posting the device identifier publicly
  • Entering credentials into messages claiming to find the phone
  • Assuming a recovery phrase contains local files

Questions people ask

Should I erase immediately?

It depends on exposure and recovery. Understand what local-only data will become unreachable first.

Do exported backups get erased too?

No. A local panic action or remote device erase does not remove independently stored exported backups.

Sources and further reading