The phrase “After First Unlock” gets used in forensic discussions as if it were a single switch: the phone is locked, but the keybag is open, so everything is readable. Apple’s own documentation describes something narrower. Data Protection assigns each file to a class, and “accessibility is determined according to whether the class keys have been unlocked” (Apple Platform Security, Data Protection overview). AFU is a state of the keybag. It is not a property of an app, and it is not a blanket grant over the data volume.
That distinction matters for anyone reasoning about what an AFU-state iPhone yields for Signal, WhatsApp, or Telegram message stores. The useful unit of analysis is the file’s Data Protection class and whether that class key is resident in the keybag at the moment of acquisition. The protocol specifications for these apps tell us what key material the designs permit to exist on disk. They do not tell us what a shipped iOS binary persists, or in which class. Conflating the two is the most common error in this area.
What Data Protection actually does per file
Apple’s Data Protection overview describes the mechanism directly. Every time a file is created on the data volume, Data Protection generates a new 256-bit per-file key and hands it to the hardware AES engine, which encrypts the file as it is written to flash. On A14 through A18 and M1 or later devices, the encryption uses AES-256 in XTS mode, with the per-file key run through a KDF (NIST SP 800-108) to derive a 256-bit tweak value and a 256-bit cipher key. On A9 through A13 and S5 or later, the encryption uses AES-128 in XTS mode, with the 256-bit per-file key split into a 128-bit value and a 128-bit cipher key.
The per-file key is not stored in the clear. It is wrapped by a class key, and the class key is what the keybag holds. When the device is in a given lock state, some class keys are loaded and some are not. A file whose class key is loaded can be decrypted by a process with the right entitlements. A file whose class key is not loaded cannot, regardless of which app wrote it.
This is why “AFU” is not a forensic boundary in the sense of a single line that, once crossed, exposes everything. It is a state in which a specific subset of class keys is available. The boundary is per class, and therefore per file.
Why the class, not the app, is the right unit
Two apps can both store SQLite databases in the same container directory and still have different forensic exposure in AFU state, because the class attribute is set per file (and, on APFS, can be subdivided per extent). Conversely, two files from the same app can have different exposure if the app assigns them to different classes. The app identity is not the variable that determines accessibility. The class is.
This has a practical consequence for how a forensic analysis should be framed. The question is not “does AFU expose Signal?” or “does AFU expose Telegram?” The question is: for each file that contains message content or key material, what is its Data Protection class, and is that class key resident in the keybag in the state the device was acquired in?
Apple’s Data Protection overview retrieved here describes the key hierarchy and the per-file mechanism. It does not reproduce the class table itself. The class definitions (A, B, C, D, and the “Complete Until First User Authentication” class) are documented on Apple’s separate Data Protection classes page, and any claim about which class a specific file belongs to should be checked against that page and against the file’s actual attributes on the device, not inferred from the overview.
What the protocol specs tell us about on-disk key material
The Signal specifications are design documents. They describe what the protocol permits, not what the shipped iOS binary does. With that caveat, they are still useful, because they define the key material that can exist at rest.
X3DH establishes a shared secret key between two parties who mutually authenticate each other based on public keys, and provides forward secrecy and cryptographic deniability (Signal X3DH specification). The spec states that Bob deletes any one-time prekey private key that was used, for forward secrecy. That is a deletion instruction in the design. Whether a given implementation actually deletes it, and when, is a separate question that requires inspecting the binary or the on-disk state.
The Double Ratchet derives new keys for every message so that earlier keys cannot be calculated from later ones, and mixes Diffie-Hellman outputs into derived keys so later keys cannot be calculated from earlier ones (Signal Double Ratchet specification). The spec also states that message keys may be stored without affecting the security of other message keys, which is useful for handling lost or out-of-order messages. It defines a MKSKIPPED state variable as a dictionary of skipped-over message keys indexed by ratchet public key and message number.
Read together, these specs tell us that a conforming implementation may have skipped message keys on disk at any given time, and that it is supposed to delete one-time prekey private keys after use. They do not tell us the Data Protection class of the file that holds the ratchet state, or whether the implementation stores skipped keys in memory only. Those are implementation facts, and they require implementation evidence.
WhatsApp and Telegram: what the retrieved sources do and do not support
WhatsApp’s public security page retrieved here is a user-facing safety page. It covers two-step verification, avoiding fake clients, group controls, and scam awareness. It does not describe the on-device database format, its encryption at rest, or its Data Protection class. Any claim that WhatsApp’s iOS message store is or is not encrypted at rest, or belongs to a particular class, is not supported by this source and should not be made from it.
Telegram’s MTProto page is explicit about its scope: it “deals with the basic layer of MTProto encryption used for Cloud chats (server-client encryption)” and points to a separate page for Secret Chats end-to-end encryption (Telegram MTProto documentation). The same page states that as of version 4.6, major Telegram clients are using MTProto 2.0, and that MTProto v1.0 is deprecated and being phased out. None of this describes the local storage format or the Data Protection class of any Telegram database on iOS.
The practical implication is that a forensic analysis of “Telegram databases” has to distinguish which store is being examined. Cloud chats and Secret Chats follow different cryptographic paths, and the MTProto page does not describe either one’s on-disk representation. The same discipline applies to WhatsApp: the user-facing security page is not a source for local storage claims.
A reproducible method for the class question
The following is a method, not a result. It does not assert what any specific app does. It is a procedure for answering the class question for a given file on a given device.
- Identify the on-disk path of the message store or key material you care about. For a given app, this is an implementation fact that must be established from the app’s container layout, not assumed.
- Read the file’s Data Protection class attribute. On iOS, this is exposed through the file’s protection class metadata; the exact tooling depends on whether you are working from a full file system image or a logical acquisition.
- Determine whether the class key for that class is resident in the keybag in the device state you acquired. This is the step that “AFU” is shorthand for, and it is the step that determines whether the file is decryptable.
- If the class key is resident, the file is decryptable by a process with the appropriate entitlements. If it is not, the file is not, regardless of the app that wrote it.
Step 3 is where the popular framing breaks down. “AFU” does not mean all class keys are resident. It means the keybag is in a state where some class keys are loaded. Which ones depends on the class definitions and on the device’s configuration.
A labeled hypothetical, not a finding
Suppose an app stores its session keys in a file assigned to the “Complete Until First User Authentication” class. In AFU state, a process with the right entitlements could read those keys. That is a reasoning aid about how class-key logic works. It is not a finding about any app, and it should not be cited as one. The retrieved sources do not establish the Data Protection class of any specific app’s message store or key material.
The same logic applies in the other direction. Suppose an app stores its message database in a class whose key is not loaded in AFU state. Then the database is not readable in that state, even though the device is “after first unlock.” The class attribute, not the lock-state label, is what determines the outcome.
What Apple says about locked-device extraction
Apple’s US law enforcement guidelines include a section titled “Extracting Data from Passcode Locked iOS Devices” in the index of information available from Apple (Apple Legal Process Guidelines, October 2025). The retrieved excerpt contains the section title but not its body. The title alone does not establish what Apple says it can or cannot extract, and no technical capability should be attributed to that section without reading its full text.
The same guidelines state that, for requests from US government and law enforcement agencies for content, absent emergency circumstances, Apple will only provide content in response to a search warrant issued upon a showing of probable cause, or customer consent. That is a statement about Apple’s response to legal process, not about what a forensic tool can extract from a device in AFU state. The two are separate questions and should be kept separate.
Why this reframing is useful
The popular framing treats AFU as a binary: locked or effectively unlocked. The Apple source describes a per-file class system in which accessibility depends on whether the class key has been unlocked. The reframing is not pedantic. It changes what evidence is needed to support a claim.
Under the binary framing, a claim like “AFU yields the Signal database” sounds like a single fact about a device state. Under the class framing, it decomposes into at least three separate claims: the database’s path, its Data Protection class, and whether that class key is resident in AFU state. Each of those requires its own evidence. The protocol specs can support claims about what key material the design permits on disk. They cannot support claims about the class attribute of a shipped binary’s files.
This is also why the boundary is real but narrower than the slogan suggests. AFU does expose a meaningful set of files, and for some apps that set may include message content or key material. But the exposure is determined by the class assignment, and the class assignment is an implementation fact that has to be measured, not assumed from the lock-state label.
FAQ
Does AFU mean the device is effectively unlocked for forensics?
No. AFU is a keybag state in which some class keys are loaded. Apple’s Data Protection overview states that accessibility is determined by whether the class keys have been unlocked. Which class keys are loaded in AFU state depends on the class definitions and the device configuration, not on a blanket rule.
Can I determine from the X3DH or Double Ratchet specs whether Signal’s iOS database is readable in AFU state?
No. Those specs describe protocol design, including what key material may exist at rest (for example, skipped message keys in the MKSKIPPED state variable, and the instruction to delete used one-time prekey private keys). They do not describe the Data Protection class of any file in a shipped iOS binary. That requires implementation evidence.
Does Telegram’s MTProto page describe the on-device database?
No. The page states it deals with the basic layer of MTProto encryption used for Cloud chats (server-client encryption) and points to a separate page for Secret Chats end-to-end encryption. It does not describe local storage format or Data Protection class.
What is the minimum evidence needed to claim a specific app’s message store is readable in AFU state?
At least: the on-disk path of the store, its Data Protection class attribute, and confirmation that the corresponding class key is resident in the keybag in the acquired state. The protocol specs alone are not sufficient.
Does Apple’s law enforcement guidelines section on locked-device extraction establish a technical capability?
The retrieved excerpt contains only the section title. The title alone does not establish what Apple says it can or cannot extract. The full text of that section would be needed to make any claim about its contents.
What to measure next
If the goal is to answer the class question for a specific app, the next steps are concrete. Retrieve Apple’s Data Protection classes page and quote the class definitions verbatim rather than paraphrasing them. Read the full text of Apple’s “Extracting Data from Passcode Locked iOS Devices” section. Establish, from a reproducible teardown or from Apple developer documentation, the Data Protection class attribute of the specific files in question. Until those steps are done, the honest position is that the protocol specs tell us what key material may exist, and the class question remains open.
That is a less satisfying answer than “AFU means everything is readable,” but it is the one the sources support. The forensic boundary is the class key, and the class key is a per-file fact. Measuring it is the work.