Somewhere inside Samsung’s software labs, engineers have been wiring up one of the most consequential hardware security features to arrive on Android phones in years. It’s called Memory Tagging Extension, or MTE, and evidence now suggests it will ship as part of One UI 9 — Samsung’s next major software update built atop Android 16. The implications stretch far beyond a single manufacturer. If Samsung activates MTE at scale across its massive installed base, it could force a reckoning with the memory safety vulnerabilities that have plagued mobile software for decades.
The discovery comes from Android Authority, whose reporters found references to MTE buried in Samsung’s latest One UI 9 beta firmware. Specifically, the publication identified a new toggle in developer options labeled “MTE status” with the ability to switch the feature on or off. The firmware in question targets the Galaxy S25 series, which runs on the Snapdragon 8 Elite chipset — hardware that supports Arm’s MTE specification. Right now, the toggle appears limited to developer options, meaning average consumers won’t see it. But its mere presence signals Samsung’s intent to eventually bring the feature into the mainstream.
So what exactly is MTE? At its core, it’s an Arm v8.5-A architecture extension designed to catch memory safety bugs — the kind of vulnerabilities responsible for the majority of critical security exploits on Android. Think buffer overflows, use-after-free errors, and heap corruption. These aren’t theoretical threats. Google’s own Project Zero team has repeatedly documented how memory safety flaws account for roughly 70% of serious security vulnerabilities in large codebases written in C and C++. Android’s native layer is heavily built in those languages.
MTE works by assigning random four-bit tags to memory allocations and their corresponding pointers. Every time software accesses memory, the hardware checks whether the pointer’s tag matches the memory’s tag. A mismatch triggers a fault. The elegance of the approach lies in its speed — because the tagging and checking happen in hardware, the performance overhead is dramatically lower than software-based memory safety tools like AddressSanitizer, which can slow execution by 2x or more. MTE’s overhead has been estimated in various benchmarks at roughly 1-3% in synchronous mode, though real-world impact varies by workload.
Google has been laying the groundwork for this moment for years. Android 14 introduced initial MTE support, allowing developers to enable the feature on compatible Pixel devices. The Pixel 8 was the first commercial phone to ship with MTE hardware support, courtesy of Google’s Tensor G3 chip. But Google kept MTE confined to developer settings and per-app opt-in configurations, treating it as an advanced debugging and hardening tool rather than a consumer-facing feature. Android 15 expanded support further. And Android 16, the foundation for One UI 9, is expected to push the boundaries even more.
Samsung’s move matters because of sheer scale. Google’s Pixel phones are influential but represent a small fraction of global Android shipments. Samsung commands roughly 20% of the worldwide smartphone market, according to recent IDC estimates. If MTE shows up on Galaxy S25 devices — and potentially future A-series and Galaxy Z models — hundreds of millions of devices could gain hardware-enforced memory safety within a few product cycles. That changes the calculus for attackers. Exploits that rely on memory corruption become significantly harder to execute reliably when the hardware itself is actively checking every memory access.
The timing aligns with a broader industry push. Arm has been vocal about MTE’s potential since announcing the extension in 2018, and the company has steadily expanded support across its Cortex-A and Cortex-X core designs. Qualcomm’s Snapdragon 8 Gen 3 and Snapdragon 8 Elite both include MTE-capable cores. MediaTek’s Dimensity 9300 and 9400 series are also believed to support the extension, though activation depends on OEM firmware choices. The hardware is ready. The question has always been whether software makers would flip the switch.
There are complications. MTE in its current form isn’t a silver bullet. The four-bit tag space means there are only 16 possible tag values, giving an attacker a 1-in-16 (roughly 6.25%) chance of guessing the correct tag on any single attempt. That’s not airtight. In synchronous mode, where every memory access is checked immediately, the security is strongest but the performance cost is highest. Asynchronous mode reduces overhead but delays fault detection, potentially allowing some exploits to slip through before the system catches the mismatch. Samsung and Google will need to decide which mode to enable by default — and whether to let users or enterprise IT administrators toggle between them.
A related concern is app compatibility. MTE can surface latent memory bugs in applications that have run fine for years despite technically containing unsafe memory operations. Enable MTE system-wide and some apps will crash. That’s actually the feature working as intended — those crashes indicate real bugs that could be exploited — but it creates a user experience problem. Samsung, which is famously protective of its consumer experience, will likely proceed cautiously. The developer options placement in the current beta suggests the company is testing the waters before committing to broader activation.
Google’s Android Security team published a detailed blog post in 2023 outlining the real-world performance of MTE on Pixel hardware, noting that enabling MTE across system processes caught previously unknown vulnerabilities during internal testing. The team described finding bugs that had existed undetected in production code — bugs that traditional fuzzing and static analysis had missed. Hardware-enforced memory tagging found them immediately. That’s a powerful argument for broad deployment.
The competitive dynamics are interesting too. Apple doesn’t use MTE. Instead, Cupertino has invested in Pointer Authentication Codes (PAC) since the A12 Bionic chip in 2018, along with more recent Memory Tagging–adjacent protections in Apple Silicon. PAC operates differently — it cryptographically signs pointers rather than tagging memory regions — and has its own strengths and weaknesses. Security researchers have demonstrated PAC bypasses, most notably the PACMAN attack disclosed by MIT researchers in 2022. Neither approach is perfect. But MTE’s ability to detect spatial and temporal memory errors gives it a broader detection surface than PAC alone.
Android’s adoption of MTE also has implications for the broader software supply chain. App developers writing native code — particularly game studios, media codec developers, and companies building performance-sensitive SDKs — will face increasing pressure to ensure their code is MTE-clean. Google has already updated the Android NDK to support MTE testing, and the company’s CTS (Compatibility Test Suite) is expected to incorporate MTE checks in future Android versions. If Samsung enforces MTE in production builds, developers who ship memory-unsafe code will see their apps crash on flagship hardware. That’s a strong incentive to fix bugs.
Enterprise buyers may be the first constituency to benefit. Corporate-managed Galaxy devices running Samsung Knox could enable MTE in synchronous mode as a security policy, hardening the device against zero-day exploits targeting the native layer. For industries subject to stringent compliance requirements — finance, healthcare, government — this kind of hardware-backed memory safety is precisely the sort of feature that influences procurement decisions. Samsung’s enterprise team surely recognizes this.
Not everything about the One UI 9 discovery is clear yet. Android Authority noted that the feature appeared in beta firmware, and Samsung could still change its implementation before the stable release. The publication also pointed out that it’s uncertain whether MTE will be enabled by default for any system processes or whether it will remain entirely opt-in. Those details matter enormously. An MTE toggle buried in developer options that nobody turns on is a curiosity. MTE enabled by default across system daemons and security-critical services is a genuine advancement in device security.
The broader trajectory seems clear. Google wants MTE on. Arm wants MTE on. Qualcomm has built the silicon to support it. And now Samsung, the world’s largest Android manufacturer, is building the software infrastructure to activate it. The remaining questions are about pace, scope, and defaults — not direction.
For security researchers, MTE’s spread is a double-edged development. It raises the bar for exploitation, which is good for defenders. But it also means the exploits that do succeed — those that somehow account for or bypass MTE — will be more valuable and more sophisticated. The market price for a zero-click Android exploit chain, already in the millions of dollars according to brokers like Zerodium, could climb further as MTE shrinks the attack surface.
There’s a historical parallel worth considering. When stack canaries and ASLR (Address Space Layout Randomization) first shipped in mainstream operating systems in the mid-2000s, critics argued they were imperfect mitigations that determined attackers could bypass. That was true. But they still eliminated entire classes of low-sophistication attacks, dramatically raising the cost of exploitation across the board. MTE occupies a similar position today — imperfect in isolation, powerful in combination with other defenses, and most effective when deployed universally.
Samsung’s One UI 9, expected to roll out broadly later in 2025 alongside Android 16, will be one of the most closely watched Android releases in recent memory — not for flashy AI features or visual redesigns, but for what’s happening underneath. A hardware security feature, years in the making, is finally approaching mass deployment. The phones are ready. The chips are ready. And if Samsung commits, the rest of the Android world will have little choice but to follow.


WebProNews is an iEntry Publication