Apple's Advanced Data Protection (ADP) is not marketing language. When you enable it, the encryption keys for your iCloud Photos, backups, Drive files, and Notes genuinely move out of Apple's data centres and into your own device trust chain — Apple cannot decrypt them, and cannot comply with a court order to hand them over. That's real progress over standard iCloud. It's also not the full story. iCloud Mail, Contacts, and Calendar stay Apple-readable regardless. File metadata — names, timestamps, folder structure, checksums — is not end-to-end encrypted. ADP is Apple-only, account-bound, and proved in February 2025 that platform-level E2E can be withdrawn at a government's request. This guide walks through each of those facts, plainly.
What standard iCloud does (and why it isn't E2E)
By default, Apple encrypts iCloud data at rest using keys stored in Apple's Hardware Security Modules (HSMs) — secured servers in Apple data centres that Apple controls. That means Apple can decrypt your Photos, backups, and Drive files in response to a court order, an internal policy, or a data breach where someone gains access to the HSMs. The data is encrypted in transit and at rest, but it isn't end-to-end: Apple holds the other end.
A handful of categories — Health data, Messages in iCloud, iCloud Keychain, and several others — have always been end-to-end encrypted; Apple never held keys for those. But Photos, backups, Drive, Notes, and Reminders were not, under the standard default.
What ADP actually changes
When you enable ADP, Apple migrates the CloudKit Service keys for covered categories from its HSMs into your iCloud Keychain trust domain — a system that is itself end-to-end encrypted and synchronised across your trusted devices. Apple's servers handle the encrypted blobs and the sync infrastructure, but are cryptographically barred from reading the keys. The shift is real: Apple published it in its Platform Security guide, and security researchers have confirmed the architecture is not marketing.
Categories that gain E2E protection under ADP include: iCloud Backup (device backup plus Messages backup), iCloud Drive, Photos, Notes, Reminders, Safari Bookmarks, Voice Memos, Wallet passes, Siri Shortcuts, and Freeform. The total is roughly 23–25 categories depending on how Apple counts them in a given support document — the company's own pages are inconsistent on the exact tally.
What ADP doesn't cover — permanently
Three categories are explicitly excluded from ADP and cannot be made end-to-end encrypted, by design:
- iCloud Mail — Apple states this explicitly: interoperability with the global SMTP/IMAP email system requires Apple to manage keys. Mail is readable by Apple at any time.
- iCloud Contacts — Uses the CalDAV/CardDAV standards, which have no native E2E layer. Apple holds keys.
- iCloud Calendar — Same rationale as Contacts. Apple holds keys.
If you sync your contacts and calendar to iCloud — which most iPhone users do — that data remains accessible to Apple even with ADP fully enabled.
The metadata gap
Even for categories that are E2E encrypted under ADP, the following metadata is not end-to-end encrypted — Apple holds keys for it:
- File and folder names, folder hierarchy
- File sizes and types
- Creation, modification, and last-opened timestamps
- Byte checksums of file content (used for deduplication)
- Device backup identifiers, device names, models, and serial numbers
Apple has acknowledged this gap and stated intent to extend E2E coverage to more metadata categories — but as of late 2025 the exclusions remain. File names and timestamps can reveal nearly as much as file contents: a folder of files named after a person, with modification dates matching a specific period, tells a story even if the contents are encrypted.
Sharing drops E2E protection
Real-time collaboration requires a shared server state, and a shared server state requires Apple to manage keys. The practical consequences:
- iWork collaboration (Pages, Numbers, Keynote shared documents): any shared document reverts to standard data protection. Apple holds keys for collaborative files.
- Shared Albums in Photos: publicly viewable shared albums are not E2E encrypted, even with ADP enabled.
- "Share with link" for any Drive file: drops that file to standard data protection.
- Sharing with anyone who doesn't have ADP enabled: the shared content falls back to standard encryption for everyone in the share.
Sending a Pages document to a colleague is one of the most common reasons people use iCloud Drive. Using it immediately removes that file from ADP's protection. This is a real-world limitation that Apple's marketing does not emphasise.
Recovery: account-bound vs Kit-bound
ADP requires you to set up at least one recovery method before activating it: either a recovery contact (a trusted person with an Apple device who can pass you a time-limited code) or a recovery key (a 28-character alphanumeric code that you hold and Apple never sees). Apple recommends storing the key on paper in two places — the same instinct behind a printed Recovery Kit, applied to your Apple account rather than a vault file.
Recovery under ADP is still mediated by Apple's infrastructure: account authentication, device trust, and iCloud Keychain synchronisation are all Apple systems. If your Apple ID is locked, compromised, or you switch away from Apple devices, recovery becomes harder — your options depend on what Apple's account system allows at that moment.
A Kistvault Recovery Kit works differently: it's a single printed sheet generated entirely on your device that opens the vault on any new phone without any account, any server, or any network connection. Recovery doesn't go through a platform; it goes through a piece of paper you printed and stored. That's a different risk trade-off — simpler in some ways, more dependent on your own storage discipline in others.
Ecosystem and platform questions
ADP is Apple-only. It requires an Apple ID, Apple devices, and all devices on your account to be on iOS 16.2 / macOS 13.1 / watchOS 9.2 or later. A single older device on the account can block activation. There is no Android path, and no way to open your ADP-encrypted data without Apple's ecosystem.
In February 2025, Apple withdrew ADP from UK users entirely after the UK government issued a Technical Capability Notice under the Investigatory Powers Act, demanding backdoor access to E2E encrypted iCloud data for all users globally. Rather than build a backdoor, Apple removed the feature for the UK. As of this writing, UK users cannot enable ADP. The episode is worth noting: platform-level E2E protection is subject to the platform's compliance decisions. A government can ask Apple to withdraw a feature, and Apple's answer — however principled — applies to every user in that jurisdiction at once.
A local-first vault that never contacts any server doesn't present this surface. There's no cloud feature for a government to ask a platform to withdraw, because the encryption doesn't depend on a platform's decision to offer it.
The key idea
ADP and a local-first vault are answers to related but different questions. ADP asks: can we keep your iCloud photos safer than Apple's default? Yes, it can. A local-first vault asks: can we keep your most sensitive files off any cloud server entirely? That question doesn't start with "can Apple encrypt it better" — it starts with "can we ensure it never reaches any server at all". Both are real security improvements. They're just not the same improvement.
Who ADP suits, and when a vault suits you better
ADP is worth enabling if you are on iPhone, your whole household is on recent Apple software, you don't use iWork collaboration heavily, and you want better protection for your existing iCloud backup and Photos library. It's a meaningful upgrade from the default and the architecture is sound. Enable it.
A local-first encrypted vault fits differently: when you want your most sensitive photos and documents stored nowhere but your device; when you use or might use both iOS and Android; when you want recovery to be a physical object you hold rather than mediated by an account system; or when you want to be insulated from whatever compliance choices any platform makes in future.
They're not mutually exclusive. Many people run ADP for their general iCloud library and keep their most sensitive files in a vault that never touches any cloud. The two layers address different parts of the threat model.
Questions
Is iCloud Advanced Data Protection zero-knowledge?
Partially. For the categories ADP covers — Photos, backups, Drive files, Notes, Reminders — Apple holds no key and cannot decrypt your content. But iCloud Mail, Contacts, and Calendar are permanently excluded; Apple holds keys for those regardless. File metadata (names, timestamps, folder structure, checksums) is also not end-to-end encrypted. Full zero-knowledge means no server holds any piece of a key to any of your data; ADP doesn't reach that bar because of the excluded categories and the metadata gap.
If iCloud ADP protects my photos, why would I need a separate encrypted vault?
ADP and a local vault solve different problems. ADP is an upgrade to Apple's cloud: better than default, but still Apple's servers, still an Apple ID, still not available on Android, and protection drops whenever you share anything via iWork collaboration or a public link. A local-first vault keeps files off any server entirely, works across iOS and Android, and ties recovery to a printed Kit you hold — not to your Apple account. If you live entirely on Apple devices and want better-than-default iCloud, ADP is worth enabling. If you want files stored nowhere but your phone, or if you use both platforms, a local vault is a different model.
What happened to iCloud ADP in the UK?
In February 2025, Apple withdrew Advanced Data Protection from UK users after the UK government issued a secret order under the Investigatory Powers Act demanding backdoor access to E2E encrypted iCloud data. Rather than build a backdoor, Apple removed ADP for new UK users and asked existing users to disable it. The situation demonstrates that platform-level E2E — where the platform controls whether the feature exists at all — can be revoked at a government's request to that platform. A local-first vault's encryption doesn't depend on Apple's compliance decisions.