Locked Isn’t Locked: The Cryptographic State Police Are Racing to Preserve on Your Phone in Phoenix
This article discusses publicly documented forensic standards and vendor security architecture. It does not claim that any particular method was used in any specific case.
A lock icon on a phone screen tells you nothing. There’s a second lock underneath it, one you can’t see, and whether it’s engaged decides what a forensic lab can actually pull off the device. Most people never learn this exists. Defense lawyers who do learn it start winning arguments the ones who don’t never even think to make.
If you’re facing charges in Phoenix or anywhere in Maricopa County and a phone is sitting in your discovery file, read this before you read the forensic report.
For the full roadmap after an arrest: Case Stages.
Two States. One Screen. No Way to Tell Them Apart By Looking…
Every modern iPhone runs on a chip called the Secure Enclave. It’s not software. It’s a physically separate coprocessor soldered onto the same silicon package as the main processor, but walled off entirely, with its own boot ROM, its own AES engine, its own stripped-down operating system deliberately clocked slow to resist power-analysis attacks. Every encryption key on the phone traces back to one hardware value fused into that chip at the factory. That value never leaves the chip. Nobody has ever pulled it out. Not Apple, not the FBI, not a forensic lab holding a warrant.
That hardware key combines with your passcode to produce what Apple calls a class key, and class keys are what actually unlock files. Different files get different protection classes. Some stay encrypted until the passcode goes in. Some stay encrypted until the phone reboots. That distinction is everything:
- Before First Unlock (BFU): the phone rebooted, and nobody’s entered the passcode since. The Secure Enclave will not release the class keys. Most of the device is cryptographically inert.
- After First Unlock (AFU): the passcode went in at least once since the last reboot. Class keys sit live in memory. The phone, and any forensic tool that gets its hands on it, can reach almost everything.
Here’s what most people never get told: a phone can sit at a lock screen, passcode required, looking untouched, and still be in AFU state. Unlock it ten minutes before it gets seized and it hasn’t rebooted since, the keys are live. The screen doesn’t tell you the truth. Only the phone’s own clock knows.
Not All Files Lock the Same Way
The Secure Enclave doesn’t treat every file on the phone the same. Apple splits files into protection classes, and which class a file lands in decides exactly when it becomes readable. Four classes matter:
- Complete: the strictest. Locks the instant the screen locks. Needs the passcode or biometric every time.
- CompleteUnlessOpen: for files actively being written when the phone locks, a mail attachment downloading in the background, for instance. Stays accessible until the write finishes, then locks like Complete.
- CompleteUntilFirstUserAuthentication: the one that actually defines AFU. Unlocks once, after the first passcode entry post-reboot, and stays unlocked even if the screen locks again, right up until the next full reboot. Most apps use this class. It’s why AFU is so much richer than BFU: almost everything in this class is fair game the moment the phone gets unlocked even once.
- NSFileProtectionNone: no lock beyond the hardware key itself. Alarms, emergency dialer, a handful of system functions. That’s the entire BFU menu. Everything else stays sealed.
Translation: the operating system, the base software running the phone, doesn’t decide what’s accessible. The file’s assigned class does, and that class got set the moment the file was created.
Why a Factory Reset Reads As “Gone” In a Forensic Report
This matters for reading a forensic report accurately, not for anyone deciding what to do with a phone. A factory reset doesn’t work by deleting files one at a time. It destroys the wrapping key protecting the entire keybag, the master list of every class key on the device. Once that key is gone, the files are still physically sitting on the flash chip, encrypted, permanently unreadable. Newer chips back this with anti-replay protection, a system that stops an old, valid copy of a deleted key from ever being reused even if someone recovers it. That’s the technical reason a forensic report can say “no data recoverable” and mean it.
One thing worth saying plainly: resetting or wiping a device after you know, or reasonably should know, that it’s connected to an investigation is illegal. Courts treat that as spoliation, and it can support charges on its own, regardless of what the data would have shown.
Why Officers Sprint for a Charger
This is why a seized phone gets plugged into a battery pack before it even leaves the scene. Keeping it powered isn’t procedure for its own sake. It prevents an accidental reboot that would slam AFU access shut and drop the device back into BFU, where most forensic tools hit a wall.
Then Apple made that wall move on its own. Starting with iOS 18, an undocumented mechanism began forcing phones to reboot after a set period of inactivity, regardless of anything else happening to the device. Security researcher Jiska Classen found it by tearing apart the actual iOS binaries, specifically the keybagd daemon and the AppleSEPKeyStore kernel extension, and confirmed the Secure Enclave itself tracks time elapsed since the last unlock. Cross the threshold, and the SEP forces the kernel to reboot. No warning. No user action. Straight to BFU.
The threshold already moved once. iOS 18.0 shipped with a 168-hour window, seven full days. iOS 18.1 cut it to roughly 72 hours. Apple never announced either number publicly. Both came from outside researchers pulling the binary apart.
There’s also USB Restricted Mode, relevant to anyone examining a locked phone through its charging port. After roughly one hour locked, iOS cuts data access over USB entirely. Charging keeps working. Data doesn’t. That’s a second clock forensic tools are racing, not just the reboot timer.
GrapheneOS Did This First. Google Had Nothing to Do With It.
Worth getting right, because most people have it backwards: GrapheneOS is not a Google product. It’s an independent, nonprofit, open-source hardening project, first released in 2016, built entirely outside Google. It runs on Google Pixel phones, and currently only Pixel phones, for one specific reason: Pixel is the only hardware line that ships everything GrapheneOS requires to function. A bootloader that can be relocked with a custom signing key. Verified Boot with rollback protection. A discrete secure element supporting StrongBox and the Weaver rate-limiting API. Hardware-backed attestation. A USB controller the OS can disable at the hardware level, not just in software.
That last piece runs through Google’s Titan M chip, a physically separate security processor built on an ARM Cortex-M3 core, isolated from the main application processor for the same reason Apple isolates the Secure Enclave: so a compromised main OS can’t touch it. Titan M stores rollback counters for verified boot, rate-limits credential guesses through Weaver, and wires directly into the phone’s physical buttons so a remote attacker can’t fake a press. Google built that chip. Google did not build GrapheneOS. GrapheneOS’s developers looked at what hardware could actually support real security hardening and picked the phone that already had it.
And GrapheneOS shipped an automatic reboot-to-lock feature years before Apple. It launched in 2021, originally 72 hours, later tightened to an 18-hour default. Unlike Apple, GrapheneOS documented theirs openly, on their own site, with the number stated plainly. Apple’s version had to be reverse-engineered because Apple never wrote it down anywhere.
Signal Isolation Buys Them Nothing Against This Clock
The reboot timer runs on elapsed time. Nothing else. It doesn’t care whether the phone is on a network or sealed inside a radio-blocking evidence bag. A phone can be fully isolated from every tower and Wi-Fi signal on earth and still silently reboot itself into BFU, purely because the clock ran out. The Scientific Working Group on Digital Evidence, the body writing the national standards examiners train on, tells its own people to plan around exactly this gap. Isolating a phone from a network and racing its internal clock are separate problems. Beating one does nothing for the other.
Face ID Doesn’t Work Until Someone Types the Passcode First
Here’s a detail that changes how an officer actually behaves at the scene. Biometrics, Face ID, Touch ID, a fingerprint reader on Android, only function in AFU state. In BFU, they’re switched off entirely, not weakened, off. The Secure Enclave requires the passcode itself, typed or entered manually, to make that first transition out of BFU. No face, no finger, gets you there. Only the code.
That’s a hard rule, not a preference. Apple enforces it directly: after any reboot, or after 48 hours of the device sitting idle, or after five failed biometric attempts in a row, the system falls back to passcode-only and refuses biometrics until that passcode goes in. So an officer holding a phone that already crossed the reboot threshold can point it at your face all day and get nothing. The phone genuinely cannot comply. It’s not being stubborn. The math doesn’t work without the code.
This connects directly to compelled-unlock questions. Courts have drawn real distinctions between forcing someone to reveal a passcode, which many treat as testimony protected by the Fifth Amendment, and forcing a fingerprint or face scan, which some courts treat as closer to a physical characteristic. But that distinction only ever matters in AFU. In BFU, biometrics aren’t a legal question. They’re a technical dead end, full stop, regardless of what a court would allow.
Android Runs the Same Split, Different Name
Android doesn’t use Apple’s exact class system, but it built the same idea from scratch, and the industry term for it is File-Based Encryption. Every Android phone since Android 10 splits storage into two buckets:
- Device Encrypted (DE) storage: the BFU-equivalent tier. Available at boot, before any credential goes in. Alarms, accessibility tools, incoming calls, the bare minimum to make the phone function as a phone.
- Credential Encrypted (CE) storage: everything else. Contacts, messages, photos, almost every app’s actual data. Locked until the first successful unlock, exactly like Apple’s CompleteUntilFirstUserAuthentication class.
Same wall, different label. And on Pixel devices specifically, that wall is enforced by the Titan M chip discussed above, wrapping the CE keys with a hardware-backed Keystore that includes rollback resistance, meaning a factory reset destroys the actual key material, not just a file pointer. Same guarantee Apple makes with its Secure Enclave, built by a different company, running under a different name.
Why Timeline Auditing Matters More in a High-Volume Court System
Maricopa County Superior Court’s Criminal Department processes an enormous caseload, one of the largest of any county court system in the country. That volume creates a specific, practical risk: the gap between arrest, booking, forensic imaging, and the preliminary hearing can stretch further than anyone intends, and nobody scrutinizes it unless the defense does.
That makes the seizure-to-imaging timeline something to actively audit before the preliminary hearing, not assume was handled cleanly by default. Confirming exactly when a device was seized, exactly when it was imaged, and whether that gap could plausibly have crossed the reboot threshold for that specific OS version is a concrete, answerable question. It belongs in the same review as everything else in the forensic report.
Discovery Questions for a Maricopa County Case
Seizure Timeline
- Exact time of seizure. Exact time of imaging. Both, in writing.
- Could the gap have crossed the reboot threshold for that device’s OS version?
Preservation Method
- Was the phone kept powered the whole time?
- Was signal isolation used, and was the charging cable routed inside the enclosure?
- Does the report state BFU or AFU status at extraction in plain terms?
Extraction Scope
- Does the report’s claimed recovery match what’s actually possible given the documented lock state?
- Was biometric access (Face ID, fingerprint) used or attempted, and does that necessarily mean the device was already in AFU state at that moment?
Preliminary Hearing Preparation
- Has the seizure-to-imaging timeline been independently confirmed, not just taken from the report’s own summary?
These belong in motion practice ahead of a preliminary hearing.
What This Actually Buys You
A report claiming full access to a defendant’s app data from a phone that sat in a property room for days before anyone touched it deserves one direct question: was the device still in AFU state by the time it got imaged? If the state can’t answer with a timestamp, their claims about what they recovered deserve zero deference.
Frequently Asked Questions
What does BFU actually mean?
Before First Unlock. The phone rebooted and nobody’s entered the passcode since, leaving most data cryptographically sealed.
Can a locked screen still mean the phone is in AFU state?
Yes. If it was unlocked recently and hasn’t rebooted, it stays in the more accessible AFU state no matter what the screen shows.
Does a Faraday bag stop the phone from rebooting on its own?
No. The reboot timer runs purely on elapsed time.
Did Google build GrapheneOS?
No. GrapheneOS is an independent nonprofit project. It runs on Pixel hardware because Pixel currently ships the specific security hardware GrapheneOS requires, not because Google created the software.
Can police use Face ID or a fingerprint to unlock a phone in BFU state?
No. Biometrics only function in AFU state. The Secure Enclave requires the passcode itself to make the first transition out of BFU, no exceptions.
Why does the seizure-to-imaging timeline matter more in a large court system like Maricopa County’s?
In a high-volume system, that interval isn’t automatically scrutinized unless the defense specifically asks. It’s a concrete fact worth confirming before a preliminary hearing.
Facing Criminal Charges in Phoenix or Anywhere in Maricopa County?
Start here: Ted Law
or request help here: Free Consultation
Call 602-453-3100