The Walled Garden Approach

A category of email services has emerged over the past decade marketing themselves as the solution to email surveillance. They promise end-to-end encryption, zero-knowledge architecture, and increasingly, quantum-safe security. Their marketing is polished, their user interfaces are clean, and their appeal to people who care about privacy is real.

These services are commonly called walled gardens: closed ecosystems where the full security promise only holds when both the sender and the receiver are inside the same garden, using the same provider's software, trusting that provider's key management. Step outside the wall, send to a Gmail address, receive from an Outlook account, use a third-party email client, and the security model changes substantially.

This article examines what these services actually deliver, under what conditions their encryption claims hold, and what you are really getting when you trust a walled garden with your private communications. We will also examine the "quantum safe" marketing label and why it frequently obscures rather than clarifies the actual security picture.

The core question is not whether these services encrypt. They do. The question is: encrypt at which point, controlled by whom, and protecting against what?

How Email Actually Works: The Four-Hop Path

Before evaluating any encryption claim, you need to understand the path an email travels. Despite decades of complexity layered on top, the fundamental architecture of email has not changed. Every message passes through four distinct points:

1. The Sender, the person composing and transmitting the message
2. The Sender's Provider, the mail server that accepts and forwards the message
3. The Receiver's Provider, the mail server that accepts and stores the message
4. The Receiver, the person who retrieves and reads the message

The two providers in the middle, positions two and three, are where the security model either holds or breaks. End-to-end encryption means the two ends (sender and receiver) perform the cryptographic work, and the two middles can only see ciphertext they cannot decrypt. The name is descriptive: encryption from end to end, with the middle excluded.

For this to be true in any meaningful, non-trust-based sense, the sender must encrypt the message before it leaves their machine, using the receiver's public key. The receiver must decrypt the message using their own private key, on their own machine, using software outside the provider's control. Neither provider in the middle ever possesses the means to decrypt.

That is the standard. Now let's examine what actually happens with walled garden services.

Scenario One: You Receive Mail From Outside the Garden

This is the most common case. Someone using Gmail, Outlook, or any standard email service sends you a message at your walled garden address. They have not encrypted the message, as most people do not, because they are just sending email the way they always have.

The path looks like this:

• The sender composes a message in plaintext
• Their provider transmits it via SMTP, typically protected only by TLS during transit
• Your walled garden provider receives the message in plaintext
• The provider encrypts it for storage using a key they manage
• You retrieve it and decrypt it using the provider's software

At step three, the provider sees your message in plaintext. There is no way around this. The sender did not encrypt before transmitting, so the message arrives unencrypted at the receiving server. The walled garden then applies its own encryption before writing the message to disk, a practice correctly called zero-access storage encryption, not end-to-end encryption.

This is meaningful. It means that if someone gains access to the stored data on the provider's servers, through a breach, a legal order, or a malicious insider, they cannot read your mail without also controlling the decryption keys. That is a real protection worth having.

But it is not end-to-end encryption. The provider was present at the moment the message arrived in plaintext. The encryption they applied was their own, using keys they control, implemented in code they wrote. What you received was plaintext mail that was subsequently encrypted by the provider on your behalf. There is a meaningful difference. A more accurate name for it would be middle-out encryption, where the middle of the chain encrypts the message and hands it to the end, rather than the end doing the encrypting. The two middles have seen the message.

Only the last leg is encrypted, by someone other than the sender, using keys the recipient does not fully control. That is the opposite of what end-to-end means. And it is worth noting that this last hop, from the provider to your email client, is already protected by TLS in any modern setup. TLS is then applied on top of that encrypted payload for delivery, so the message travels as encrypted content inside an encrypted channel. As a transport protection, the additional value over TLS is narrow: it matters only if TLS itself is broken or compromised. What you do retain is the encrypted storage benefit: mail sitting on the provider's servers is encrypted at rest, so a server breach does not hand an attacker your readable messages. That is a real and meaningful protection. It just is not end-to-end encryption, and it does not protect against the provider themselves.

Scenario Two: You Send Mail to Someone Outside the Garden

Now consider the reverse: you are inside the walled garden and you send a message to someone at a standard provider.

Here, your provider must deliver a message that the receiver's standard email infrastructure can actually process. SMTP does not speak the walled garden's proprietary encryption format. So one of two things happens:

Option A: The Provider Decrypts and Transmits in Plaintext

The outbound message goes out via standard SMTP in plaintext, either decrypted by the provider for delivery or composed in plaintext to begin with. The receiver's provider receives it in plaintext. The receiver gets plaintext. The path:

• You compose a message inside the garden
• The provider decrypts it (or transmits it unencrypted) to deliver it outbound
• The receiver's provider receives plaintext
• The receiver reads plaintext

This is not end-to-end encryption in any direction. The provider was involved in the decryption step necessary to send the message.

Option B: The Provider Sends a Link

Some walled garden services handle external recipients by sending them a link rather than the message itself. The recipient receives an email that says, in effect, "someone has sent you a secure message, click here to read it."

When the recipient clicks the link, they are taken to a web page hosted by the walled garden provider, where they read the message through the provider's web interface, after authenticating or providing a password the sender shared with them separately.

This is not end-to-end encryption. This is a web portal with a password. The message never left the garden's infrastructure. The recipient reads it through the provider's software, on the provider's servers. The "encryption" in this case is simply the provider's own storage encryption, viewed through a browser window. There are no ends involved in any cryptographic sense.

Scenario Three: Both Parties Are Inside the Same Garden

This is the scenario where walled garden E2EE claims are most plausible. When both the sender and the receiver use the same service, the provider can potentially facilitate genuine end-to-end encryption, because they have both parties' public keys and can enforce an encryption scheme across the entire path.

In this scenario, a properly implemented walled garden service can genuinely encrypt the message to the recipient's public key before it is ever stored, meaning neither transmission nor storage exposes plaintext. This is the closest most walled garden users ever get to true E2EE.

But even here, the key custody question changes the picture significantly. True end-to-end encryption requires that the provider cannot decrypt, not that they choose not to. That distinction depends entirely on whether the provider generated your keys, stores your private key, and controls the software that performs decryption. We have written in detail about why provider-generated and provider-stored keys fundamentally undermine the security model.

Most walled garden services generate your key pair for you, encrypt your private key with a passphrase they receive from your browser, store the encrypted private key on their servers, and provide the JavaScript code that decrypts your private key each time you log in. They can:

• Generate weaker keys or keys with hidden structure
• Capture your passphrase via the JavaScript they serve
• Deliver modified code to specific targeted users
• Log the decrypted private key at the moment of use
• Comply with legal compulsion to provide a modified code delivery silently

These are not hypothetical attack scenarios invented to be alarmist. They are the natural consequence of the provider being inside the trusted computing base for both key generation and decryption. Code delivered by the party you are trying to exclude from your communications cannot be the code performing your encryption and decryption. This is a foundational principle, not an opinion.

The "Quantum Safe" Marketing Angle

Several walled garden services now advertise their encryption as quantum safe or quantum resistant. This sounds significant. Quantum computing represents a genuine long-term threat to certain cryptographic algorithms, specifically the integer factorization and discrete logarithm problems that underpin RSA and classical elliptic curve cryptography. Post-quantum algorithms, such as those standardized by NIST in 2024, are designed to resist attacks from sufficiently powerful quantum computers that do not yet exist at scale.

Adopting post-quantum cryptography is a reasonable forward-looking engineering decision. We do not dispute that, and we currently employ a default encryption of AES-256-GCM, which is deemed quantum resistant by NIST guidelines. But that is still not the full picture.

What we dispute is the implication that "quantum safe" meaningfully addresses the actual privacy threat model for most email users.

Consider what quantum-safe encryption does and does not protect against:

• It protects against: A future sufficiently powerful quantum computer decrypting data that was intercepted and stored today, years or decades from now
• It does not protect against: The provider seeing your message in plaintext when it arrives via SMTP from outside the garden
• It does not protect against: The provider capturing your private key passphrase via the JavaScript they deliver
• It does not protect against: A legal order compelling the provider to alter their client-side code to capture messages before encryption. This is not hypothetical. In 2007, Hushmail, then one of the most trusted encrypted email providers, was compelled by court order to modify the Java applet delivered to a specific user's browser to intercept plaintext before it was encrypted and transmit it to law enforcement. Quantum-safe algorithms are irrelevant when the code performing the encryption has been replaced.
• It does not protect against: Outbound messages to external recipients leaving as plaintext SMTP, whether decrypted by the provider for delivery or simply composed and transmitted in plaintext to begin with

In every scenario where the walled garden's E2EE already breaks down, quantum-safe algorithms do nothing. The algorithm's strength is irrelevant when the provider holds the keys, controls the key generation, or receives the message in plaintext. Quantum-safe encryption of data the provider can already access is not meaningfully safer encryption. It is the same access, with a harder lock on a door the provider already has a key to.

The real near-term threat for nearly all users is not quantum decryption. It is provider access, legal compulsion, data breach, and insider threat. Post-quantum marketing addresses none of these. It does, however, sound impressive and technically sophisticated, which is precisely why it is effective marketing.

What the Claims Actually Deliver

Setting aside the marketing language, what does a walled garden email service actually deliver?

When Senders Encrypt Before Sending (The Ideal Case)

If your correspondents use PGP or S/MIME independently and encrypt their messages to your public key before transmitting them, your walled garden service receives an encrypted blob it cannot read, stores it, and delivers it to you. You decrypt using your private key. This is genuine E2EE.

But notice what happened: the walled garden's own encryption features played no role. The security came entirely from your correspondent encrypting first using a standards-based protocol. In this scenario, it does not matter what email service you use. Any provider, including the most basic IMAP host, delivers the same security guarantee, because the encryption happened before the message arrived anywhere. The walled garden's proprietary encryption layer added nothing.

When Senders Do Not Encrypt Before Sending (The Common Case)

Most people do not encrypt before sending. Most email in the world is transmitted as plaintext. When this mail arrives at your walled garden provider, the provider sees it in plaintext. They then apply their own encryption before storing it to disk.

What you have at this point is:

• A message that was already TLS-protected during transit (as virtually all modern mail transfer is)
• A message that arrived in plaintext at the receiving server
• A message that the provider then encrypted using their own keys and their own code
• A message that you will decrypt using the provider's software, software they control and can update at will
• A message that will exist as plaintext on your device after decryption, just as it would with any provider

The extra encryption layer between the provider's servers and your device is layered on top of a channel already protected by TLS. It adds meaningful protection against server-side breaches. It does not add protection against the provider itself, against legal compulsion directed at the provider, or against an attacker who compromises the provider's systems at the point where plaintext is briefly present during processing.

And when you close the message, it is plaintext on your device, just as it is with any email service.

The Drawbacks of Walled Garden Services

Beyond the encryption limitations, walled garden services impose a set of structural costs that deserve consideration.

Vendor Lock-In

Walled garden services typically use proprietary encryption formats, proprietary APIs, or proprietary storage schemas. Migrating away from the service, taking your encrypted mail with you, is often difficult or impossible without the provider's cooperation and software. Your encrypted mail is only readable through their tools. This is the classic walled garden problem: the garden protects you, but it also contains you.

Correspondent Lock-In

The security promise of a walled garden only fully applies when both parties are inside the same garden. To communicate securely with someone outside the garden, you must either persuade them to join your service, accept the degraded link-based experience for external recipients, or fall back to plaintext SMTP just like everyone else. The security model is contingent on network effects that the provider has a financial interest in expanding.

Client Lock-In

Because the decryption is tied to the provider's software, their web interface, their mobile app, their browser extension, you cannot freely choose how you access your mail. Using a standard IMAP client, which gives you freedom of choice and removes the provider from the software trust equation, typically breaks the encryption model. You are dependent on the provider's software continuing to exist, to function, and to remain trustworthy.

PWA and Web Delivery Risks

Many walled garden services deliver their encryption functionality through Progressive Web Apps (PWAs) or browser-based JavaScript. A PWA is, in functional terms, a browser tab presented as a standalone application. The code that handles your private key, potentially including decryption, is downloaded from the provider's servers each time you open the application. The provider can update that code at any time, including in response to a legal compulsion you will never be informed about. You cannot audit what code is actually running at the moment you use it.

Key Custody and the Provider Trust Requirement

As discussed above, most walled garden services generate your encryption keys, store your private key (encrypted with your password), and supply the code that decrypts it. This design means the provider is inside the trusted computing base for your encryption. The security claim becomes: trust us not to abuse the access we demonstrably have, rather than: we are architecturally incapable of accessing your data.

The Zero-Knowledge Claim

Several walled garden providers describe themselves as "zero-knowledge." Zero knowledge is a specific cryptographic property with a precise meaning, one that no email provider can legitimately claim. Email arrives via SMTP. SMTP delivers plaintext. A provider that receives plaintext, even briefly, even before encrypting it, has knowledge of the content at that moment. The zero-knowledge label, applied to email, is a marketing redefinition of a technical term, not an accurate description of the underlying architecture.

What Standards-Based Encryption Actually Gives You

The alternative to walled garden encryption is not weaker security. It is standards-based encryption, specifically PGP/GPG or S/MIME, used independently of any provider.

When you generate your own key pair using GnuPG, Kleopatra, or any other independent tool, and provide only your public key to your email provider, something structurally different is true:

• The provider never touched your private key, not once, not during generation, not ever
• The provider cannot decrypt mail encrypted to your public key regardless of what they are compelled to do or what happens to their systems
• You decrypt using software you chose, that the provider did not write and cannot update
• Your correspondents can encrypt to your public key from any email service using any standards-compatible tool
• You can leave your provider and take your encrypted mail with you, it decrypts the same way with the same key

This approach works with any email provider that supports IMAP. It is not a proprietary capability. It is a consequence of using an open standard correctly.

How an Open Architecture Differs: Removing the Provider Entirely

The architectural difference between a walled garden and an open, standards-based approach becomes clearest when you examine what happens to the provider's role in each model.

In a walled garden, the provider is inside the cryptographic process. They generated your key. They store your private key. They supply the code that uses your private key. They are present in some form at every stage of the encryption and decryption lifecycle.

In a properly configured open architecture, the provider can be removed from the cryptographic process entirely. Our most secure configuration illustrates how this works in practice. When you generate your own PGP key pair using independent software, upload only your public key to your account, enable automatic PGP encryption of incoming mail, and access that mail using a third-party client such as Thunderbird, the following becomes true:

• Mail that arrives unencrypted reaches us in plaintext, just as it does with any provider including walled gardens. If you have enabled PGP auto-encryption, it is encrypted to your public key first. Then, regardless of whether PGP is enabled, the message — headers and all — is wrapped in AES-256-GCM encryption before being written to disk. When PGP is enabled, what lands on disk is an AES-256-GCM-wrapped PGP message: two independent layers, the outer one quantum resistant by NIST guidelines. What is different from a walled garden is what happens next: because we never generated your keys, never stored your private key, and play no role in the decryption software you use, we are architecturally incapable of reversing the PGP layer. We have locked the message with a lock that only your private key can open, and your private key has never been anywhere near us.
• Automatic encryption can be applied to all incoming mail, to mail arriving at specific aliases only, or to mail matching a filter rule. PGP encrypt is available as a filter action, giving you fine-grained control over exactly which messages get encrypted and with which key.
• You decrypt using Thunderbird, K-9 Mail, or any PGP-capable client, software we did not write, cannot update, and do not control
• We have no ability to modify the decryption code path, capture your passphrase, or access plaintext after encryption
• For mail that arrives already encrypted by the sender, the ideal case, we are a dumb store-and-forward that never sees plaintext at all
• Even if we were compelled, compromised, or otherwise forced to act against your interests, we have nothing to betray: we do not possess the private key, and we do not control the software performing decryption

A note on algorithm strength: the AES-256-GCM layer applied to all stored mail is quantum resistant by NIST guidelines. PGP will be upgraded to a post-quantum standard as those tools mature. But as the quantum-safe section above makes clear, algorithm strength is not where the meaningful distinction lies. The path is the weakness, not the cipher. What matters is whether the provider can decrypt at all, and in our most secure configuration, the architecture ensures we cannot.

This is not a proprietary capability. It is the natural result of building on open standards instead of a closed ecosystem. It works with any provider that supports IMAP and PGP. It is not dependent on your correspondents joining the same service. It does not lock you in to any particular client, giving you the freedom to use any email software you choose. And it gives you the freedom to leave without losing access to your encrypted mail.

The walled garden, by contrast, can only credibly promise this when both parties are inside the garden and when you trust that the garden's key management, code delivery, and storage practices are exactly as described. That trust is a load-bearing assumption, not a cryptographic guarantee. You are also bound to the provider's own client software. Some walled garden services offer a bridge application that allows third-party clients to connect, but using it typically bypasses the proprietary encryption layer entirely, at which point you have left the garden's security model behind while still accepting its other constraints.

A Realistic Summary

Walled garden email services offer real value. Their storage encryption protects against server-side breaches. Their within-garden encryption provides meaningful protection for users communicating with each other inside the same ecosystem. They are significantly better than a mainstream provider with no encryption of stored mail.

But the marketing language significantly overstates what they deliver for the majority of use cases, and the structural limitations are rarely disclosed prominently:

• External correspondents: not E2EE; plaintext arrives at the server, a link-based workaround replaces true encrypted delivery, or an AES-256 encrypted file is sent that the recipient decrypts with a shared password — all three are meaningfully different from end-to-end encryption
• Outbound to external recipients: not E2EE; mail travels as standard SMTP, arriving in plaintext at the recipient's mail server and delivered to their LDA, where it is stored in plaintext unless the recipient has independently arranged their own encryption; within-garden delivery is the only case where E2EE can hold
• Zero-knowledge: not technically accurate; plaintext exists at the provider during inbound processing
• Quantum-safe claims: do not address the actual threat; quantum-safe algorithms do not protect against provider access, legal compulsion, or code-path manipulation
• Key custody separation: not delivered by default; providers generate, store, and use your keys on your behalf
• Client freedom: not delivered; leaving their software typically breaks the encryption model

If your correspondents encrypt before sending, any standards-based email provider gives you equivalent security with fewer restrictions. If your correspondents do not encrypt before sending, the walled garden's encryption is real but narrower than advertised: it protects stored data against server-side exposure, layered on top of transit already protected by TLS, with decryption occurring in provider-controlled software before the message becomes plaintext on your device.

There is a different approach. Rather than building a garden with walls, it is possible to provide automatic incoming encryption with granular control, applied to all mail, to specific aliases, or to mail matching filter rules, while remaining completely outside the decryption path. When you generate your own keys and use a third-party client, the provider encrypts mail arriving for you but possesses no ability to reverse it. You get the convenience of automatic storage encryption without surrendering key custody or being locked into the provider's software. The encryption benefit of a walled garden, without the walls. This is what CodaMail provides.

That is worth knowing before choosing which garden to live in.

Published: March 2026