Apple released their new iPhone 17 series a few months ago, but aside from the new features and improvements, the most exciting security feature of these new phones was not even mentioned in its keynote or really advertised at all.

And I think it significantly raises the bar in terms of security for everyone.

With Apple’s new A19 chip being based on the ARMv9A architecture, iOS now supports the memory tagging extension feature. And this comes from an announcement on the Apple security research blog in September.

Apple calls their implementation “Memory Integrity Enforcement (MIE) and published a technical breakdown on their security blog.

It combines some existing memory safety features in iOS with ARM’s Memory Tagging Extension (MTE), which has been seen in some Android smartphones for a few years now.

Let’s explore how it aims to make cyberattacks on iOS devices significantly more difficult.

What is MTE? 

MTE is a hardware feature introduced by ARM as part of the ARMv8.5-A architecture in 2019. ARM built it as a debugging tool for software developers.

Apps need to store data in your phone’s memory (RAM), and they reserve this space through a process called memory allocation.

Unfortunately, if these allocations are not strictly validated, apps can inadvertently or maliciously access memory outside of what they were assigned.

What MTE does is essentially tag every single memory allocation with a secret code.

The hardware then ensures that every future request to access that memory is only granted if the request contains that same secret.

If the request does not contain the secret code, for example, because it came from an app other than the one that was allocated in the first place, then the app that is making the request crashes and the event is logged by the operating system.

The goal behind this was to help developers identify these fatal errors immediately. Why is this a big deal for security?

According to reports from both Microsoft and Google, over 70% of security vulnerabilities identified in their products are attributable to issues related to memory safety.

And many of the high-profile vulnerabilities that we have seen over the years were caused by a lack of memory safety.

Security researchers identified that MTE could function as a continuous tool for monitoring and preventing security exploits, in addition to its use as a debugging tool.

The Google Pixel has actually been using MTE in some capacity since the Pixel 8.

Hardware advantage 

Most exploits against iOS devices rely on memory corruption bugs. These are bugs where, because of faulty system logic, an attacker can write to out-of-bounds memory or type-confuse objects to corrupt important parts of the process data and ultimately take control of the system.

Memory corruption bugs have been around forever and are unlikely to go away completely. Even with the latest iOS versions, we see many bugs of this category being fixed in patch updates regularly.

It would be infeasible to aim for a bug-free iOS. So instead, Apple has focused on making these bugs as difficult as possible to exploit.

They have already done a great job at this in their software and hardware enhancements over the years, with features like pointer authentication codes to mitigate control flow hijacking, zone sequestering, and other proprietary hardware mitigations like Kernel Text Read and Write (KTRR) and Page Protection Layer (PPL).

Apple’s MIE is supposed to be the final nail in the coffin, potentially ending memory corruption exploitation in iOS completely.

Apple uses MIE to secure the kernel and over 70 userland processes in its operating system.

They also make MIE available as an opt-in feature for app developers, meaning that it is very likely the apps you use, which need the highest levels of security, hopefully as instant messengers or web browsers, will probably enable it on their own soon.

This usage is a step above the typical MTE configuration on Android, which uses it less substantially across the operating system itself.

It works much like an address sanitizer, a common software debugging tool.

The problem with software-based address sanitizers is that they have a significant overhead due to the inefficiency of performing extra logic on every single memory access. It would not be a good idea to ship a production device with a software-based address sanitizer active because performance would take too much of a hit.

The cool thing about the MTE feature is that it leverages new hardware instructions available in the ARMV9A architecture that implement the functionality of a software address sanitizer, but in a hardware-backed way.

These new CPUs have built-in circuitry to handle the sanity checks. So, performance takes no real hit.

If you inspect the kernel itself on the iPhone 17 running the latest iOS version, you can see these new MTE instructions present in the kernel cache binary.

The first new instruction you will see is the IRG instruction, which inserts a random tag into a pointer.

Now, much like pointer authentication codes, the IRG instruction generates a random 4-bit tag and inserts it into the top, unused bits of a given pointer.

The STG instruction takes that tag and writes it into a special private shadow memory region that holds tags for every 16-byte chunk of memory.

Once a pointer and its corresponding memory are tagged, any subsequently executed memory access instruction will trigger an exception if the tags are ever found to be mismatched.

Checking for mismatched tags does not require any new logic to be implemented in software. The typical ARM 64 load and store instructions have new circuitry hard-coded in these latest ARM CPUs, which validates the pointer and memory tags almost instantly with no noticeable performance overhead.

So, in practice, how would this prevent exploitation? For typical use after freeing bugs, a program mistakenly uses a pointer to already freed memory.

But with MIE enabled, as soon as a memory access is made, the ARM hardware will recognize the tag mismatch and trigger an exception. Similarly, for buffer overflows, the very first out-of-bounds write will fail due to the address and memory tag mismatch.

One small caveat is that since these memory tags are only four bits, separate allocations can have the same tag, but this still provides a strong defence since the reliability of an exploit will drop to a 1 in 16 chance of success.

Protection vs performance

With all that power built into the hardware, you are probably wondering, why is MIE not enabled everywhere on iOS. It comes down to a choice between protection and performance, which are defined by the two modes in which MTE operates.

MTE comes in two modes, synchronous and asynchronous.

Synchronous mode is optimized for protection over performance, and it is the only mode the Android open-source project claims can act as a true security mitigation.

Asynchronous mode offers higher performance but does not necessarily crash the application immediately, and it does not record some information about the memory that is being improperly accessed.

If you look at how MTE is used in GrapheneOS, for example, they enable MTE on the kernel in synchronous mode.

But for userland apps, they use a hybrid approach where they use synchronous mode when apps are writing to memory, but they use asynchronous mode when apps are reading from memory.

And the Android open-source project refers to this as asymmetric mode. They claim that this provides a balance, but it is still not as robust as purely operating in synchronous mode.

iOS, on the other hand, uses synchronous mode exclusively in all the areas where it uses MIE.

According to Apple, in asynchronous mode, memory corruption does not instantly trigger an exception, which may result in a period during which exploitation is possible.

Even though Apple has made synchronous MTE more efficient thanks to the new hardware, the performance impact of enabling it is why they have enabled it selectively.

MTE also makes existing memory safety bugs much more visible to users. The likelihood that an existing bug causes an app crash increases when MTE is enabled.

For this reason, many would probably be unlikely to put up with broadly enabled MTE across the entire system right now.

But hopefully, this becomes less of an issue over time as developers improve their apps thanks to this new debugging ability.

Why this new feature matters

Getting back to cybersecurity on mobile devices, all of this is of particular relevance to people who are being targeted by mercenary spyware like Pegasus.

Attackers rarely use a single exploit; they chain many smaller exploits together.

If an attacker gains even a limited access through a vulnerable application, they can leverage that privilege to compromise additional applications, potentially reaching the highest levels of your operating system.

Since the majority of problems are memory-related, many of the links in these chains are memory corruption bugs—bugs which could potentially be stopped by MTE.

As Apple puts it, “inevitably, attackers must face memory integrity enforcement at a stage where their capabilities are still very limited, leaving very few viable avenues for exploitation.” Breaking just one step invalidates the entire attack strategy.

The protections MIE gives against malware and spyware that rely on these exploit chains are enormous because they dramatically reduce the probability of a successful chain of attacks.

On Apple’s own research blog, they state that they believe memory integrity enforcement represents the most significant upgrade to memory safety in the history of consumer operating systems and that even with substantial effort, their internal research team could not rebuild any of their sample exploit chains to work around this mitigation on iOS.

As an iPhone user, this should be a very comforting statement, and for the hacker community, it presents a daunting challenge.

MIE vs. Lockdown Mode

So, how does this compare to lockdown mode?

Lockdown mode is very effective at preventing exploit chains, just like MTE is. But the approach that it takes is very different.

Ultimately, what lockdown mode is doing is reducing your attack surface dramatically by disabling apps and features that you are unlikely to need in the name of security.

If there were an exploit in the iMessage link preview generator, it could now be blocked by MIE, and it would happen without needing to disable link previews because MIE is always enabled.

If MIE blocks an exploit attack, it is detected immediately. MIE crashes the exploited app and logs the details, making it more likely you will receive a threat notification quickly.

If an exploit is blocked simply because you didn’t use link previews, that could be harder to spot after the fact.

For the highest levels of security, these features should be working in tandem.

That is the basics of defence in depth to dramatically reduce the likelihood of an exploit.

I hope Apple soon introduces a feature that lets Lockdown Mode enable MTE system-wide for both the OS and apps.

As I mentioned earlier, MTE is only enabled selectively outside the kernel on iOS for both performance and stability reasons.

Lockdown Mode users are far more likely to accept app crashes and performance drawbacks for improved security. If they added per-app toggles like GrapheneOS, where you could decide which apps this gets enabled on or not, that would be even better for these advanced users with very high-risk threat models.

Overall

This is a massive leap forward in terms of security for iPhone users, and frankly, it is the first time in a long while that I have been genuinely thrilled about an Apple product.

While MTE is a hardware feature that is exclusive to the iPhone 17 series, some of the other improvements that Apple includes in MIE are implemented in iOS 26, and they will be accessible to older devices.

The other thing is that most casual users aren’t exploited by Pegasus. However, the likelihood that you could face a threat like mercenary or commercial spyware should not be understated.

If your work puts a target on your back—MIE is not a feature; it is an insurance policy that considerably raises the bar on your personal security posture.

Take a moment to breathe on that. Your digital safety just got a massive upgrade.