Understanding BFU and AFU in iPhone Forensics and Encryption
Knowledge
2025-05-12
Apple’s iPhone is widely regarded as one of the most secure consumer devices on the market. For digital forensics professionals, this strong security poses unique challenges—especially when dealing with the iPhone’s two key encryption states: Before First Unlock (BFU) and After First Unlock (AFU).
These states determine how much data is accessible based on whether the user has unlocked the device since the last reboot. The transition from BFU to AFU is controlled by a combination of hardware-based encryption, data protection classes, and the Secure Enclave Processor (SEP)—a dedicated chip responsible for handling sensitive operations like passcode verification and key management.
Apple’s security framework is built on a combination of hardware-enforced encryption and fine-grained access controls. This architecture protects user data even if the device is lost or seized. To understand how data accessibility varies between BFU and AFU states, it’s essential to examine three core components: the Secure Enclave, file-based encryption, and data protection classes.
Secure Enclave Processor (SEP)
The Secure Enclave is a dedicated coprocessor within Apple’s system-on-chip, responsible for handling sensitive operations such as passcode processing, Touch ID / Face ID verification, and key management. It runs a separate microkernel-based operating system and is isolated from the main processor. According to the Apple Platform Security Guide, this isolation ensures that “compromise of the main operating system does not compromise sensitive operations handled by the Secure Enclave.”
Crucially, the Secure Enclave controls access to the keybag, which stores file class keys. In the BFU (Before First Unlock) state, the SEP refuses to unlock these keys without valid user authentication.
File-Based Encryption (FBE)
Apple devices running iOS and iPadOS use file-based encryption, where each file is encrypted with a unique per-file key. These file keys are wrapped with a class key, which is itself encrypted using a combination of the device’s hardware UID key and the user’s passcode. This allows iOS to enforce per-file access policies based on the user’s interaction with the device.
Apple documents this approach in its File System Security section, explaining how encryption is tied to both hardware and user context.
These protection levels are enforced by the SEP and directly affect whether a file is accessible in AFU or BFU states.
Keybag and Keychain
The keybag is a data structure that stores encryption class keys, which are protected using the device’s UID (Unique ID) and the user’s passcode. The keys inside the keybag are used to decrypt files according to their data protection class. Unless the SEP unlocks the keybag—typically after the first user unlock—most user data remains inaccessible.
The Keychain is used to store sensitive credentials such as passwords, certificates, and tokens. According to Apple’s documentation on Keybags and Keychain, access to Keychain items is also governed by data protection classes and often restricted to the AFU state.
AFU and BFU Explained
Apple’s iOS devices operate in two key security states that directly impact data accessibility: Before First Unlock (BFU) and After First Unlock (AFU). These states are determined by whether the user has entered a valid passcode after the last device boot. Understanding the difference between them is critical for assessing what data is available during forensic acquisition.
What Is BFU (Before First Unlock)?
The BFU state occurs immediately after a device powers on or reboots and before the user has entered their passcode. In this state, most encryption keys stored in the keybag remain locked by the Secure Enclave. As a result, access to user data is severely restricted. Even if the device is powered on and responsive, most personal files, app data, and Keychain items are encrypted and unavailable.
Apple confirms in its Hardware Security Overview that the Secure Enclave “refuses to release class keys” until the passcode is entered, effectively enforcing the BFU state.
In the BFU state:
Only a small subset of data protected with NSFileProtectionNone or stored in memory at boot is accessible.
Most apps and user content remain fully encrypted.
The Keychain is inaccessible unless items are marked with lower protection levels (rare).
What Is AFU (After First Unlock)?
Once the user unlocks the device for the first time after boot, it enters the AFU state. At this point, the Secure Enclave has authenticated the user and released the necessary class keys from the keybag into memory. These keys remain available until the device reboots or automatically powers off.
Apple explains in its Data Protection Overview that “after the first unlock, the device remains in a state where most data is accessible until it is shut down or restarted.” This is the primary state in which normal app usage and most forensic extractions occur.
In the AFU state:
Files protected with classes like NSFileProtectionCompleteUntilFirstUserAuthentication and NSFileProtectionComplete become accessible.
The Keychain (if not using biometric-only flags) is available for reading secure items.
Background processes and apps can access encrypted content as needed.
Forensic Implications and Strategies
Apple’s iOS security architecture—featuring the Secure Enclave (SEP), keybags, and data protection classes—creates significant constraints for forensic acquisition. Whether an iPhone is in Before First Unlock (BFU) or After First Unlock (AFU) state directly determines what data, if any, can be accessed. This distinction must inform both the timing and methods used by forensic professionals.
BFU State: Highly Restricted Access
When an iPhone is in the BFU state, it has been powered on or rebooted, but not yet unlocked with a passcode. In this state, the Secure Enclave does not release the decryption keys needed to access most user data. According to Apple’s Data Protection Overview, data protected by the class NSFileProtectionComplete remains fully encrypted until the user unlocks the device.
Key forensic limitations in BFU:
User data (messages, emails, photos) is inaccessible.
The Keychain is sealed by SEP and cannot be queried.
Pairing records, Wi-Fi settings, and network configuration profiles are protected and unavailable.
As Apple documents, this information is encrypted under the “Complete Protection” class and only accessible after the first unlock: Keybags and Keychain – Apple
Limited access to unencrypted partitions (e.g., system files, partial logs).
Only data classified under NSFileProtectionNone (rarely used) may be readable—such as limited system logs or crash reports.
As such, full-disk or logical acquisitions are not possible in BFU. Instead, forensic response in this state typically focuses on:
Preserving the device state: isolate from networks, prevent shutdown, and maintain power
Capturing basic device metadata: serial number, model, OS version, boot state;
Examining non-user partitions: such as iBoot or SEP firmware for device profiling.
AFU State: Conditional Access to User Data
Once the device is unlocked after boot, it transitions into the AFU state. In this state, the Secure Enclave releases decryption keys for many files and Keychain items. Most user data becomes accessible, assuming the device remains unlocked and powered on.
App List (Installed applications, app bundle identifiers and versions)
Some App Data-Not fully protected (Some cache or temp files, app containers storing data under NSFileProtectionCompleteUntilFirstUserAuthentication)
System Logs (idevicesyslog can stream logs in real-time, rash logs, kernel panics, diagnostics-on some iOS versions)
Wi-Fi and Bluetooth Info (known wireless devices, previously connected networks)
Network Settings (VPN configurations, IP address and routing info, mobile network info)
However, if the device reboots or exceeds a period of inactivity (as defined in Apple’s inactivity protection rules), it will return to BFU, re-sealing encrypted data.
Inactivity Reboot Feature: A Forensic Risk
One key implication for forensic access is the Inactivity Reboot Security Feature, introduced by Apple to protect data even when a phone is seemingly “available.”
If an iPhone has not been unlocked for a set period (e.g., 6.5 days with no unlock and 4 hours of inactivity), the Secure Enclave automatically revokes access to previously released keys. As a result, the device transitions back to a BFU-like state, even if it hasn’t rebooted.
iPhone Forensics Outlook
As Apple continues to prioritize user privacy through hardware-based encryption and data protection classes, iPhone forensics faces increasingly complex technical and legal challenges. The distinction between BFU (Before First Unlock) and AFU (After First Unlock) states remains central to understanding what evidence can be accessed and when.
In BFU, most user data—including network settings, paired device records, and app content—remains sealed and inaccessible due to encryption keys stored in the Secure Enclave. Only minimal system metadata can be gathered without a passcode or biometric unlock. In contrast, the AFU state provides an opportunity window where certain data becomes temporarily accessible, but even this is subject to time-bound protections like the inactivity reboot mechanism.
For forensic analysts, this means timing, lawful authority, and proper preservation techniques are more critical than ever. Future investigations will likely rely increasingly on:
Agent-based forensic tools that work in AFU windows,
Chain-of-trust analysis across system logs and metadata,
Collaborative efforts with device management systems and lawful requests to Apple.
At the same time, Apple is expected to continue strengthening iOS security, reducing unencrypted metadata, and limiting access even further—aligning with a broader industry trend toward zero-access architectures.
Ultimately, staying current with Apple’s evolving Platform Security Guide and adopting adaptive forensic workflows are essential for anyone operating in the digital forensics or mobile security space.
