What happens when a phone holding keys is lost?

Whether a lost phone exposes anything depends first on storage encryption and on the state the phone is in.

On iPhone, Apple’s Data Protection assigns every file a class. For the Complete Protection class, the decrypted class key is discarded shortly after the device locks, so that data is unreadable until someone enters the passcode or uses Face ID or Touch ID. The default class for third-party app data, Protected Until First User Authentication, keeps its key in memory once the user has authenticated after a restart, even while the phone is locked. Apple says this class protects data from attacks that involve a reboot. Android’s file-based encryption has a similar split between storage available only after the user has entered their credentials and storage available before.

Keys themselves can be harder to take than files. The Android Keystore system keeps key material out of the app’s process, and can bind it to secure hardware such as a Trusted Execution Environment or Secure Element. An attacker who controls the app might be able to use such a key on the device but cannot copy it off. RFC 9750, the MLS architecture document, recommends exactly this for signature private keys: keep them apart from other secrets, preferably in dedicated hardware, so authentication can be recovered after a compromise.

So a locked, encrypted phone with hardware-held keys gives a finder little, while an unlocked phone, or an app that keeps decrypted messages in weakly protected storage, can give a lot. See encryption at rest vs in transit for how storage encryption works.

Apple and Google both let an owner erase a lost device from elsewhere. Apple’s platform security guide says iPhone and iPad can be erased remotely by an administrator or user, rendering all data unreadable, and that the device acknowledges the command before performing the wipe.

The catch is connectivity. Apple’s iCloud guide says that if the device is offline, the erase begins the next time it is online. Google’s Android help lists what a device needs before it can be secured or erased: power, a mobile data or Wi-Fi connection, a signed-in Google Account, Find Hub turned on and visibility on Google Play. A phone that has been switched off or kept away from any network will not receive the command.

Remote wipe is a good step, but it cannot be the only one. Design as if the device’s keys may already have been copied.

In MLS, membership is managed per client, and RFC 9750 says a client usually corresponds to one device. A person with a phone and a tablet is two members of each group, each with its own keys. That is what makes a lost phone manageable: the phone’s keys can be cut out without touching the tablet’s, and the person stays in the conversation.

The same reasoning applies outside MLS. When each device has its own key pair, losing one device means revoking one key, not replacing a person’s identity everywhere.

The cryptographic response has two parts.

• Remove it from every group. A member of each group sends a Remove for the lost device’s leaf, carried in a Commit. RFC 9750 says that as long as the other members are honest, MLS guarantees message secrecy for all messages in the epochs after the compromised party has been removed. This is the post-compromise security route that works even if the attacker holds the phone’s current group secrets.
• Invalidate its signing credential. If the device’s signature key may have leaked, RFC 9750 says the old credentials must be invalidated before an attacker can no longer authenticate messages as that device. It also recommends that, where the credential type supports revocation, group members check for revoked keys.

Then account for devices that cannot hear about it yet. A verifier that is offline only knows what it last received. The Offline Protocol security documentation states this directly: an offline verifier cannot learn a new central revocation until it receives updated information, and asks applications to define credential expiry and revocation behaviour for disconnected periods. Short credential lifetimes are one way to bound how long a revoked device can still be accepted.

Messages already sent to the lost phone were readable by it, and nothing done afterwards changes that. Forward secrecy protects older messages only if the phone had already deleted the keys for them, and RFC 9750 notes that apps often keep decrypted messages on the device anyway. Its recommendation is to protect stored messages with encryption at rest, and to delete them as soon as practical if the threat model includes someone reading the device directly.

On the owner’s side, a replacement phone starts fresh. RFC 9750 says a new device joins as a new client and does not gain access to history. A device that lost its state can rejoin as a new member and remove the member that represented its old state, but it still does not get the messages exchanged while it was gone.