BFU vs AFU: What You Can Actually Recover From a Locked iPhone

🔒 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.

When a locked iPhone lands on your bench for data recovery, the single most important question is not "what model is it?" or "is the screen working?" — it is "has this phone been unlocked at least once since it last booted?" That one fact, captured by the terms BFU (Before First Unlock) and AFU (After First Unlock), largely decides whether you are looking at a rich extraction or at a pile of ciphertext. This article explains what the two states actually mean at the silicon level, what realistically comes off a device in each state, and — just as importantly — what is permanently gone no matter what tools you own.

The short answer

BFU (Before First Unlock) — the device has powered on or rebooted and nobody has entered the correct passcode since. The passcode-derived encryption keys are not in memory, so the Secure Enclave keeps almost all user data locked. You can typically get system files, some caches, the Wi-Fi list, a little Wallet/notification data and a limited slice of media/metadata — and, on very old vulnerable hardware, a partial keychain. Messages, photos, mail and most app data are cryptographically unavailable.
AFU (After First Unlock) — the passcode has been entered at least once since boot, so the keys are loaded in RAM. Even if the screen is locked again, most data-protection keys are available and a compatible tool can pull the large majority of the file system — often cited as roughly 90–95%.
BFU and AFU describe the encryption state since boot, NOT whether the screen is currently locked. A phone sitting on your bench with the screen off can be in either state.
Without the passcode, there is no supported way to brute-force or "decrypt" a modern (A12/2018-and-later) iPhone. Chip-off and ISP give you only encrypted bytes. Be honest with the customer about this before you take the job.

Background

Modern iPhones use file-based Data Protection'. Every protected file is encrypted with its own key; those per-file keys are wrapped by class keys, and the class keys are themselves protected by a key that is derived from the user passcode entangled with the hardware UID key fused into the Secure Enclave (SEP) during manufacture.

The consequence is the whole reason BFU/AFU exists:

The passcode key cannot be computed off-device, because it requires the per-device UID key that never leaves the AES engine inside the SEP — not even sepOS software can read it.
When the phone boots cold, that passcode key does not exist in memory yet. Any file in a class that needs it stays sealed. That is BFU.
The first time the correct passcode is entered, the SEP derives and releases the class keys into RAM. From then until the next reboot, those keys are available. That is AFU.

Apple's Data Protection classes are the mechanism underneath the jargon:

Class	Name	Available in BFU?	Typical contents
A	Complete Protection	No (evicted shortly after lock)	The most sensitive keychain items / apps that opt in
B	Protected Unless Open	Partially	Files that can be written while locked (e.g. mail attachments arriving)
C	Protected Until First User Authentication	No — this is the big one	The default class for most user data; available only AFU
D	No Protection	Yes	Files usable before first unlock (some system data)

Because Class C ("Protected Until First User Authentication") is the default, the overwhelming majority of user content is exactly the data that only unlocks in AFU. That is why BFU feels so empty and AFU feels so full.

The Android world uses different words for the same idea: File-Based Encryption (FBE) with Device Encrypted (DE) storage (readable in Direct Boot / BFU) and Credential Encrypted (CE) storage (readable only AFU). Older devices used Full-Disk Encryption (FDE). The BFU/AFU distinction applies across both platforms; see Android FBE vs FDE Encryption Explained.

How it works

What puts a phone into BFU:

A power-off and cold boot.
A reboot (crash, forced restart, or a tool-triggered restart).
iOS 18 "inactivity reboot" — introduced in iOS 18.0 (Sept 2024) with a 7-day timer and tightened to 72 hours in iOS 18.1 (Oct 2024). If the phone is not unlocked for that window, the SEP itself triggers a reboot back to BFU. It cannot be defeated by airplane mode, a Faraday bag, or keeping the device on the charger, because the countdown lives in the Secure Enclave.

What a tool can actually do in each state:

BFU acquisition relies on reading only the data that is not sealed by a passcode-derived class key, plus whatever a low-level exploit can reach. On checkm8-vulnerable hardware (A11 / iPhone X and older) a bootrom-level agent (e.g. the checkra1n line of tooling) can mount the file system and copy what is decryptable, including — on some iOS versions — a partial keychain. checkm8 does not touch the SEP and cannot recover the passcode or the Class C data.
AFU acquisition takes advantage of the class keys already sitting in RAM. A compatible agent walks the live file system and pulls files as their classes permit — which, AFU, is most of them.

The hard hardware wall:

A12 and later (2018+, iPhone XS onward) are not vulnerable to checkm8, and later SEP hardening blocks the older tricks even on some A11 units. On these devices, with an unknown passcode, there is no public, repeatable way to get a full file system.
The SEP enforces escalating delays and a guess counter, plus an ~80 ms key-derivation cost per attempt, so passcode guessing is throttled to the point of impracticality for any decent passcode. There is no brute-force support in mainstream forensic tools for current devices — knowing (or the owner providing) the passcode is the path to a full extraction.

For the Android/Qualcomm/MediaTek analogue — EDL (Emergency Download) mode, Firehose programmers, and tools like mtkclient — the same rule holds: exploits may let you read raw partitions, but if the user data is FBE/CE-encrypted with an unknown credential, you still hit ciphertext. See Qualcomm EDL Mode and Firehose Programmers and eMMC and UFS ISP Data Recovery.

What this means in practice

If a live, unlocked-since-boot (AFU) device reaches you, preserve that state. Losing AFU is the single most common way a recoverable job becomes unrecoverable.

Do not power it off and do not let it reboot. A reboot drops it to BFU.
Keep it charged and on a stable power source.
Prevent auto-lock timeouts from becoming a reboot risk; isolate it from the network (airplane/Faraday) to stop remote-wipe, but remember: network isolation does NOT stop the iOS 18 72-hour inactivity reboot. Treat the 72-hour clock as a hard deadline from the moment of last unlock.
Document the state (screen on/off, battery, iOS version) before doing anything.

If the device is already BFU, set expectations honestly:

On checkm8 hardware (iPhone X / A11 and earlier), a limited BFU triage is often possible.
On A12+ with an unknown passcode, expect very little — and no path to the encrypted bulk without the passcode.

Always ask for the passcode. In legitimate owner-authorized recovery, the customer knowing their passcode changes everything: it turns a dead BFU device into a full extraction. Confirm ownership and authorization in writing before any work — see Data Recovery Authorization and Chain of Custody.

What is and isn't recoverable

Data / scenario	BFU (unknown passcode)	AFU (unknown passcode)	Passcode known
System files, some logs/caches	Often yes	Yes	Yes
Wi-Fi list, some Wallet/notification data, limited location points	Sometimes	Yes	Yes
Partial keychain	Only on old vulnerable HW (checkra1n)	Partial–most	Yes
Messages, iMessage, call logs	No	Usually yes	Yes
Photos & videos (camera roll)	Limited/none	Usually yes	Yes
Mail, most third-party app data (Class C default)	No	Usually yes	Yes
Full file system (~90–95%)	No	On supported HW/agent	Yes
Data on A12+ with unknown passcode, BFU	Effectively unrecoverable

Permanently / practically unrecoverable — say so plainly:

Class C user data in BFU on a passcode-locked device — sealed until first unlock, full stop.
Anything on a modern (A12+) device when the passcode is unknown and the device is BFU.
Data after a remote or local wipe: erasing the effaceable-storage key destroys the wrapping key and renders the entire file system cryptographically dead. No chip-off recovers it.
Ciphertext from chip-off / ISP / EDL on an encrypted device is just that — encrypted bytes with no key. Physical access to the eMMC/UFS/NAND does not equal data access on an encrypted phone.

FRP is not the same problem. Factory Reset Protection / Activation Lock is an account/anti-theft lock, entirely separate from data encryption. On a device that has been wiped, there is no user data left to recover regardless of FRP state — removing an activation/anti-theft lock does not "unlock data," and defeating anti-theft protection on a device you do not own is out of scope here and often illegal. This article is strictly about owner-authorized data recovery.

Common misconceptions

"Chip-off / ISP always gets the data." False on any encrypted device (i.e. essentially all modern phones). You get the encrypted image; without the SEP/TEE-held keys it is useless. Chip-off remains valuable for unencrypted legacy devices, dead-boot logic-board work, and forensic imaging where the key is available.
"Locked screen means BFU." No. A phone can be screen-locked yet still AFU (keys in RAM). Conversely a phone with the screen on right after a reboot to the passcode prompt is BFU.
"Jailbreaking the phone breaks the encryption." No. checkm8/checkra1n give code execution, not the passcode. They let you read what is already decryptable in the current state; they do not defeat Data Protection or the SEP.
"A newer, more expensive tool can brute-force any iPhone." For current A12+ hardware with a strong unknown passcode, no mainstream tool offers practical brute force — the SEP throttling and guess counter are the wall.
"If I keep it in a Faraday bag it can't reboot to BFU." Isolation stops network events (remote wipe/lock), but the iOS 18 inactivity reboot is timed by the SEP locally and fires anyway. Mind the 72-hour clock.
"Removing FRP/Activation Lock recovers the data." No — it is an anti-theft account lock, unrelated to the encrypted user partition, and typically the data is already gone on a reset device.

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.