The Pixel 11 does not support ARM's Memory Tagging Extension, and GrapheneOS says that's not a bug or an oversight. In a statement that circulated widely after it landed on Bluesky and got picked apart on Hacker News, the hardened Android fork's developers put it bluntly: "It appears Google cut an important security feature to save money."

  • GrapheneOS reports the Pixel 11 lacks MTE in software, firmware, and almost certainly hardware, the first Pixel since the 8 series to drop it.
  • MTE is a chip-level feature that catches memory corruption bugs, the kind that power a huge share of real-world exploits, before they can be weaponized.
  • Pixel 8, 8 Pro, 8a, the 9 series, 9a, and the 9 Pro Fold all shipped with hardware MTE, which GrapheneOS has enabled by default since Pixel 8 launched.
  • The move breaks GrapheneOS's long-standing pitch that Pixels are the only Android phones meeting all of its firmware, driver, and hardware security requirements.

What is ARM's Memory Tagging Extension, and why does it matter?

Most of Android's operating system and a large chunk of its native code is written in C and C++, languages that hand memory management to the programmer instead of doing it automatically. That flexibility is also where a huge fraction of serious security bugs come from: use-after-free errors, buffer overflows, out-of-bounds reads. Get one of those wrong and an attacker can often turn it into arbitrary code execution.

RelatedOne GitHub issue, RCE on Claude Code and Gemini CLI runners

MTE, introduced as part of ARMv8.5-A, attacks that problem at the hardware level. Every 16-byte chunk of memory, a granule, gets tagged with a small numeric value. Pointers carry a matching tag. When code tries to read or write through a pointer, the CPU checks whether the pointer's tag matches the granule's tag. Mismatch, and the chip faults immediately instead of letting the access silently corrupt memory. A dangling pointer to freed memory, or a pointer that's wandered past the end of a buffer, gets caught at the moment it misbehaves rather than three function calls later when the damage is already done.

How ARM Memory Tagging Extension checks pointer access Two panels. Left: a pointer tagged 3 accesses a memory granule also tagged 3, tags match, access is granted. Right: a stale pointer tagged 7 tries to access a granule now tagged 3, tags mismatch, the hardware faults and blocks the access. ARM Memory Tagging Extension HOW TAG MATCHING CATCHES A STRAY POINTER VALID ACCESS pointer tag = 3 granule tag = 3 tags match access granted STALE / DANGLING POINTER pointer tag = 7 granule tag = 3 tags mismatch HARDWARE FAULT: BLOCKED genztech.blog
Fig 1 A pointer's tag has to match the tag on the memory it points to. When an old, freed, or out-of-bounds pointer carries a different tag, the CPU faults on contact instead of letting the access corrupt memory silently.

GrapheneOS turns MTE on by default across the base OS and extends its protection to any compatible app a user installs, which is a big part of why security researchers and high-risk users (journalists, activists, people who assume they're a target) gravitate toward it. It's not a theoretical feature. It closes off entire exploit chains that would otherwise rely on precisely this class of bug.

From Pixel 8 to Pixel 11: the MTE timeline

Hardware MTE arrived on Google's Tensor G3 and has stuck around through G4 and G5, until now.

  1. Pixel 8 / 8 Pro (2023)Tensor G3 ships with hardware MTE support GrapheneOS adopts it by default at launch
  2. Pixel 8a (2024)MTE support carries over on the same Tensor G3 silicon No regression
  3. Pixel 9 series, 9a, 9 Pro Fold (2024 to 2025)Tensor G4 keeps hardware MTE intact GrapheneOS's "hardware requirements met" claim continues to hold
  4. Pixel 11 (2026)GrapheneOS reports no MTE support in software, firmware, or hardware First regression since Pixel 8, breaking a six-generation streak

Why would Google cut this from the Pixel 11?

GrapheneOS's own framing is the only stated reason on record, and it's a cost one: cutting a feature to save money. There's no official Google explanation to weigh against that, and Google hasn't been reported as commenting on the claim at all, so treat "why" as GrapheneOS's read on the situation rather than a confirmed corporate rationale.

That said, the timing lines up with something else. A PiunikaWeb report from January 2026 had already floated the idea that the Pixel 11 could be the last new Pixel generation to get GrapheneOS support, pointing to broader doubts about whether GrapheneOS can keep pace with future Pixel hardware changes. An MTE regression on the very device that report was worried about doesn't prove a wider pullback from hardware security investment, but it's the kind of data point that makes the earlier warning look less speculative in hindsight.

Who does this actually affect?

Directly, GrapheneOS users buying or planning to buy a Pixel 11. That's a small slice of the overall Android market by unit count, but it's a slice that skews toward people with genuinely elevated threat models: security researchers, reporters handling sensitive sources, activists in hostile jurisdictions, and just privacy-conscious buyers who chose Pixel hardware specifically because GrapheneOS could run on it with every security box checked. For that group, hardware MTE wasn't a nice-to-have. It was often the reason Pixel was the only phone on the shopping list.

RelatedOpenAI Mandates Hardware Passkeys for Cyber Access

Indirectly, this matters to anyone paying attention to where Google is putting its hardware security budget. Pixel has functioned as Android's reference security platform, the device other Android vendors and even Google's own stock-Android messaging point to. If a security feature can get quietly dropped from a flagship generation without pushback strong enough to reverse it, that's a signal worth watching even for people who will never install a custom ROM.

How does this compare to what Apple is doing?

Apple's answer to the same class of problem is Memory Integrity Enforcement, introduced with the iPhone 17 lineup and the A19 chip. MIE also uses tagged pointers to catch memory-safety violations, though its enforcement points and defaults differ from ARM's MTE implementation in the details. The headline difference isn't technical, it's philosophical: Apple made MIE always-on by default on its newest flagship silicon. Google, on the reporting available, is moving the Pixel line the opposite direction at almost the exact same moment.

Nobody needs to declare an outright winner here. But one company is expanding hardware memory-safety protection as a default, and the other appears to be retracting it from its highest-end new device. That contrast is going to be hard for security-focused reviewers to ignore.

Our take

Cost pressure on flagship hardware is real, and not every feature survives every product cycle. But MTE wasn't a cosmetic extra. It was one of the more consequential mobile hardware security advances of the last decade, and Google spent three Pixel generations building a reputation around supporting it fully. Cutting it on the Pixel 11, without comment, undercuts the exact pitch that made Pixel the default recommendation for the highest-scrutiny Android users. GrapheneOS calling it out publicly, in blunt terms, is the correct response. Whether Google walks it back, offers a fix in a later hardware revision, or just lets the claim quietly go away is the thing to watch next.

What to watch · 2026-2027
  • Whether Google issues any public statement or clarification on the Pixel 11's MTE status.
  • Whether GrapheneOS revises its official supported-device security requirements to reflect the gap.
  • Whether a later Pixel 11 hardware revision or a Pixel 11a variant restores hardware MTE.
  • Whether other Android OEMs follow Google's Tensor lead or hold the line on MTE support.
Primary sources

Original analysis by GenZTech.