← Back to the catalog

Phone or Tablet Data Loss

Data loss on a phone or tablet doesn't play by the same rules as a PC, mostly because of two things most current smartphones and tablets do that a typical computer doesn't: encrypting all storage by default, and soldering the flash memory directly onto the board.

Recovery decision

Mobile data loss: what should you do next?

Answer one question about the current state. The result suggests the safer next step rather than diagnosing the failure.

Typical source stabilityDevice-dependent

Default action riskHigh

Default first actionPreserve device state

Check my situation

This guide classifies the next recovery action from observable information. It does not diagnose hardware condition or estimate a percentage chance of recovery.

What's actually happening

Modern iOS and Android devices normally use hardware-backed storage encryption, with keys tied to the device and often protected by the user credential. As a result, simply reading or transplanting flash storage from a damaged modern phone usually does not produce usable plaintext, even when the memory itself is intact. This is the opposite of most scenarios in this catalog: the barrier is usually not damage to the data, it's access to a device that can decrypt it.

How recoverable this really is

Strongly depends on what the actual failure is. A cracked screen or a dead charging port, where the device otherwise still functions internally, is often the most recoverable version of this — connecting the device to a computer, or repairing just the broken component, can restore full normal access. A device that won't boot at all, or that's been physically destroyed, is a much harder problem specifically because of the encryption point above: raw flash or UFS access is not equivalent to plaintext recovery. On modern encrypted devices, usable decryption can depend on both the user's credential and device-specific secure hardware or key state, so a storage dump plus the passcode may still be insufficient.

Record the exact model, passcode availability, account credentials, whether the device still powers on, whether it is recognized by a trusted computer, and what happened immediately before the loss. Preserve existing trusted computers and authentication devices: they may contain pairing records, local backups or active sessions. Avoid factory reset, firmware restore, bootloader unlocking and repeated repair attempts unless their data consequences are understood.

What you can establish safely

Cloud synchronization also changes the problem. Photos, contacts, messages or application data may have replicas or backups outside the device even when the handset itself is inaccessible, while some application data may exist only inside an encrypted application container.

What changes recoverability

Modern phones and tablets combine flash storage with device-specific encryption and secure key handling. That makes the device's current ability to boot, unlock and decrypt data more important than raw access to the memory chips. A broken screen with an otherwise functioning, unlockable phone is therefore a very different case from a dead mainboard, a factory-reset device or deleted data on a healthy encrypted phone.

The general approach

Where the device still functions, prioritize non-destructive restoration of normal user-level access — for example an alternative display path, charging or data connection, or board-level repair that preserves the original secure hardware. Do not present firmware restore or recovery-mode procedures as generic data-access steps: a recovery or restore mode is not automatically a data-access mode, and even the correct passcode does not necessarily unlock every Data Protection, File-Based Encryption or application key class at once. Where the device doesn't function at all, options are genuinely more limited and device-specific, and usually depend more on whether recent backups exist — a manufacturer cloud backup, or a computer the device was previously synced to — than on any recovery technique applied to the device itself.

Modern phone recovery is key-dependent, not flash-dependent

Reading raw NAND or UFS storage off a modern phone preserves every encrypted byte, but that's not the same thing as recovering plaintext. Both iOS Data Protection and Android's File-Based Encryption tie the actual decryption keys to the device's own hardware and the user's credential, so physical possession of the flash contents doesn't by itself grant possession of the data inside it — see iPhone Data Protection and Secure Enclave recovery and Android FBE, Keystore and hardware-bound recovery.

The original board can matter more than the storage chip

Because key material is bound to the device's own security hardware — the Secure Enclave on iPhone, a hardware root of trust on Android — replacing a damaged logic board with a working one does not transfer the original phone's ability to decrypt its own data. For a device that needs data recovered rather than just working again, preserving the original board can matter more than restoring the device to normal service.

A reboot can change what's currently accessible

A phone that's running and has been unlocked since it last booted can be in a different, more favorable cryptographic state than the same phone after a restart. This is a reason to avoid unnecessary power cycles on a device that still needs data preserved from it, not a reason to try to manipulate that state directly.

Factory reset destroys keys, not just files

On modern encrypted devices, a factory reset can render previous user data cryptographically inaccessible by destroying or replacing required key material, without necessarily overwriting every storage cell. Exact behavior varies by platform and generation: Apple documents that an erase operation destroys or replaces key material so that previous files become cryptographically inaccessible, and Android implementations vary by generation and encryption architecture. Treat a reset as a destructive, one-way action, not a reversible troubleshooting step.

Cloud, backup and another device are separate recovery sources

A cloud sync service, a dedicated cloud backup, a computer the phone was previously connected to, and another device signed into the same account can each hold a different, incomplete subset of the missing data — none of them is a guaranteed superset of what was on the phone. Inventory each of them separately before assuming the phone itself is the only remaining copy.

Application encryption can add another layer on top

Even after a phone's own storage encryption is dealt with, individual apps — password managers, secure messengers, crypto wallets — can protect their own data with a separate key held in Keychain or Android Keystore. Recovering an app's files intact doesn't guarantee that key is also available.

The encryption boundary here is the same reason ordinary storage recovery cannot simply bypass a missing credential; see Locked Out of an Encrypted Volume. For storage that is removable rather than hardware-bound to a phone, see Memory Card Not Recognized or Asks to Be Formatted or, once the card itself is stable, Corrupted or Deleted Video from a Memory Card. A lost or damaged phone with a cryptocurrency wallet installed usually turns into a wallet-recovery question rather than a phone-recovery one once the app's own state is the goal; see Cryptocurrency Wallet Recovery and Recovering Encrypted Wallet Files and Keystores. For the board-level repair question specifically, see mobile device recovery state and board-level preservation, and for what other tools this involves, mobile device and cloud recovery tools.