The GrapheneOS team says the Pixel 11 'doesn't yet meet the GrapheneOS security standards and may be skipped' because Google cut ARM hardware memory tagging (MTE) from software, firmware, and near-certainly silicon, and it is telling users not to buy the device — a public divergence between Google's flagship hardware and the leading hardened-Android baseline that resolves when GrapheneOS ships Pixel 11 support, formally skips to Motorola, or Google acknowledges or restores MTE.

state: corroboratedheat: mediumuncertainty: mediumknownscott: lowgrapheneos android-platform-security hardware-security-standards memory-safetyGrapheneOS Google

What is this?

GrapheneOS, the hardened Android OS project (~400k users), announced in late August 2026 that its port to Google's new Pixel 11 lineup is stuck at 'partial': ARM's Memory Tagging Extension (MTE), a silicon-level memory-safety feature the project applies across the entire base OS and treats as a hard requirement, is missing from the Tensor G6's software and firmware and 'near certainly' its hardware — which GrapheneOS attributes to Google cost-cutting. The team is publicly telling people not to buy the Pixel 11 (pointing to the Pixel 8/9/10 instead, and advising returns) and is weighing skipping the generation entirely in favor of its upcoming Motorola partnership, whose 2027 flagship is expected to meet its hardware requirements including MTE. The story is not settled in the supplied material: a forum poster relays an unverified Google Support claim that MTE hardware is present but software-disabled, minimal MTE reportedly surfaced in Android 17 QPR1 Beta 4 firmware (prompting GrapheneOS to soften the thread title to 'doesn't yet meet'), and one outlet claims a later beta restores 'bare-minimum' MTE — so whether the silicon truly lacks the feature remains contested.

Why it matters to Scott

GrapheneOS publicly enforcing a versioned hardware-security bar — failing the Pixel 11, telling buyers to stay away, and second-sourcing Motorola rather than soften — restates a position Scott's canon already carries: ip:framework.sovereign-software-assurance's 'assurance demonstrated, not promised' with exit readiness, plus vendor-lock-in's second-source logic. Nothing here extends or challenges that canon, touches his container/LLM stack, or would change what he builds or argues — it's the world agreeing with him again; the only upgrade path would be the unverified 'MTE silicon present but firmware-disabled' claim, which the supplied material cannot establish.

ip:framework.sovereign-software-assuranceip:concept.vendor-lock-inip:concept.software-admission-constitution

queries asked of Scott's wikis

hard security requirements non-negotiable baseline vendor cost cutting
newer is not better hardware refresh upgrade treadmill
single vendor dependency second source platform risk diversification
memory safety hardened runtime sandboxing agent code execution
small open-source project as security standard setter leverage over platform vendor
capability present but disabled firmware gating silicon feature removal

Measured heat

now 0 pts/hpeak 70 pts/hcomments 0/hpeers p14momentum: steady2 platformsage 1034h

points/hour across evidence · reading as of 2026-10-12 02:59:37.977291+11:00 · deterministic, not a model opinion

How the heat travelled

08-29 14:00	⭐ origin echo-reconstructed	GrapheneOS: 'Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped' — 'It appears Google cut an important security GrapheneOS (project forum account) on blog (echo) · attributed from hn.story.49964303	—
10-05 13:02	first on hacker news · published · +887.0h	Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped finnlab	—
10-05 13:02	amplified on hacker news 👑	hn.story.49964303 finnlab	peak 437 · 293 comments · 100% of case engagement
10-05 15:21	our radar first saw it · +889.4h	discovery anchor: hn.story.49964303	—

Evidence (2) — ⭐ canonical anchor

source	object	author	score	comments
🟧 hn	Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped Retrieved article excerpt Open article · Retrieved 2026-10-05T15:31:00.198612+00:00 - ### [GrapheneOSGrapheneOS](https://discuss.grapheneos.org/u/GrapheneOS) - 30 Aug Post #1 Sunday, August 30, 2026 2:20 AM - Edited We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money. ARM hardware memory tagging (MTE) is used by GrapheneOS across the entire base OS including the kernel and every standard base OS process. It's only temporarily disabled for a few device-specific processes. It greatly improves protection against nearly all remote exploits and many local exploits. Pixel 8 launched with hardware MTE support in October 2023. We integrated it into our hardened\_malloc project and began using it across the OS later that month. Android and the Pixel OS never started using it by default. Android Advanced Protection Mode in Android 16 enables it for a few processes. Apple's Memory Integrity Enforcement (MIE) is an always enabled feature on the iPhone 17. It's simply a high quality implementation of MTE using the latest standard extensions. It uses MTE in the most secure mode in the kernel and a large portion of userbase. They did a very good job integrating it. Apple's MIE and Android 16+ AAPM don't use MTE for user installed apps unless those explicitly opt in. GrapheneOS enables it for more apps automatically and has a toggle for users to opt-in for every user installed app. There's a per-app toggle to opt-out for incompatible apps which is uncommon. Neither iOS or Android encourage app developers to opt into MTE and other more aggressive security features used in the base OS. Apple's docs warn developers of performance and stability issues. Our approach enables forcing using MTE in the standard allocators regardless. Pixel 11 does have security improvements including moving to post-quantum secure verified boot (ML-DSA) and replacing Samsung Shannon IMS with AOSP IMS. Titan M3 should significantly improve protection against data extraction in Before First Unlock state. It's too bad they ruined it by cutting MTE. Pixel 11 series is a lot more expensive for an incremental improvement to the CPU, the same underpowered GPU and reduced RAM for the Pro base models. They finally caught up to the last generation of Qualcomm cellular radio. It's overpriced, the upgrades aren't impressive and losing MTE is appalling. Compared to the Pixel 11, a Snapdragon 8 Elite Gen 5 has 40% higher single threaded CPU performance, 80% higher multi threaded performance, over 100% higher GPU performance and a far better cellular radio. It also finally has MTE. The next gen is what will be in the first Motorola with GrapheneOS. Pixel 9a and earlier (including Nexus devices) were the Android Open Source Project reference devices. Pixel support was removed from AOSP with Android 16. It's now harder to support Pixels than many other devices and massive progress towards open source firmware and driver libraries was discarded. Compared to the stock Pixel OS, GrapheneOS ships AOSP patches months earlier and Linux kernel patches many months earlier. However, we rely on them for firmware and most driver updates. We also want to move to new kernel branches earlier. These things can be improved with our Motorola partnership. We strongly recommend against buying Pixel 11 devices. Pixel 8, 9 and 10 have much better overall security for GrapheneOS. Pixel 10 is cheaper with similar hardware and MTE. Pixel 11's Titan M3 should improve BFU security for users without a strong passphrase, but losing MTE craters AFU security. We haven't determined what to do about this situation. It may be best for us to skip the Pixel 11 series devices. We can shift our focus entirely to the upcoming Motorola devices instead. Pixel 10a was really a 9th gen Pixel, so hopefully the Pixel 11a does the same with 10th gen and includes MTE. --- <https://bsky.app/profile/grapheneos.org/post/3mua32q4ds22e> <https://grapheneos.social/@GrapheneOS/117179231167297908> <https://x.com/GrapheneOS/status/2093731615243411862> - Reply	finnlab	437	293
🟧 echo.blog ⭐	GrapheneOS: 'Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped' — 'It appears Google cut an important security	GrapheneOS (project forum account)	—	—

source

object

author

score

comments

🟧 hn

Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped

Retrieved article excerpt

Open article · Retrieved 2026-10-05T15:31:00.198612+00:00

- ### [GrapheneOSGrapheneOS](https://discuss.grapheneos.org/u/GrapheneOS)
- 30 Aug

Post #1 Sunday, August 30, 2026 2:20 AM
- Edited

We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money.

ARM hardware memory tagging (MTE) is used by GrapheneOS across the entire base OS including the kernel and every standard base OS process. It's only temporarily disabled for a few device-specific processes. It greatly improves protection against nearly all remote exploits and many local exploits.

Pixel 8 launched with hardware MTE support in October 2023. We integrated it into our hardened\_malloc project and began using it across the OS later that month. Android and the Pixel OS never started using it by default. Android Advanced Protection Mode in Android 16 enables it for a few processes.

Apple's Memory Integrity Enforcement (MIE) is an always enabled feature on the iPhone 17. It's simply a high quality implementation of MTE using the latest standard extensions. It uses MTE in the most secure mode in the kernel and a large portion of userbase. They did a very good job integrating it.

Apple's MIE and Android 16+ AAPM don't use MTE for user installed apps unless those explicitly opt in. GrapheneOS enables it for more apps automatically and has a toggle for users to opt-in for every user installed app. There's a per-app toggle to opt-out for incompatible apps which is uncommon.

Neither iOS or Android encourage app developers to opt into MTE and other more aggressive security features used in the base OS. Apple's docs warn developers of performance and stability issues. Our approach enables forcing using MTE in the standard allocators regardless.

Pixel 11 does have security improvements including moving to post-quantum secure verified boot (ML-DSA) and replacing Samsung Shannon IMS with AOSP IMS. Titan M3 should significantly improve protection against data extraction in Before First Unlock state. It's too bad they ruined it by cutting MTE.

Pixel 11 series is a lot more expensive for an incremental improvement to the CPU, the same underpowered GPU and reduced RAM for the Pro base models. They finally caught up to the last generation of Qualcomm cellular radio. It's overpriced, the upgrades aren't impressive and losing MTE is appalling.

Compared to the Pixel 11, a Snapdragon 8 Elite Gen 5 has 40% higher single threaded CPU performance, 80% higher multi threaded performance, over 100% higher GPU performance and a far better cellular radio. It also finally has MTE. The next gen is what will be in the first Motorola with GrapheneOS.

Pixel 9a and earlier (including Nexus devices) were the Android Open Source Project reference devices. Pixel support was removed from AOSP with Android 16. It's now harder to support Pixels than many other devices and massive progress towards open source firmware and driver libraries was discarded.

Compared to the stock Pixel OS, GrapheneOS ships AOSP patches months earlier and Linux kernel patches many months earlier. However, we rely on them for firmware and most driver updates. We also want to move to new kernel branches earlier. These things can be improved with our Motorola partnership.

We strongly recommend against buying Pixel 11 devices. Pixel 8, 9 and 10 have much better overall security for GrapheneOS. Pixel 10 is cheaper with similar hardware and MTE. Pixel 11's Titan M3 should improve BFU security for users without a strong passphrase, but losing MTE craters AFU security.

We haven't determined what to do about this situation. It may be best for us to skip the Pixel 11 series devices. We can shift our focus entirely to the upcoming Motorola devices instead. Pixel 10a was really a 9th gen Pixel, so hopefully the Pixel 11a does the same with 10th gen and includes MTE.

---

<https://bsky.app/profile/grapheneos.org/post/3mua32q4ds22e>
<https://grapheneos.social/@GrapheneOS/117179231167297908>
<https://x.com/GrapheneOS/status/2093731615243411862>

- Reply

finnlab

437

293

🟧 echo.blog ⭐

GrapheneOS: 'Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped' — 'It appears Google cut an important security

GrapheneOS (project forum account)

—

Interpretation history

2026-10-08T02:42:30Z
HN discussion continues growing (437/293, velocity spike detected) but the core technical question — whether Pixel 11 silicon lacks MTE or merely has it firmware-disabled — remains unresolved; GrapheneOS has not formally decided to skip the generation, and no new Google firmware release has definitively restored MTE.
2026-10-05T15:42:06Z
grounded: known/low — GrapheneOS publicly enforcing a versioned hardware-security bar — failing the Pixel 11, telling buyers to stay away, and second-sourcing Motorola rather than so
2026-10-05T15:32:12Z
case created — The hardened-Android reference implementation is publicly failing a new Google flagship over a cut hardware security feature and may skip it — a consequential, resolvable platform-security episode with transferable hardware-security lessons, now actively echoed on HN (162/97).

Decision trace

10-08 13:46attention_routeThe editor compared this story and chose to keep watching.
10-08 13:42attention_candidatecoverage review: magnitude valve eligible (multi-platform, top-decile engagement); not yet communicated
10-08 13:42repriceHN discussion continues growing (437/293, velocity spike detected) but the core technical question — whether Pixel 11 silicon lacks MTE or merely has it firmware-disabled — remains unresolved; Graphen
10-06 07:22sensor_dirtyvelocity_spike
10-06 04:21sensor_dirtycomment_update
10-06 02:42groundGrapheneOS publicly enforcing a versioned hardware-security bar — failing the Pixel 11, telling buyers to stay away, and second-sourcing Motorola rather than soften — restates a position Scott's
10-06 02:32createThe hardened-Android reference implementation is publicly failing a new Google flagship over a cut hardware security feature and may skip it — a consequential, resolvable platform-security episode wit