Is iMessage End to End Encrypted? Yes, but the Answer Has an Asterisk

If you've ever asked "is iMessage end to end encrypted," the short answer is yes. Device to device, your iMessages are encrypted such that Apple's relay servers cannot read the content in transit. That part has been true since 2011. The longer answer, the one that actually matters to your privacy, involves where those messages end up after they arrive. For about a decade, the backup layer quietly undid most of what the transport layer promised. That gap has a fix now. It's opt-in. And in at least one country, it was temporarily yanked entirely. Here's what you need to know.

Key Takeaways

• iMessage traffic between devices is genuinely end-to-end encrypted. Apple cannot read your messages while they're in transit.
• iCloud backups historically included a copy of your iMessage encryption key that Apple could access, which meant law enforcement (or anyone who compromised Apple's systems) could read backed-up messages.
• Advanced Data Protection (ADP), launched in December 2022, closes that backup gap by letting your trusted devices retain sole access to encryption keys for 23 categories of iCloud data, including backups. It is not enabled by default.
• The UK government ordered Apple to pull ADP entirely for UK users in early 2025. That order was reportedly abandoned months later, but the episode demonstrates how opt-in encryption can be revoked at the jurisdictional level.
• As of May 2026, cross-platform RCS messages between iPhone and Android now support end-to-end encryption via the MLS protocol, a separate but related development.

What Does "End-to-End Encrypted" Actually Mean for iMessage?

It means the plaintext of your message exists only on the sending device and the receiving device. Apple's servers act as relays. They pass ciphertext. They do not hold the keys to decrypt it. This is real, verifiable, and has been independently confirmed by security researchers. If someone intercepted the packets between your iPhone and Apple's infrastructure, they'd get noise.

So far, so good. The problem was never the wire. It was the filing cabinet.

Where Did iMessage Encryption Break Down Historically?

The backup layer. Specifically, iCloud Backup. When you had iCloud Backup enabled (which most people do, because it's on by default and Apple prompts you to set it up), a copy of your Messages encryption key was included in the backup itself. Apple held the keys to that backup. Which means Apple could decrypt your messages from the backup copy if compelled to, or if their systems were compromised.

This was not a bug. It was a design choice. Apple's rationale was account recovery: if you lost all your devices, Apple needed to be able to help you restore your data. The trade-off was that "end-to-end encrypted" described the transport path accurately while being deeply misleading about the overall system.

As James Darpinian pointed out, some critics argue this distinction is a semantic dodge. The iMessage servers don't read your messages, but the iCloud backup servers can. It's all Apple software running on Apple servers. The architectural separation is real in a protocol sense and irrelevant in a "who can read my texts" sense.

Why Did Apple Leave the Backup Gap Open for So Long?

Law enforcement. The FBI specifically lobbied Apple not to implement end-to-end encrypted backups. iCloud backup access was a reliable investigative tool precisely because iMessage's transport encryption was strong enough that breaking it directly was impractical. The backup was the side door. Apple disclosed this access path in its own law enforcement guidelines. It wasn't hidden. It was documented. Most users just never read those documents.

This dynamic persisted from iMessage's launch in 2011 through late 2022. Over a decade where the marketing said "encrypted" and the architecture said "except the copy we keep."

What Is Advanced Data Protection, and Does It Fix the Problem?

Advanced Data Protection (ADP) is Apple's answer, launched in December 2022. When you enable it, your trusted devices retain sole access to the encryption keys for the majority of your iCloud data. The number of end-to-end encrypted data categories jumps from 14 to 23, and the new additions include the ones that matter most: iCloud Backup, Photos, Notes, and Messages in iCloud.

With ADP on, Apple cannot decrypt your backups. They don't have the keys. If you lose all your trusted devices and your recovery key, your data is gone. That's the trade-off. It's the correct one for people who want the "end-to-end encrypted" label to describe the entire system, not just the wire.

The catch: ADP is not enabled by default. You have to go find it in Settings, set up a recovery contact or recovery key, and explicitly turn it on. Apple does not prompt you. The default behavior, today, in 2026, is still the old behavior: backups include a key Apple can access.

If you want to enable it, Apple provides instructions here. It takes about two minutes. You should do it now. I'll wait.

How Does the UK ADP Episode Change the Picture?

In February 2025, Apple pulled ADP entirely for UK users after receiving a government order under the Investigatory Powers Act. New users couldn't enable it. Existing users were told they'd eventually need to disable it. Apple stated publicly that it could no longer offer the feature in that jurisdiction.

Months later, the UK government reportedly abandoned the demand following Apple's legal challenge. But the episode is instructive for a reason that goes beyond the UK specifically.

Opt-in encryption is encryption that can be opted out for you. Not by you. By a government, by a policy change, by a software update that resets a toggle. The structural problem isn't whether ADP works (it does, and well). The problem is that "works when enabled" and "works" are different security postures. A feature that a single court order can strip from an entire country's users is a feature, not an architecture.

What About Messages Between iPhone and Android?

Until very recently, this was simple: messages between an iPhone and an Android phone were sent via SMS or MMS. No encryption at all. Plaintext through carrier infrastructure. Anyone with access to the network path (state-sponsored actors, compromised carrier equipment, lawful intercept systems) could read them. The green bubble wasn't just a social signal. It was a security downgrade.

The FBI publicly warned about this in late 2025, specifically citing state-sponsored hackers intercepting cross-platform messages. The EFF ran an "Encrypt It Already" campaign targeting Apple in January 2026.

As of May 2026, Apple began rolling out end-to-end encrypted RCS messaging between iPhone and Android with iOS 26.5. The encryption uses the Messaging Layer Security (MLS) protocol, an IETF-overseen open standard incorporated into the GSMA's RCS Universal Profile 3.0 spec in March 2025. When both ends support it, a lock icon appears in the chat.

The bubbles are still green. Apple kept the color distinction. Make of that what you will.

Does "Encrypted in Transit" Mean the Same Thing as "End-to-End Encrypted"?

No. These are distinct guarantees, and conflating them is one of the most common mistakes in consumer security discussions.

"Encrypted in transit" means the data is protected while moving between two points (your device to a server, for instance). The server on the other end can decrypt and read it. HTTPS is encrypted in transit. Your bank can still see your transactions.

"Encrypted at rest" means the data is encrypted while stored on a server. But "encrypted at rest" says nothing about who holds the keys. If the service provider holds the decryption key, "encrypted at rest" protects against a hard drive theft but not against a subpoena.

"End-to-end encrypted" means only the communicating parties hold the keys. The service in the middle handles ciphertext it cannot decrypt. This is what iMessage provides for device-to-device transport. This is what iCloud backups did not provide until ADP, and still don't provide unless you turn ADP on.

The Haven Blog put it well: for years, iCloud backups satisfied neither the "encrypted in transit" nor "encrypted at rest" guarantees in a meaningful way, because Apple held the keys at every stage of the backup process.

What Should You Actually Check on Your iPhone Right Now?

Two things.

First, check whether Advanced Data Protection is on. Go to Settings, tap your name at the top, tap iCloud, scroll to Advanced Data Protection. If it says "Off," your iCloud backups (including your message history) are accessible to Apple. Here's a walkthrough.

Second, check whether iCloud Backup is on at all. If you have ADP enabled, iCloud Backup being on is fine, because the backup is now end-to-end encrypted with keys only your devices hold. If you don't want to enable ADP for some reason (maybe you're worried about losing your recovery key), you can disable iCloud Backup entirely, which means your iMessage encryption keys stay on-device. But you also lose your backup. Pick your trade-off.

Why Does This Matter Beyond iMessage?

The iMessage backup gap is the clearest consumer example of a pattern that shows up everywhere in software: the transport is encrypted, but the storage isn't, or the storage is encrypted but the provider holds the keys, or the provider doesn't hold the keys but a government can compel them to redesign the system so they do.

This pattern is especially relevant for AI products. We build Selina, a privacy-focused AI assistant that remembers you across conversations. The parallel to the iMessage story is direct. Encrypting a chat in transit to a language model means little if the conversation logs, the embeddings, or the memory store used for personalization sit in a location the provider can access. The backup is always the weak point. The thing that makes the product useful (persistence, recall, continuity) is also the thing that creates the exposure.

For Selina, files and transfers via SelinaSEND are zero-knowledge encrypted. Memory is encrypted at rest but is not end-to-end encrypted, because a slice of each request reaches a frontier provider at inference time. We state that directly because the iMessage saga is a decade-long case study in what happens when you let marketing language outrun your actual architecture. Saying what you don't protect is part of protecting people.

Is Opt-In Encryption Good Enough?

It depends on your threat model, but for most users, the answer is no, because most users will never toggle it on.

Apple's ADP is a real, meaningful security upgrade. The cryptography is sound. The implementation is reviewed. When it's on, it works. But the base rate for users enabling non-default security settings is low. Single-digit percentages, typically. Which means the vast majority of iMessage users are still operating with the pre-2022 backup exposure. Their messages are end-to-end encrypted in transit and fully decryptable by Apple (or anyone Apple is compelled to cooperate with) in backup.

The UK episode makes the structural fragility concrete. A government can order the feature removed. Apple complied, then fought, then the order was reportedly dropped. But during those months, every UK user lost access to the strongest protection Apple offers. Opt-in encryption is a feature. Features can be disabled. Architectures that make compliance impossible (because the data never exists in a form the company can access) are a stronger guarantee, though they come with their own trade-offs around recovery and usability.

There is no free lunch here. Any system that can help you recover your data after you lose every device is, by definition, a system where someone other than you can access your data. ADP solves this by making recovery your responsibility (via a recovery key or recovery contact). That's the right answer for informed users. It's a terrible answer for the majority of people who will never change a default setting.

What About Metadata?

End-to-end encryption protects content. It does not protect metadata. Apple knows who you message, when, how often, and from which devices. This metadata is not covered by iMessage's end-to-end encryption or by ADP. It's available to Apple and, by extension, to anyone Apple is legally compelled to share it with.

Metadata is often described as "data about data," which undersells it. Metadata is the social graph. Knowing the content of a message between a journalist and a source matters less than knowing that the journalist and the source communicated at all, at 2 AM, fourteen times in a week, from a location near the courthouse. End-to-end encryption of content is necessary but not sufficient for communications privacy. iMessage provides the former. It does not attempt the latter.

So, Is iMessage End-to-End Encrypted or Not?

iMessage is end-to-end encrypted in transit, between devices, for message content. That statement is accurate and has been since launch.

Your iMessage history stored in iCloud backups is end-to-end encrypted only if you have Advanced Data Protection enabled. If you don't (and most people don't), Apple holds a copy of the key and can decrypt your backed-up messages.

Cross-platform messages to Android are now end-to-end encrypted via RCS with MLS, as of iOS 26.5, when both devices support it.

Metadata (who you message, when, how often) is not end-to-end encrypted and is available to Apple regardless of your settings.

The correct answer to "is iMessage end-to-end encrypted" is: the transport layer, yes. The system as most people actually use it, with default settings and iCloud Backup on? No. Not unless you take an explicit action that Apple does not prompt you to take.

Go turn on ADP. It takes two minutes.

If you're interested in an AI assistant that treats your privacy as architecture rather than a toggle, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io