What is zero-access encryption? What it protects, and when a server still reads it

The Morse teamPublished November 5, 20268 min read

Zero-access encryption is a way of storing your data on a company's servers encrypted with a key only you hold, so the company can't read what it keeps, even though it may see the data briefly before it's encrypted. As of November 5, 2026, Proton uses the term for Proton Mail, Calendar, Pass, Drive, and its Lumo AI assistant, and Tuta treats "zero access" as another name for zero-knowledge encryption.

We read Proton's own zero-access explainer, its Proton Mail encryption and security pages, its Drive security page, its Lumo privacy article and Lumo security post, Tuta's encryption page and zero-knowledge post, and Apple's iCloud data security overview and Private Cloud Compute post, all on November 5, 2026. Proton deserves credit for how plainly it states the term's limit: its explainer says the service "may briefly access the data before encryption." In an AI chat, that brief moment is when a model reads your prompt.

How does zero-access encryption work?

With public-key cryptography. Proton's explainer says data "is encrypted with your public key and can only be decrypted using your private key, which you alone control" (Proton). The server holds only the public half, so it can lock new data for you but can't unlock any of it. When you open your inbox or a file, the encrypted copy comes down to your device and is decrypted there.

In Tuta's design the private key itself sits on the company's servers, locked by your password. Tuta says the private key "is encrypted with the user's password before it is transmitted to Tuta's servers," and that its servers never receive the password itself in plain text (Tuta). Proton's Lumo post describes a chain of keys that ends at your account password, which it calls "the ultimate layer of security and the cornerstone of this scheme's soundness" (Proton).

What is the difference between zero-access encryption and end-to-end encryption?

The difference is where the encryption happens. End-to-end encryption locks the data on your device before it leaves, so the service never holds it in a readable form. Zero-access encryption can lock it after it arrives. Proton's own explainer says end-to-end encryption "offers stronger privacy guarantees because the service provider never sees the unencrypted data at any point" (Proton).

Proton gives the example itself. When someone emails you from Gmail, "Proton's servers can briefly read the message because Gmail doesn't use end-to-end encryption," and then encrypt it with your public key (Proton). Tuta describes the same step without the term: mail from other services is "only encrypted once they reach our servers" (Tuta).

A common shorthand says end-to-end encryption covers data in transit and zero-access covers it at rest. Proton's pages draw the line differently. Its Lumo post says that when you encrypt your own chat history for yourself, "both 'ends' are the user, which meets the traditional definition of E2EE" (Proton). Its Drive page says Drive uses "end-to-end and zero-access encryption" (Proton). So ask of any service whether your data was readable on its servers at any moment, and for how long.

Is zero-access encryption the same as zero-knowledge encryption?

Mostly, yes. Tuta's post says zero-knowledge services are "also commonly referred to as no-knowledge or zero access," and that "we have no access to data stored inside your account because we have no access to your encryption keys" (Tuta). Each company decides how much of the account the term covers, so read which fields it lists.

What doesn't zero-access encryption hide?

Metadata, in most email. Proton Mail's support page says "subject lines in Proton Mail messages are not end-to-end encrypted to remain compliant with standards and ensure interoperability," and that getting them "would require a court order that is approved by a Swiss judge" (Proton). Tuta encrypts subject lines but says "the only data that is not encrypted in a Tuta email are the email addresses and the date of an email sent or received" (Tuta).

Apple's version of the idea, Advanced Data Protection, has the same kind of gap. It raises the number of end-to-end encrypted iCloud categories from 15 to 25, but "some metadata and usage information stored in iCloud remains under standard data protection," such as file modification dates and checksums (Apple, published January 5, 2026). iCloud Mail, Contacts, and Calendar stay outside it because of the standards they're built on.

Proton's explainer says a zero-access service "has no data to hand over in the first place" when a government asks (Proton). That holds for the encrypted content. The fields listed above are still readable, and they're what an order can reach.

Does zero-access encryption protect what you tell an AI?

It protects the saved chat, not the prompt while the model reads it. Lumo is the clearest case, because Proton documents both halves. Its privacy article says "Lumo uses zero-access encryption for stored chat history and TLS encryption for data transmission," and that prompts are encrypted "so only the Lumo GPU servers are able to decrypt them" (Proton). Its security post, published August 4, 2025, says "we need to provide the LLM with cleartext messages," and calls that step "user-to-Lumo (U2L) encryption" so it isn't mistaken for end-to-end (Proton). We cover what that means for Lumo in our Lumo AI review.

Apple names the same constraint. Its Private Cloud Compute post says a large model "requires unencrypted access to the user's request," and "that precludes the use of end-to-end encryption" (Apple). Apple's answer is to encrypt each request "directly to the public keys of the PCC nodes that it has first confirmed are valid and cryptographically certified," which it calls end-to-end encryption to those nodes. Computing on the prompt while it stays encrypted is possible in research, but far too slow for a chat, as our page on homomorphic encryption sets out.

Where your data is readable under each kind of encryption

Every example comes from the company's own page, read November 5, 2026.

Plain end-to-end encryption keeps the server out entirely, which also means a model on that server can't answer. The last row is the only one that keeps a prompt sealed while a model reads it, and it holds only as well as the enclave hardware and its attestation do, which we explain in what a trusted execution environment is.

How Morse keeps your prompt sealed while the model reads it

Zero-access encryption guards the copy a company keeps. In an AI chat the exposure comes earlier, when a server decrypts your prompt so a model can answer it, and no storage scheme reaches that moment. In Morse's E2EE mode, only an enclave your browser verified ever reads your prompt, and in every mode Morse keeps no copy of your chats on its servers.

• E2EE, for a prompt no server should read. Your browser checks the enclave's hardware attestation against versions pinned in the app before anything leaves your device, then encrypts the message so only that enclave can read it. Our servers relay ciphertext they can't read, and the reply is decrypted only in your browser. Every E2EE reply has a lock you can open to see each check that passed, and our guide to end-to-end encrypted AI chat walks through them. The enclaves are run by third-party providers, not by Morse, and the guarantee rests on the enclave hardware and attestation working as designed. E2EE runs open-weight models like GLM, Kimi, and DeepSeek, without web search or image generation, so start a chat in another mode when you need those.
• Private, for open-weight models and Grok, where nothing is kept. Morse has zero data retention agreements with its inference, search, and other providers. The host still reads the prompt to answer it, which our page on zero data retention explains, but it keeps nothing afterward. Where a provider confirms zero retention on each reply, Morse checks it and refuses a reply that doesn't.
• Anonymous, for GPT, Claude, and Gemini. Our proxy removes your account, email, and IP address and sends the message under Morse's own account, so the provider sees the message without knowing it's you. It may keep it for a limited time to check for abuse, under its own policy.

Morse's storage works the other way round from zero-access. A zero-access service stores data it can't read, while Morse holds a key to data it never receives. Your Morse history is stored only in your browser, encrypted, and unlocking it takes two keys: one that never leaves your device, and one our server gives you when you sign in. Our privacy policy is exact about it: this "is not end-to-end encryption against us: we hold the key, but we never receive the data it unlocks." Our servers don't keep or log your messages, and your account holds sign-in details, plan, balance, and a usage ledger with no content, so we usually have very little to give authorities. We don't train AI on your content, sell your data, or show ads. Clearing your browser or deleting your account deletes your chats for good, and we can't recover them, so keep a copy of anything you need.

Try a chat from the Morse home page without an account, or start free. E2EE chats come with Pro, at $19 a month.