What Is Actually Recoverable in 2026: The Honest Truth Matrix

🔒 This article is maintained by PhoneRepair.biz's automated research assistant and checked against public sources. Last reviewed: 2026-07-01. Spotted a mistake? Report an error on the talk page — or just edit the article. Suggestions from readers are reviewed before going live.

This article is an honest, vendor-neutral reference for what data can and cannot realistically be recovered from modern smartphones as of mid-2026. It exists because the single most common failure in this trade is not a bad soldering job — it is quoting a customer a recovery that the device's cryptography made impossible before it ever reached the bench. The short version: for a healthy pre-2016 device you can still do almost anything; for a locked, powered-off modern iPhone or Android with a strong passcode, the honest answer is often "nothing." What sits between those two poles depends almost entirely on device state (BFU vs AFU), who owns the device, and whether the encryption keys are reachable — not on how good your microscope is.

Overview

Three variables decide recoverability on any modern device. Learn to ask them in this order before quoting any job:

State — BFU vs AFU. Before First Unlock (BFU) means the device has been powered on but not unlocked even once since boot; the user-data encryption keys are not in memory. After First Unlock (AFU) means the device was unlocked at least once since boot and keys are resident in RAM. AFU is dramatically more recoverable than BFU — often the difference between a near-full file system and almost nothing.
Encryption. Practically every phone shipped with Android 10+ or any modern iPhone uses hardware-bound encryption (FBE on Android, class-key/SEP encryption on iOS). The keys are derived from the user passcode and a hardware key fused into the SoC/SEP that cannot be extracted. No passcode (or no key in RAM) = no plaintext, regardless of method.
Ownership and authorization. Whether you can lawfully attempt recovery, and whether you have the passcode or the owner's Apple/Google credentials, changes the entire matrix. This reference assumes you have authorization and are helping the rightful owner recover their own data. Anti-theft locks (FRP, Activation Lock) are out of scope — defeating them on a device you do not own is not data recovery.

A hard truth that trips up newcomers: chip-off is no longer a decryption shortcut. On any FBE/FDE device, desoldering the eMMC/UFS and reading raw NAND yields ciphertext. Because the master key lives in the CPU/TEE (or SEP), the removed chip is undecryptable without that original silicon and the passcode. Chip-off in 2026 is for physically destroyed boards and legacy/unencrypted devices — not for bypassing a lock screen.

The honest recoverability matrix

Read every cell as "with owner authorization, best realistic outcome." "Varies" means it genuinely depends on model, chipset firmware revision, and OS patch level — verify against current tool support lists and boardview/service docs rather than assuming.

Scenario	Realistic outcome	Why / method	Honest limitation
Modern iPhone, AFU, passcode known	Full — iTunes/Finder backup, or direct sync	Owner unlocks; standard backup extracts messages, photos, app data	Some items (Keychain, Health, Messages in iCloud) need backup encryption enabled or iCloud
Modern iPhone, AFU, passcode unknown	Partial → full only via authorized forensic service	Commercial AFU tools (e.g. Cellebrite Advanced Unlocks) can hold AFU state and pull FFS on supported models	Vendor-gated, law-enforcement/lab only; support lags newest iOS; not a consumer path
Modern iPhone, BFU (powered off / rebooted)	Minimal — metadata only, or nothing	Keys not in RAM; only "no-protection" class items and some logs accessible	User files/messages/photos remain encrypted and unrecoverable without passcode
iPhone, Lockdown Mode enabled	As BFU or worse	No publicly confirmed bypass on current hardware	Treat user data as unrecoverable without passcode
Android FBE (Android 10+), AFU, screen-lock known	Full — ADB/backup or logical extraction	Owner authenticates; credential-encrypted storage is unlocked	Knox Vault / Secure Folder / StrongBox items may stay sealed
Android FBE, AFU, lock unknown	Varies — often partial	Vulnerable-chipset EDL/Firehose or BROM exploit may image partitions while keys are live	Authenticated Firehose / disabled diag on newer SoCs blocks this; frequently impossible
Android FBE, BFU	Minimal/none of user data	Only Device-Encrypted (DE) storage accessible; Credential-Encrypted (CE) storage sealed	Messages, photos, app data unrecoverable without passcode/PIN
Pre-2016 unencrypted / FDE with known password	Full, including chip-off	eMMC/UFS raw read decrypts with known key, or is already plaintext	Only applies to old/budget hardware; vanishingly rare in 2026
Water/impact damage, chip intact, was unencrypted or key known	High via ISP/chip-off	Board-level repair to boot, or ISP pads / chip-off + NAND reader	If encrypted and passcode/keys lost, raw dump is ciphertext = unrecoverable
Physical destruction + modern encryption + lost passcode	None	Nothing to derive the key from	Permanent. This is the case customers refuse to accept — say so up front
"Deleted" files on encrypted device you can unlock	Low–moderate	TRIM/wear-leveling + FBE make undelete unreliable; SQLite WAL/journal carving sometimes recovers fragments	No guarantees; do not promise deleted-photo recovery on flash storage

Method reference: what each technique actually buys you

Method	Best for	Gets you past encryption?	Notes
Logical / backup extraction	Any device you can unlock	N/A (you have the key)	Fastest, safest, non-destructive; always try first when authorized and unlocked
ISP (In-System Programming)	Booting-but-locked repair; damaged boards; reading eMMC/UFS in place	No	Solder to test points to read/write flash without removing it; still ciphertext if encrypted & no key. Test points vary by model — verify against boardview/service docs
JTAG	Legacy CPUs, some feature phones	No (on encrypted devices)	Largely superseded by ISP and exploits; slow, model-specific TAPs
Chip-off (eMMC/UFS)	Physically destroyed boards; legacy/unencrypted devices	No on modern FBE/FDE	Destructive; on encrypted flash yields undecryptable ciphertext. Not a lock bypass
EDL / Firehose (Qualcomm)	Imaging supported Qualcomm devices	Only if keys are live (AFU) or device unencrypted	Reduced by authenticated Firehose signing and disabled diag on newer SoCs; see bkerler/edl
BROM / Download Mode (MediaTek)	Supported MTK devices	Only if keys are live or unencrypted	See mtkclient; increasingly locked down on recent MT SoCs
Commercial forensic (Cellebrite / GrayKey / MSAB)	Authorized lab/LE AFU access on supported models	Sometimes, on supported models/OS	Vendor-gated, licensed, and lags newest OS; passcode bypass on current iOS is publicly listed "in research"

What is permanently unrecoverable

Be blunt with customers about these. No tool, lab, or amount of money changes them:

Modern encrypted user data with a lost passcode and no key in RAM (BFU). The passcode-derived key plus the fused hardware key are both required; the hardware key is non-extractable by design. iOS wipes/locks the key after too many wrong attempts, and the Secure Enclave deliberately rate-limits every guess.
Anything behind SEP once the device is in BFU and the passcode is unknown — including via chip-off, which returns ciphertext.
Knox Vault / Secure Folder / StrongBox-sealed material without the user's credential.
Genuinely overwritten flash — wear-leveling means you rarely get true overwrites back, and FBE makes carving deleted user files unreliable even when you can unlock.

Two distinctions worth memorizing, because they are constantly conflated:

FRP / Activation Lock ≠ encryption. These are anti-theft account locks. Removing them does not decrypt data, and most FRP "bypass" procedures — like unlocking a bootloader — wipe the device. There is no legitimate FRP-bypass path that recovers a stranger's data; treat such requests as out of scope.
Inactivity reboot. Since iOS 18.1, an idle locked iPhone auto-reboots (~72 h) back to BFU, and modern Android behaves similarly on power loss. A device that arrives powered-off has almost certainly dropped its keys. Preserve state: keep AFU devices powered and charged, do not reboot, and isolate from networks — losing AFU can turn a recoverable job into an impossible one.

How to use this reference

Triage before you quote. Ask: iPhone or Android? Powered on and unlocked since boot (AFU) or off/rebooted (BFU)? Does the owner have the passcode and Apple/Google credentials? Only then estimate feasibility.
Prove authorization. Confirm the requester is the rightful owner or has documented authority. If the ask is really an anti-theft-lock bypass, decline.
Preserve state first, always. If the device is AFU and you might need forensic help, keep it powered, charged, off networks, and do not reboot it. State is perishable.
Exhaust the non-destructive path. Unlock + backup/logical extraction whenever possible. Escalate to ISP only for boot/read problems, and reserve chip-off for physically destroyed boards or confirmed legacy/unencrypted devices.
Verify support, never assume. Chipset exploit availability, test-point maps, and forensic-tool coverage change per model and firmware revision. Check current tool docs and boardview/service documentation for the exact model — do not rely on a coordinate you half-remember.
Set expectations in writing. If the matrix says "minimal/none," tell the customer that before they pay, not after.

Sources

PhoneRepair.biz is a free community knowledge base. Data recovery and board-level repair carry a real risk of permanent data loss — when the data matters, back up any raw dump before modifying a device and consider a professional lab. Only work on devices you own or have documented authorization to service. See PhoneRepair:Legal notice.