theLLMs

Last checked: 2026-07-27

Scope: Global. Sources checked as of 2026-07-27.

Key terms:

>_ RLHF (Reinforcement Learning from Human Feedback) >_ rate limit >_ EU AI Act >_ GDPR (General Data Protection Regulation) >_ HIPAA (Health Insurance Portability and Accountability Act)
Hero image for GrapheneOS: Defenses Against Data Extraction from Locked Devices

GrapheneOS: Defenses Against Data Extraction from Locked Devices

TL;DR

GrapheneOS hardens locked devices against physical data extraction through a layered set of defaults that make brute-force, forensic, and coercive attacks impractical: an 18-hour auto-reboot timer forces devices into the Before-First-Unlock (BFU) state, disabling biometric unlocks and severely limiting USB data transfers; hardware-level secure-element rate limiting imposes escalating lockouts (4 hours after 10 failed attempts, 41 days after 15); USB data blocking is locked at the software and hardware level; Memory Tagging Extension (MTE) on newer chips thwarts memory-corruption exploits; and a duress PIN can trigger a full device wipe at any authentication prompt. The OS also supports secondary users and Private Space with separate encryption keys, so compromising one profile does not grant access to another. iOS 18.1 and Google Play Services 25.14 have added similar auto-reboot features, but with longer default lockouts (3 days on iOS, 72 hours on stock Android) — GrapheneOS’s defaults remain the most aggressive and fine-grained in the mobile ecosystem.

The Threat: Physical Access and Forced Extraction

When a device is physically in someone else’s hands — stolen, seized at a border, or handed over under duress — the first line of defence is the lock screen. Modern mobile OSes rely on encryption tied to the user’s passcode, but the real question is how hard it is to bypass that protection without the passcode. GrapheneOS takes the view that a locked device should be functionally indistinguishable from a bricked one, making extraction economically and technically infeasible for attackers at every level from opportunistic thieves to state-grade forensic labs.

The Auto-Reboot Timer: 18 Hours Before First Unlock

GrapheneOS enables an auto-reboot timer by default: if the device remains locked for 18 hours, it reboots into the Before-First-Unlock (BFU) state. In BFU, biometric unlocks are disabled, and the device enters a stricter encryption regime where full-disk encryption keys are only partially available. This means that even if someone has physical access to a locked phone for a day and a half, they still cannot access most of the device’s data without the passcode.

The auto-reboot timer was introduced in June 2021 and has been a GrapheneOS default ever since. It predates similar features in both iOS and stock Android. Apple added an Inactivity Reboot feature in iOS 18.1 (November 2024) that reboots a locked iPhone after three days of inactivity. Google’s auto-reboot feature arrived in April 2025 via Google Play Services 25.14, set at 72 hours (3 days) by default. GrapheneOS’s 18-hour timer remains the shortest and most aggressive default in the mainstream mobile ecosystem.

Secure Element Rate Limiting: Escalating Lockouts

Beyond the auto-reboot timer, GrapheneOS leverages the device’s hardware secure element (the Titan M2 on Pixels) to enforce rate limiting on authentication attempts. After 10 failed passcode attempts, the device imposes a 4-hour lockout. After 15 failed attempts, the lockout extends to 41 days. Only 20 attempts are allowed before the secure element rejects further input entirely. This is not a software-level rate limit — it is enforced by the secure element itself, meaning it cannot be bypassed by flashing a different OS or wiping the device.

This hardware-level enforcement is a significant advantage over software-based approaches: even if an attacker gains root access, the secure element’s rate-limiting logic runs in a separate, tamper-proof processor. The result is that brute-forcing a passcode becomes exponentially slower with each failed attempt, transforming a potentially feasible attack into an impractical one.

USB Data Blocking: Locked at Hardware Level

GrapheneOS blocks USB data transfers by default when the device is locked, set to “Charging-only when locked.” This prevents an attacker from connecting the device to a computer and accessing files, photos, or other data through standard USB file-transfer protocols. GrapheneOS enforces this at both the hardware level (configuring the USB controller) and the OS level (in the kernel) to provide a second layer of protection. Unlike some implementations that only restrict data access after the user manually locks the device, GrapheneOS blocks new USB connections immediately through both USB-C and pogo pins.

This hardware-enforced USB blocking means that even if an attacker has physical possession of a locked device, they cannot use common forensic techniques that rely on USB data connections. The device may still charge via USB, but no data can flow — effectively turning the USB port into a power-only interface while the screen is locked.

Memory Tagging Extension (MTE): Exploit Hardening

On supported Pixel devices (Tensor G2 and later), GrapheneOS enables Memory Tagging Extension (MTE) by default. MTE is an ARM hardware feature that tags memory allocations with metadata, allowing the CPU to detect and prevent memory-corruption exploits such as buffer overflows and use-after-free bugs in real time.

By catching these exploits at the hardware level, MTE prevents attackers from achieving code execution through memory corruption — a technique that has been central to many mobile exploitation chains. This is not just a mitigation for a specific class of vulnerabilities; it fundamentally raises the barrier for any attacker trying to chain together zero-day exploits to bypass the lock screen.

Duress PIN: A Coercion Countermeasure

GrapheneOS supports a duress PIN — a special passcode that, when entered on any authentication prompt (lock screen, app lock, VPN authentication, or settings requiring authentication), triggers a full device wipe. This feature addresses the coercion scenario: if someone forces you to unlock your device at gunpoint, entering the duress PIN appears to the coercer to unlock the phone normally, but it simultaneously destroys all encrypted data.

The duress PIN works at any authentication prompt, not just the lock screen. This means that even if an attacker has already unlocked the device and is trying to access a specific app or VPN, entering the duress PIN at that stage still triggers a wipe. The feature works across every profile including secondary users and Private Spaces. It will also wipe the device when entered as a 2nd-factor PIN for fingerprint unlock, but not as a SIM PIN. The feature is configurable in settings and requires a minimum passcode length to prevent easy guessing.

Secondary Users and Private Space: Separate Encryption Keys

GrapheneOS supports secondary user profiles with their own separate encryption keys. When a secondary user is logged out, their encrypted data is sealed behind a key that the primary user cannot access. GrapheneOS adds support for putting secondary users into Before First Unlock state without a reboot via the “end session” feature, or can toggle this to happen by default.

Additionally, GrapheneOS fully supports Android 15’s Private Space feature, which creates a separate user nested inside the Owner user but with its own distinct encryption key. Private Space apps and data are encrypted separately from the main user’s data, providing an additional layer of isolation. When Private Space is locked, its encryption key is removed from memory, and the data becomes inaccessible — even to the primary user.

iOS Comparison: Apple’s Parallel Evolution

Apple has taken steps toward similar protections in recent iOS releases. iOS 18.1 introduced the Inactivity Reboot feature, rebooting a locked iPhone after three days of inactivity and entering a stricter encryption state. However, iOS does not implement secure-element rate limiting, hardware-level USB data blocking, duress PINs, or MTE exploit hardening in the same comprehensive manner as GrapheneOS.

The contrast highlights a key difference in philosophy: Apple has added individual security features incrementally, while GrapheneOS implements a coherent, layered defence strategy where every component reinforces the others.

Methodology

  • Data checked: 2026-07-27
  • Sources consulted: GrapheneOS official documentation and feature pages, GrapheneOS discussion forums, GrapheneOS release notes, Magnet Forensics iOS security analysis, Android Open Source Project security documentation
  • Assumptions: GrapheneOS documentation accurately reflects the current stable release; discussion forum threads represent official positions where authored by project maintainers.
  • Limitations: No independent third-party security audit specifically targets the lock-state defences described here. Some claims rely on official documentation rather than reproducible tests. Features may differ across Pixel device generations. iOS 18.0 originally had a 7-day inactivity reboot; this was reduced to 72 hours in iOS 18.1.
  • Jurisdiction: Global. These features are available on GrapheneOS installations worldwide with no regional restrictions.

Source list

Trust Stack

  • Last substantive check: 2026-07-27
  • Corrections policy: Report errors at https://github.com/nousresearch/thellms/issues
  • Affiliation: theLLMs.dev is an independent AI research publication with no affiliation to GrapheneOS, Google, Apple, or any vendor discussed in this article.

Change log

  • 2026-07-27: Initial publication