Memory Integrity Enforcement (MIE) is the culmination of an unprecedented design and engineering effort, spanning half a decade, that combines the unique strengths of Apple silicon hardware with our advanced operating system security to provide industry-first, always-on memory safety protection across our devices — without compromising our best-in-class device performance. We believe Memory Integrity Enforcement represents the most significant upgrade to memory safety in the history of consumer operating systems.
There has never been a successful, widespread malware attack against iPhone. The only system-level iOS attacks we observe in the wild come from mercenary spyware, which is vastly more complex than regular cybercriminal activity and consumer malware. Mercenary spyware is historically associated with state actors and uses exploit chains that cost millions of dollars to target a very small number of specific individuals and their devices. Although the vast majority of users will never be targeted in this way, these exploit chains demonstrate some of the most expensive, complex, and advanced attacker capabilities at any given time and are uniquely deserving of study as we work to protect iPhone users against even the most sophisticated threats. Known mercenary spyware chains used against iOS share a common denominator with those targeting Windows and Android: they exploit memory safety vulnerabilities, which are interchangeable, powerful, and exist throughout the industry.
For Apple, improving memory safety is a broad effort that includes developing with safe languages and deploying mitigations at scale. (For a primer on how we think about memory safety, see the opening of this post.) We created Swift, an easy-to-use, memory-safe language, which we employ for new code and targeted component rewrites. In iOS 15, we introduced kalloc_type, a secure memory allocator for the kernel, followed in iOS 17 by its user-level counterpart, xzone malloc. These secure allocators take advantage of knowing the type — or purpose — of allocations so that memory can be organized in a way that makes exploiting most memory corruption vulnerabilities inherently difficult.
In 2018, we were the first in the industry to deploy Pointer Authentication Codes (PAC) in the A12 Bionic chip, to protect code flow integrity in the presence of memory corruption. The strong success of this defensive mechanism in increasing exploitation complexity left no doubt that the deep integration of software and hardware security would be key to addressing some of our greatest security challenges. With PAC behind us, we immediately began design and evaluation work to find the most effective way to build sophisticated memory safety capabilities right into Apple silicon.
Arm published the Memory Tagging Extension (MTE) specification in 2019 as a tool for hardware to help find memory corruption bugs. MTE is, at its core, a memory tagging and tag-checking system, where every memory allocation is tagged with a secret; the hardware guarantees that later requests to access memory are granted only if the request contains the correct secret. If the secrets don’t match, the app crashes, and the event is logged. This allows developers to identify memory corruption bugs immediately as they occur.
We conducted a deep evaluation and research process to determine whether MTE, as designed, would meet our goals for hardware-assisted memory safety. Our analysis found that, when employed as a real-time defensive measure, the original Arm MTE release exhibited weaknesses that were unacceptable to us, and we worked with Arm to address these shortcomings in the new Enhanced Memory Tagging Extension (EMTE) specification, released in 2022. More importantly, our analysis showed that while EMTE had great potential as specified, a rigorous implementation with deep hardware and operating system support could be a breakthrough that produces an extraordinary new security mechanism.
Consider that MTE can be configured to report memory corruption either synchronously or asynchronously. In the latter mode, memory corruption doesn’t immediately raise an exception, leaving a race window open for attackers. We would not implement such a mechanism. We believe memory safety protections need to be strictly synchronous, on by default, and working continuously. But supporting always-on, synchronous MTE across key attack surfaces while preserving a great, high-performance user experience is extremely demanding for hardware to support.
In addition, for MTE to provide memory safety in an adversarial context, we would need to finely tune the operating system to defend the new semantics and the confidentiality of memory tags on which MTE relies. Ultimately, we determined that to deliver truly best-in-class memory safety, we would carry out a massive engineering effort spanning all of Apple — including updates to Apple silicon, our operating systems, and our software frameworks. This effort, together with our highly successful secure memory allocator work, would transform MTE from a helpful debugging tool into a groundbreaking new security feature.
Today we’re introducing the culmination of this effort: Memory Integrity Enforcement (MIE), our comprehensive memory safety defense for Apple platforms. Memory Integrity Enforcement is built on the robust foundation provided by our secure memory allocators, coupled with Enhanced Memory Tagging Extension (EMTE) in synchronous mode, and supported by extensive Tag Confidentiality Enforcement policies. MIE is built right into Apple hardware and software in all models of iPhone 17 and iPhone Air and offers unparalleled, always-on memory safety protection for our key attack surfaces including the kernel, while maintaining the power and performance that users expect. In addition, we’re making EMTE available to all Apple developers in Xcode as part of the new Enhanced Security feature that we released earlier this year during WWDC.
The rest of this post dives into the intensive engineering effort required to design and validate Memory Integrity Enforcement.
Designing Memory Integrity Enforcement
Memory Integrity Enforcement starts with our secure memory allocators — kalloc_type, xzone malloc, and WebKit’s libpas — all of which use type information to decide how to organize memory allocations. With both use-after-free and out-of-bounds bugs, an attacker’s goal is to create overlapping interpretations of memory, which they achieve by controlling the precise position of certain allocations — of a specific type — that is advantageous to them. The type-aware placement policies of our secure memory allocators help thwart these memory corruption techniques, as we described in our kalloc_type post. Our secure allocators set a new high-water mark of software protection against memory corruption, while preserving the same or better performance as the allocators they replaced.
Allocators can apply protections only at the granularity of memory pages — 16KB on iOS — which is a natural fit for multi-page allocations. For smaller allocations, our secure allocators can use page-level protections to help prevent memory corruption attacks across different type buckets. However, page-level protections are too coarse to defend against attacks within the same type bucket, and we use memory tagging to close this gap.
Let’s look at how EMTE can be used to protect against two of the most common types of memory corruption: buffer overflows and use-after-free vulnerabilities. For buffer overflows, the allocator is responsible for using different tags for neighboring allocations. If a request to access memory spills over to adjacent memory that has a different tag, the hardware blocks it, and the operating system can take action and terminate the process. We represent this visually below with three adjacent allocations, tagged with three different secrets: ⏺️, 🔼, and ⏹️. Two access attempts with the 🔼 tag are permitted to 🔼-tagged memory, but the third attempt is blocked as it spills over into the adjacent, ⏹️-tagged allocation.
Memory Integrity Enforcement blocks buffer overflows
The allocator is also responsible for retagging memory as it gets reused for other purposes. In the image below, the 🔼 allocation is retagged as ⏹️ after it has been freed and reallocated by the system. If a request to the retagged memory is made with the older 🔼 tag, as would be seen in use-after-free exploits, the hardware blocks it and lets the operating system take further action.
Memory Integrity Enforcement blocks use-after-free access
A key weakness of the original MTE specification is that access to non-tagged memory, such as global variables, is not checked by the hardware. This means attackers don’t have to face as many defensive constraints when attempting to control core application configuration and state. With Enhanced MTE, we instead specify that accessing non-tagged memory from a tagged memory region requires knowing that region’s tag, making it significantly harder for attackers to turn out-of-bounds bugs in dynamic tagged memory into a way to sidestep EMTE by directly modifying non-tagged allocations.
Finally, we developed Tag Confidentiality Enforcement to protect the implementation of our secure allocators from technical threats and to guard the confidentiality of EMTE tags — including against side-channel and speculative-execution attacks.
Our typed allocators and EMTE both rely on confidentiality of kernel data structures from user applications, and of the tags chosen by the allocator. Attackers might attempt to defeat EMTE, and in turn Memory Integrity Enforcement, by revealing these secrets. To protect the kernel allocator backing store and tag storage, we use the Secure Page Table Monitor, which provides strong guarantees even in the presence of a kernel compromise. We also ensure that when the kernel accesses memory on behalf of an application, it's subject to the same tag-checking rules as userspace.
Attacks based on speculative execution can also be used to expose secrets. To improve performance, modern CPUs predict the execution of instructions that follow prior, potentially longer latency instructions. If the prediction is correct, computation is very fast. If it’s wrong, the CPU discards the prediction, and computation is slower. Unfortunately, discarded predictions have observable effects that can reveal system state and data, and because speculative attacks never cause the system to crash or misbehave in observable ways during their use, they’re particularly useful for an attacker. For example, evaluating a pointer authentication instruction speculatively exposed timing differences in our original implementation of Pointer Authentication Codes (PAC), which would allow the valid signature to be isolated. During the design phase for Memory Integrity Enforcement, we identified and addressed the three speculative vulnerabilities that could undermine tag confidentiality.
First, when EMTE is active, requests to access memory cause the hardware to check tags. It's crucial that evaluating a tag-checking instruction speculatively doesn’t expose timing differences that would allow an attacker to isolate the valid tag. From the start, we designed the Apple silicon implementation so that tag values can’t influence speculative execution in any way. Recently published security research demonstrates that the MTE implementation on Google’s Pixel devices is vulnerable to this type of attack, allowing MTE to be bypassed in Google Chrome and the Linux kernel.
Second, allocators assign random tags to memory, and attackers must not be able to predict tag values that the system will choose. We address this issue by frequently re-seeding the underlying pseudo-random generator used to select new tags.
Third, Spectre variant 1 (V1) is a speculative-execution vulnerability that allows attackers to exploit conditional branches to leak data, including MTE tag values. To date, there has been no solution to this problem in consumer operating systems, because general Spectre V1 mitigations such as Speculative Load Hardening have a prohibitive CPU cost. The presence of EMTE leaves Spectre V1 as one of the last avenues available to attackers to help guide their attacks, so we designed a completely novel mitigation that limits the effective reach of Spectre V1 leaks — at virtually zero CPU cost — and forces attackers to contend with type segregation. This mitigation makes it impractical for attackers to use Spectre V1, as they would typically need 25 or more V1 sequences to reach more than 95 percent exploitability rate — unless one of these sequences is related to the bug being exploited, following similar reasoning as our kalloc_type analysis.
Our mission with Memory Integrity Enforcement is to protect all users by default and provide an extraordinary disruption to the exploitation of memory corruption vulnerabilities. To do so, we considered a wide set of threats, including some of the most challenging ones — such as side channels — and arrived at this extensive combination of features not present in other MTE implementations. Google took a great first step last year when they offered MTE to those who opt in to their program for at-risk users. But even for users who turn it on, the effectiveness of MTE on Android is limited by the lack of deep integration with the operating system that distinguishes Memory Integrity Enforcement and its use of EMTE on Apple silicon.
For the new A19 and A19 Pro chips to support Memory Integrity Enforcement, we dedicated an extraordinary amount of Apple silicon resources to security — more than ever before — including CPU area, CPU speed, and memory for tag storage. And to fully realize this hardware investment, we designed all of the new operating system elements of MIE jointly with our hardware work, including secure allocators, EMTE, and tag confidentiality protections.
Because EMTE tag checking imposes a performance cost, we designed Memory Integrity Enforcement to take advantage of our secure allocators first and use EMTE to protect only smaller individual allocations within a type bucket, which software allocators can’t defend on their own. Then, by knowing where and how we would deploy EMTE, we could accurately model the tag-checking demand of the operating system, and design our silicon to satisfy it. Our hardware implementation influenced additional software design decisions, reducing the overhead of tag checks even further. Importantly, deploying EMTE with this level of precision supports our strategy to provide as many memory safety improvements as possible to users on previous iPhone generations, which don’t support EMTE.
For the security evaluation of Memory Integrity Enforcement, we involved our offensive research team from the very beginning. From 2020 to 2025, they continuously analyzed and attacked the system — first conceptually, with theoretical exploitation avenues, then with practical attacks in simulated environments, and eventually on new hardware prototypes. Prolonged engagement from our offensive research team allowed us to identify and eradicate entire attack strategies and techniques before attackers could ever discover them, leading to a stronger, more mature feature from the outset.
Our offensive research team identified where and how attackers are most likely to break into the system, and our deployment of Memory Integrity Enforcement is deeply guided by their findings. Notably, this includes making sure that this powerful new protection is available to third-party apps that are likely entry points for attackers — such as social networks, messaging apps, or any other app where a specific user can be targeted. Starting immediately with the launch of MIE, any developer can begin testing this powerful protection for their app, including EMTE on hardware that supports it, using the Enhanced Security settings in Xcode.
The meticulous planning and implementation of Memory Integrity Enforcement made it possible to maintain synchronous tag checking for all the demanding workloads of our platforms, delivering groundbreaking security with minimal performance impact, while remaining completely invisible to users.
Security evaluation
Memory Integrity Enforcement started with a deeply ambitious goal: to make it immensely more expensive and difficult to develop and maintain mercenary spyware attacks based on memory corruption against our platforms. While there’s no such thing as perfect security, MIE is designed to dramatically constrain attackers and their degrees of freedom during exploitation.
Throughout the design and implementation of Memory Integrity Enforcement, our offensive research team evaluated our progress by looking at sophisticated exploit chains that were previously used against our platform, recent vulnerabilities, and our own internal research. First, we worked on rebuilding and adapting previously seen exploit chains to systems protected by MIE. But it’s not sufficient to consider only previous chains that were developed before MIE existed, because attackers will surely adapt in reaction to these new protections. We therefore also evaluated a selection of more recent vulnerabilities that we expected would have the best chance of surviving MIE. For these, we meticulously enumerated all possible exploitation opportunities, similar to our evaluation of SockPuppet against kalloc_type.
Both approaches revealed the same conclusion: Memory Integrity Enforcement vastly reduces the exploitation strategies available to attackers. Though memory corruption bugs are usually interchangeable, MIE cut off so many exploit steps at a fundamental level that it was not possible to restore the chains by swapping in new bugs. Even with substantial effort, we could not rebuild any of these chains to work around MIE. The few memory corruption effects that remained are unreliable and don’t give attackers sufficient momentum to successfully exploit these bugs.
Here’s a visual representation of what this looks like for an attacker. The chart below represents six of the real-world exploit chains that we evaluated and shows the steps where Memory Integrity Enforcement — the secure allocators, EMTE, or both — stops the attack.
Memory Integrity Enforcement vs. real-world exploit chains
Notably, attackers confront Memory Integrity Enforcement early in the exploitation process. Although some issues are able to survive MIE — for example, intra-allocation buffer overflows — such issues are extremely rare, and even fewer will lend themselves to a full end-to-end exploit. Inevitably, attackers must face MIE at a stage where their capabilities are still very limited, leaving few viable avenues for exploitation. This leads to fragile chains where breaking just one step is often enough to invalidate the entire exploit strategy. When that happens, most of the chain’s components can’t be reused, and the attackers have to restart exploit development with entirely new bugs.
Conclusion
The industry-leading security of iPhone means that the vast majority of our users never face system-level attacks on their devices. Our work on memory safety is aimed primarily at the mercenary spyware and surveillance industry, which spends many millions of dollars to exploit memory corruption vulnerabilities and target a small number of individuals because of who they are and what they do. Over the past five years, we developed a comprehensive approach to memory safety that integrates the best of our hardware and software capabilities, and today’s announcement is the culmination of this ambitious vision. With the introduction of the iPhone 17 lineup and iPhone Air, we’re excited to deliver Memory Integrity Enforcement: the industry’s first ever, comprehensive, always-on memory-safety protection covering key attack surfaces — including the kernel and over 70 userland processes — built on the Enhanced Memory Tagging Extension (EMTE) and supported by secure typed allocators and tag confidentiality protections.
Based on our evaluations pitting Memory Integrity Enforcement against exceptionally sophisticated mercenary spyware attacks from the last three years, we believe MIE will make exploit chains significantly more expensive and difficult to develop and maintain, disrupt many of the most effective exploitation techniques from the last 25 years, and completely redefine the landscape of memory safety for Apple products. Because of how dramatically it reduces an attacker’s ability to exploit memory corruption vulnerabilities on our devices, we believe Memory Integrity Enforcement represents the most significant upgrade to memory safety in the history of consumer operating systems.