Google Just Made the Pixel 11 Less Secure: Removing ARM MTE Is a Huge Mistake

The Pixel 11 was supposed to move Google’s security story forward. Instead, one of the most important hardware protections introduced with recent Pixel generations has reportedly disappeared.

According to a GrapheneOS project discussion, the Pixel 11 generation does not provide ARM hardware Memory Tagging Extension support, better known as MTE. The missing feature is serious enough that the GrapheneOS team says the devices do not meet its security requirements and may be skipped entirely.

That is not a minor compatibility complaint. It is a warning from a project that has spent years hardening Android against real-world exploitation.

Google may point to newer security improvements, including quantum-resistant cryptography and other forward-looking protections. Those developments matter. I’m not arguing otherwise.

But quantum-resistant cryptography is mostly about preparing for a future threat. MTE helps defend the device in your pocket against memory corruption attacks today.

Removing it is bad. Really bad.

And no amount of futuristic security branding changes that.

What reportedly changed with the Pixel 11

Starting with the Pixel 8 generation, Google’s phones moved to newer ARM CPU cores with hardware memory tagging support. That allowed Android and alternative operating systems such as GrapheneOS to use MTE as a practical exploit mitigation.

GrapheneOS considers hardware memory tagging important enough to list it as a requirement for future supported devices. Its documentation specifically describes the feature as an “incredibly powerful” hardware security capability and says it is enabled by default to protect compatible operating system components and user-installed apps.

The Pixel 11 generation reportedly breaks that progression.

At the time of writing, the key public claim comes from the GrapheneOS project discussion. Google’s own detailed technical explanation for the missing MTE support is not available there, so I would be careful about inventing a motive. It could involve Google’s SoC choices, CPU core configuration, performance priorities, implementation cost, or something else entirely.

The reason matters, but the result matters more.

If the hardware does not support MTE, an operating system cannot add it later with a software update. GrapheneOS cannot patch around the missing CPU feature. Google cannot quietly enable it in a future Android release. A userspace allocator cannot emulate the same protection with the same security and performance properties.

The silicon either supports hardware tag checking or it does not.

That is why this is a hardware security regression rather than a missing launch feature.

MTE is not just another security acronym

Memory safety bugs have been one of the biggest sources of serious vulnerabilities for decades.

Languages such as C and C++ give developers direct control over memory. That control is useful for performance and low-level systems programming, but it also creates entire categories of bugs:

• Buffer overflows
• Buffer underflows
• Use-after-free vulnerabilities
• Invalid pointer accesses
• Out-of-bounds reads and writes
• Heap memory corruption

Android contains a huge amount of native code. The kernel, hardware abstraction layers, media components, graphics stack, drivers, networking services, vendor components, and many performance-sensitive libraries all operate close to the hardware.

A single memory corruption bug does not automatically equal a full device compromise. Modern Android has sandboxing, SELinux, control-flow protections, verified boot, address-space randomization, and many other defenses.

But memory corruption is often where an exploit chain begins.

An attacker finds a bug in a component that processes untrusted data. Maybe it is an image decoder, browser engine, GPU driver, Bluetooth implementation, baseband-related interface, or media service. The attacker then attempts to turn that bug into something useful, such as arbitrary code execution.

MTE makes that process harder.

How ARM Memory Tagging Extension works

At a high level, MTE associates a small tag with a region of memory and another tag with the pointer used to access that memory.

When the CPU performs a memory load or store, it checks whether the pointer tag matches the tag assigned to the memory.

Conceptually, it looks like this:

Pointer tag: 0xA
Memory tag:  0xA
Result:      Access allowed

If a stale or corrupted pointer carries the wrong tag, the hardware detects the mismatch:

Pointer tag: 0x4
Memory tag:  0xB
Result:      Tag mismatch

Depending on the configured MTE mode, the process can be terminated immediately or the fault can be reported asynchronously.

This is especially useful for two common classes of bugs.

Use-after-free

A program allocates an object and receives a pointer to it. Later, the object is freed, but some part of the program still holds the old pointer.

Without additional protection, that stale pointer might access memory that has since been reused for another object. An attacker may be able to manipulate that reuse and turn the bug into controlled memory corruption.

With MTE, the allocator can assign a new tag when the memory is reused. The old pointer still carries the previous tag, so the CPU notices that it no longer matches.

The stale pointer becomes much less useful.

Buffer overflows

Suppose code allocates a buffer and then writes beyond its boundary. If the neighboring allocation has a different tag, crossing into that allocation causes a mismatch.

Again, MTE does not magically prove that every memory access is correct. It has granularity and probability limitations, and some invalid accesses may remain within the same tagged region.

But it puts another hardware-enforced obstacle between a bug and a working exploit.

That is exactly what defense in depth is supposed to do.

MTE can stop exploitation, not just find bugs

MTE is sometimes discussed as if it were primarily a developer debugging feature. That undersells it.

Yes, MTE is excellent for finding memory bugs during development and testing. Android’s documentation strongly recommends synchronous MTE during development because it can stop the process at the invalid access and provide useful diagnostic information.

But MTE can also run in production.

Android documents three primary operating modes:

• SYNC, which reports the fault precisely and terminates the process immediately
• ASYNC, which reduces performance cost but reports the fault later
• ASYMM, which uses synchronous checks for reads and asynchronous checks for writes

Google’s Android documentation recommends asynchronous MTE in production as a low-overhead memory safety defense. For especially sensitive processes, synchronous checking can be worth the additional cost.

GrapheneOS goes further by using hardware memory tagging as a real exploit mitigation, not merely a crash-reporting mechanism.

That distinction matters.

A debugging feature tells developers that something went wrong. A security mitigation tries to make sure an attacker cannot successfully exploit what went wrong.

MTE can do both.

It is not perfect, and that is not an excuse to remove it

No serious security feature provides absolute protection.

MTE uses a limited tag space. Depending on the allocation strategy, an attacker may have some probability of correctly guessing a tag. MTE also works at a defined memory granularity, so it cannot detect every small out-of-bounds access within the same granule.

It will not fix logical vulnerabilities.

It will not stop a developer from accidentally exposing sensitive data through a badly designed API.

It will not replace sandboxing, control-flow integrity, pointer authentication, safe languages, or timely security updates.

None of this makes MTE unimportant.

Security is not a search for one perfect shield. Modern exploit resistance comes from stacking independent defenses until turning a vulnerability into a reliable compromise becomes expensive, unstable, or impossible.

An attacker may have to:

1. Find a reachable memory corruption bug.
2. Bypass the application sandbox.
3. Defeat address-space randomization.
4. Work around control-flow protections.
5. Avoid MTE tag mismatches.
6. Escape into a more privileged process.
7. Survive additional kernel and hardware defenses.
8. Establish persistence despite verified boot.

Remove one of those layers and the attacker has less work to do.

It does not matter that the removed layer was not perfect. Seat belts are not useless because cars also have airbags. Sandboxing is not useless because sandbox escapes exist. MTE is not useless because a determined attacker may sometimes work around it.

The whole point is to make exploitation harder.

Software cannot fully compensate for missing hardware MTE

Android has other approaches for detecting memory corruption.

Tools such as AddressSanitizer, Hardware-assisted AddressSanitizer, and various allocator hardening techniques can catch bugs or make exploitation more difficult. GrapheneOS also has its own hardened memory allocator.

These are valuable, but they are not interchangeable with production-ready hardware tagging.

Traditional sanitizers often carry too much memory or performance overhead for broad use on a consumer phone. Software-based mitigations can also lack the direct, per-access CPU enforcement that makes MTE useful.

Rust and other memory-safe languages are another major part of the solution. Google has already been moving new Android code toward memory-safe implementations, and that is absolutely the right direction.

But rewriting a platform the size of Android takes years. Vendor drivers, native libraries, the Linux kernel, hardware interfaces, and third-party components do not suddenly become memory safe because Google wrote more new code in Rust.

Even in a mostly memory-safe system, unsafe boundaries still exist.

MTE protects the large body of native code that exists now. It also protects software that will not be rewritten anytime soon.

The choice should never have been “Rust or MTE.” We need both.

Use memory-safe languages to prevent new bugs. Use hardware tagging to catch and mitigate the memory bugs that remain.

Why the GrapheneOS reaction matters

GrapheneOS does not support a device simply because it can boot Android.

Its hardware requirements cover long-term firmware updates, verified boot, rollback protection, secure elements, hardware-backed key storage, radio isolation, virtualization, USB attack-surface controls, modern kernel support, and multiple processor-level exploit mitigations.

Hardware memory tagging is explicitly on that list.

The project also says Pixel 8 and later devices use MTE by default for the base operating system and known-compatible apps, with an option to enable it more broadly.

So when GrapheneOS says the Pixel 11 does not meet its standards and may be skipped, this is not a dramatic response to a missing checkbox. Supporting the phone without MTE would mean lowering a security requirement that the project has already established.

I think refusing to quietly lower that standard is the correct response.

Otherwise, hardware vendors learn that security features are optional. They can promote them for a few generations, remove them when inconvenient, and assume everyone will update the marketing slides instead of asking difficult questions.

Skipping a major Pixel generation would be painful for GrapheneOS. Pixels have historically been the main practical hardware platform for the project. A skipped generation could affect users, testing capacity, device availability, and the project’s long-term support planning.

That makes the warning more credible, not less.

There is no obvious benefit for GrapheneOS in refusing to support popular new hardware. If the team is willing to consider doing that, the missing capability is clearly not viewed as cosmetic.

The Pixel 11 may still have strong security

This needs to be said clearly: the absence of MTE does not automatically make the Pixel 11 an insecure phone.

Security is not binary.

The Pixel 11 may still include:

• A hardened Android security model
• Strong application sandboxing
• Verified boot and rollback protection
• Hardware-backed key storage
• A dedicated secure element
• Pointer authentication
• Branch target identification
• Regular security updates
• Improved baseband and subsystem isolation
• Better virtualization
• New cryptographic protections

Depending on the alternatives, it may still be more secure than many competing phones.

But “still secure overall” and “a meaningful security regression” can both be true.

That nuance often gets lost in product coverage. Reviews reduce security to the number of promised update years or whether a phone has a security chip with a cool name.

Those things matter, but they do not tell the whole story.

A device can gain new defenses while losing an existing one. If the lost defense addresses a major source of current vulnerabilities, users deserve to know.

Quantum-resistant security does not replace MTE

Google’s work on post-quantum cryptography is valuable. Powerful quantum computers could eventually threaten widely used public-key cryptographic systems.

The industry cannot wait until a cryptographically relevant quantum computer appears before starting the transition. New algorithms need standardization, implementation, testing, deployment, and years of compatibility work.

There is also a real “harvest now, decrypt later” concern. Attackers can collect encrypted data today and hope to decrypt it in the future once the required technology exists.

Preparing early is responsible engineering.

But post-quantum cryptography and memory tagging solve entirely different problems.

Quantum-resistant cryptography protects cryptographic operations against a future class of computational attacks. MTE helps prevent attackers from exploiting memory corruption vulnerabilities running on the device right now.

One protects keys, signatures, or encrypted communication against future quantum capabilities.

The other can stop a malicious input from turning a use-after-free bug into code execution today.

You cannot compensate for weaker memory safety by adding stronger cryptography.

If an attacker exploits a process and gains access to sensitive data after it has already been decrypted, the mathematical strength of the encryption algorithm is not the issue. Cryptography protects data in transit and at rest. It does not automatically protect data while compromised software is actively using it.

That is why presenting quantum-resistant features as a counterweight to losing MTE would be misleading.

It would be like removing the locks from your front door and proudly announcing that the basement will be protected against a new drilling technology that may become practical years from now.

Great work on the basement. I still want the front door locked.

MTE protects against the boring bugs attackers actually use

Security marketing loves exotic threats.

Quantum computers sound futuristic. AI-powered attacks sound inevitable. Satellite communication security makes for great launch-event material.

Memory corruption sounds old and messy.

That is exactly why it is dangerous to underestimate it.

Use-after-free bugs and out-of-bounds accesses are not hypothetical. They keep appearing in browsers, operating system kernels, media frameworks, drivers, and vendor components. Attackers do not care whether a vulnerability sounds exciting. They care whether it gives them execution.

A new phone should not trade a practical mitigation against current exploit techniques for a cleaner benchmark result, cheaper CPU configuration, or easier hardware integration.

To be clear, Google has not publicly established that any of those were the reason. I am not claiming to know why MTE is reportedly missing.

I am saying that the bar for removing it should be extremely high.

If there is another hardware mechanism providing equivalent or stronger protection, Google should document it in technical detail. It should explain which memory corruption classes are covered, whether enforcement works on every relevant load and store, how Android enables it, what the performance tradeoffs are, and whether alternative operating systems can use it.

A vague promise of “enhanced security” is not enough.

This also hurts developers

MTE does more than protect end users after a product ships.

When developers can run real software under synchronous hardware tagging, memory bugs become easier to reproduce and diagnose. Instead of discovering silent heap corruption several operations after the original invalid access, the process can stop close to the exact instruction that caused the problem.

That produces better crash reports and shorter debugging sessions.

More importantly, broad MTE use creates real-world coverage that internal testing cannot reproduce. Users exercise strange combinations of features, data, apps, locales, peripherals, network conditions, and timing behavior.

Google’s own Android documentation points out that development tests may not cover every user scenario. That is one reason production MTE is useful.

Removing hardware support does not just weaken exploit resistance on one phone. It removes that phone generation from the pool of devices capable of finding and containing these bugs through hardware tagging.

For an ecosystem as large as Android, that loss adds up.

The precedent worries me most

Hardware security features need continuity.

Developers need to know that a mitigation introduced today will still exist in the next hardware generation. Operating system projects need that continuity before making a feature part of their security architecture. App developers need enough compatible devices to justify testing and enabling it.

The Pixel 8 generation made MTE feel like the beginning of a stronger Android baseline. Pixel 9 and Pixel 10 devices continued to meet GrapheneOS requirements.

If Pixel 11 drops it, the message is awful: do not assume a valuable security primitive will survive even a few product cycles.

That discourages adoption.

Why should an app developer invest time testing MTE compatibility if Google may ship its flagship hardware without it? Why should operating system developers design stronger default policies around a feature that can disappear? Why should users believe claims about hardware-backed protection if those claims come with an invisible expiration date?

Security capabilities should become more common and more mature over time. They should not vanish without a technically convincing replacement.

What Google should do now

First, Google should clearly confirm or deny whether every Pixel 11 model lacks hardware MTE support.

If some models or CPU cores support it and others do not, that needs to be documented too. Partial support can create its own limitations, especially when processes move between heterogeneous CPU cores.

Second, Google should explain the technical reason.

Not in marketing language. Not with a statement about a “multi-layered approach.” Developers need the actual architecture-level explanation.

Third, if another mitigation replaces MTE, Google should publish enough information for independent security researchers and projects such as GrapheneOS to evaluate it.

The replacement should also be available to alternative operating systems. A hardware feature locked behind proprietary stock firmware is not equivalent if GrapheneOS cannot use it.

Finally, Google should restore MTE support in the next revision if there is no equivalent replacement.

Security regressions should be treated as regressions, even when the rest of the product gets faster.

Should you avoid the Pixel 11?

For an average user running stock Android, the answer depends on the complete security picture, update policy, competing devices, and the eventual technical details.

I would not claim that everyone who buys a Pixel 11 is immediately in danger. That would be irresponsible.

But security-conscious buyers should absolutely pause.

If you want to run GrapheneOS, do not assume Pixel 11 support is coming. Wait for an official decision from the project before buying the device. A bootloader that can be unlocked does not guarantee GrapheneOS support, and buying hardware based on an expected future port is always a gamble.

If hardware memory tagging matters to you, the existing Pixel generations supported by GrapheneOS may be the safer choice until the Pixel 11 situation is fully explained.

And if Google eventually confirms that MTE is gone without providing an equivalent mitigation, I would consider that a legitimate reason to skip the generation.

Not because the Pixel 11 has no security.

Because buyers of a premium security-focused phone should not have to accept fewer defenses against one of the most persistent classes of software vulnerabilities.

A shiny future does not excuse weaker security today

I like that Google is investing in quantum-resistant cryptography. The transition to post-quantum systems is necessary, difficult, and easy to postpone until it becomes an emergency.

But security engineering is not a choice between the future and the present.

We need cryptography that can survive tomorrow’s quantum attacks. We also need hardware defenses that make today’s memory corruption bugs harder to exploit.

MTE is not a theoretical feature waiting for a future threat model. It is usable now. Android supports it now. GrapheneOS uses it now. It addresses bug classes attackers target now.

That is why the reported Pixel 11 decision looks so bad.

A new generation of hardware should not force a security-focused operating system to choose between lowering its standards and abandoning the device. A flagship phone should not move backward on practical exploit mitigations while its marketing moves forward.

Until Google provides a convincing technical explanation or an equally strong replacement, removing hardware MTE deserves to be called what it is:

A serious security regression.

Sources

• GrapheneOS discussion: Pixel 11 doesn’t meet the GrapheneOS security standards and may be skipped
• Android Open Source Project: ARM Memory Tagging Extension
• GrapheneOS FAQ: Supported devices and hardware security requirements
• Arm: Enhancing memory safety with Memory Tagging Extension
• Android Developers: Memory Tagging Extension for native apps
• Google Security Blog: Rust in the Android platform
• Author's Website