GrapheneOS has strong defenses against data extraction. It heavily builds upon the standard security features provided by Android 17 and the most secure hardware available for Android. Currently, only Pixels provide the hardware security features and updates required by GrapheneOS. That's going to change in 2027 thanks to our partnership with Motorola Mobility and progress being made by Qualcomm.

Disk encryption provides strong protection for data. Even the most sophisticated attackers aren't going to be directly breaking it. They either need to exploit the OS while in After First Unlock state or brute force the PIN/password.

Android 16 QPR2 calls for a secure element implementing rate limiting ramping up delays. It's 4 hours after 10 and 41 days after 15. Only 20 attempts are allowed. For usability, It rejects the most recent 5 unique failed attempts early to avoid wasting attempts on repeated errors. GrapheneOS only supports devices implementing the latest generation secure element rate limiting.

https://source.android.com/docs/security/features/authentication/rate-limiting

The secure element on the supported devices also has insider attack resistance. That's implemented by requiring the Owner user to successfully authenticate before the secure element firmware can be updated. A valid signing key and greater version number aren't enough alone. The purpose of this is preventing any government from bypassing the rate limiting by coercing the creation of a firmware update removing the rate limit.

Pixels have used a secure element with an internal timer implementing rate limiting and insider attack resistance since the Pixel 2 launched near the end of 2017. Here's a post about this from back in 2018:

https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html

The secure element and integration into the OS has become far better since then, but it shows this goes back a long way and isn't a new feature.

GrapheneOS also raises the character limit for passwords from 16 to 128. This enables using high entropy diceware passphrases not depending on the secure element rate limiting.

To make a strong passphrase convenient to use without ruining it with biometric unlock, GrapheneOS adds an optional 2nd factor fingerprint PIN. We reduce the allowed fingerprint attempts from 20 to 5 and failure to enter the correct 2nd factor PIN counts towards it. This enables using 6-8 random diceware words as the main unlock method required in Before First Unlock and fingerprint+PIN using a short PIN for convenience. Using a valid fingerprint prompts to enter the 2nd factor PIN which is needed to complete unlocking the screen and hardware keystore.

GrapheneOS greatly improves the exploit protections for the OS with hardened memory allocators and other features. It heavily uses hardware-based security features including hardware memory tagging (MTE) to protect against exploits. A partial overview of those protections is here:

https://grapheneos.org/features#exploit-protection

GrapheneOS adds specialized protection against attacks with physical access too. For example, it blocks new USB connections at a software and hardware level by default while locked and disables USB data as soon as there are no active USB connections.

GrapheneOS shipped a locked device auto-reboot timer back in June 2021. It can be set between 10 minutes and 72 hours. We enabled it by default using 72 hours and then lowered it 18 hours. It automatically returns the device to Before First Unlock state due to our memory zeroing as part of tearing down the OS and booting. We got Pixels to add memory zeroing for booting the firmware fastboot mode in April 2024. Apple and Google added a locked device auto-reboot timer in iOS 18.1 and Android 16. For Android, it can be enabled with the Android Advanced Protection Mode. Our implementation is better for multiple reasons but it's a useful feature regardless.

Android uses separate encryption keys for each secondary user and Private Space. GrapheneOS adds support for putting both back into Before First Unlock state without a reboot via end session for secondary users or toggles for either to do it by default. It's still much better for the device to be rebooted to get the main user back at rest, completely clear leftover data from RAM and block secure element updates.

Our duress PIN/password feature is a minor feature fitting into the bigger picture. It wipes the device when it's entered in any OS prompt for the current profile's PIN or password. It will wipe the device when entered into the authentication prompt for changing a sensitive setting or anything else requiring it, not only the lockscreen. It works across every profile including secondary users and Private Spaces, not only the main user.

There are multiple ways to use the duress PIN/password feature including writing it down on a phone case or a paper kept in a wallet. People should carefully consider how to use it in an actual duress situation where there can be physical or legal consequences for wiping the device. GrapheneOS doesn't require it to protect data from being extracted from the device, but it takes recovering it completely off the table even with the PIN/password for each profile on the device.

GrapheneOS doesn't depend on the duress PIN/password to protect user data. It's one of the tools it provides among the major privacy and security improvements it offers as a whole. Our features page provides an overview of what GrapheneOS offers compared to standard Android 17. It covers most of the major features we provide and many of the minor ones but there's also a lot more beyond it. Our release notes are a lot more exhaustive since we make sure to cover everything when it's added, changed or removed.

https://grapheneos.org/features
https://grapheneos.org/releases#changelog