That's not true. Cellebrite has working BFU and AFU exploits for recent iOS and usually catches up to the latest iOS versions and hardware in weeks or a couple months. They do not have working brute force support for the Pixel 2 / Pixel 6 or later / iPhone 12 or later due to the secure elements but can still exploit the devices in BFU mode and extract the data available before unlocking. iPhone 17 may work out better due to hardware memory tagging but previous iOS and iPhone models did not hold out in the way you're claiming at all.
What data _is_ there to extract BFU, really, if you can't break the secure element? I mean, the main storage isn't decrypted yet, right?
Android and iOS both use filesystem-based disk encryption with fine-grained keys, not only a global encryption key. There's a subset of the OS data available before first unlock to have basic functionality available there. Three examples are installed apps, saved Wi-Fi networks including passwords and alarms with the system clock apps being available before first unlock via explicitly storing it in the before first unlock encrypted data. All of the data and metadata blocks are encrypted, but not all of it is encrypted with keys tied to the user's credentials. Android uses per-profile encryption so it gets security benefits from it too, but both operating systems mainly use it for usability benefits needed to make always on disk encryption suitable for their broad audience. They were able to deploy disk encryption to everyone without complaints partly because they did it this way, so in that sense the before first unlock data has a security benefit.
Apps are installed so that their packages are available before first unlock and can explicitly opt-in to supporting a specific subset of their components and data before available before first unlock. An app can implement push notifications before first unlock if the developers want to do it, and they could do that in a way where no message data, etc. is available before first unlock. The OS leaves it up to apps to decide what to do, and nearly all apps stick with the default of all their functionality and data available After First Unlock instead of either making it available Before First Unlock or having it go back at rest while locked again.
My mental model of this is “Apple releases new iOS with security patches -> time passes before cellebrite develops an AFU exploit -> Eventually Apple patches the exploit -> go to step 1”. By adding auto reboot Apple ensured that since lots of the time is spent in the stage where the latest iOS has no AFU exploit and AFU becomes BFU before that changes, and thus they are stuck with only extracting whatever is unencrypted at boot time at best. The leaked matrices even for September 2024 had no BFU listed for any remotely recent versions.
Cellebrite and other companies can develop exploits using independent sets of bugs. Cellebrite is also not the only company developing exploits. These companies (or governments) don't have to wait until the bugs they use get patched or mitigated before they develop more exploits. They can also develop exploits against Beta releases of Android and iOS rather than waiting for it to be used by a large audience. That makes it possible for them to develop exploits against newer exploit protections prior to launch unless they're specific to newer hardware that's not released yet. Android has a more open development model and much longer longer beta testing for new major releases which gives them a lot of time to prepare for next generation exploit protections in standard Android. iOS doesn't give them as much time to prepare, but they still have time to prepare before new major releases come out. That's also not taking into account that they can have more than public sources to test with new versions.
Apple and Google do not appear to have a regular source for finding out which vulnerabilities are currently being exploited. Both appear to be refraining from actively seeking our these devices to patch all the exploits they use. It's often external researchers including at Citizen Lab and Amnesty International determining which vulnerabilities are being exploited by these tools and reporting it to both Apple and Google. Long periods of time often pass with no loss of capabilities for new Android and iOS versions. The main reason Cellebrite loses access is likely tied to the deployment of new exploit protections requiring working around those and using new vulnerabilities. Code churn also likely impacts them.
You seem to be mixing up what they're referring to as a BFU exploit with a BF exploit. Pixel 2, Pixel 6+ and iPhone 12+ have withstood Cellebrite's efforts to do brute force attacks against a BFU device. BFU exploit means they can extract data such as saved Wi-Fi networks and installed apps, but without a BF exploit they cannot bypass the secure element throttling. It may become impractical for them to have BF exploits anymore, but it doesn't make their BFU exploits worthless.
Citation needed.
It's a statement directly based on the regularly updated Cellebrite Premium documentation from the past 2 years. At a bare minimum, the April 2024, July 2024 and February 2025 documentation was posted publicly and even that subset shows what's said above. Do you think Cellebrite's documentation isn't accurate or that the leaked documentation was tampered? We aren't posting it publicly ourselves, but we do have a source providing it to us and can compare it over time. Only Pixels and iPhones are successfully stopping brute force but neither is successfully stopping exploiting the OS whether they're BFU or AFU.