ProtonMail launched in 2014 as a crowdfunded project from CERN researchers who wanted encrypted email accessible to non-experts. The pitch was simple: end-to-end encryption, Swiss jurisdiction, zero access to your message contents. For a decade, that was enough to make it the default recommendation whenever someone asked about private email.
It still deserves that reputation for what it does. But the questions privacy-conscious users are asking in 2026 are more nuanced than "is my email encrypted?" — and ProtonMail's answers to some of them are uncomfortable.
The 2021 IP Logging Incident
In September 2021, Motherboard and Le Monde reported that ProtonMail had complied with a Swiss court order to log the IP address of a French climate activist — a member of Youth for Climate who was using the service under the assumption it couldn't be compelled to identify them. ProtonMail received a legally binding order from Swiss authorities, acting on a Europol request, and complied.
ProtonMail's response was transparent: they published a blog post acknowledging what happened and explaining that Swiss law, not Swiss privacy, governs them. End-to-end encryption protects message contents, not metadata. IP addresses, timestamps, and account creation details are operational data — and like any company operating in a real jurisdiction, ProtonMail can be legally compelled to collect and hand them over.
"End-to-end encrypted" means the service cannot read your email contents. It says nothing about whether they can be compelled to log who you are and when you connect. These are different threat models.
This isn't a knock unique to ProtonMail — any centralized service faces the same constraint. But it matters because ProtonMail's marketing leans heavily on Swiss privacy law as a shield, and that shield has an obvious hole. If your threat model includes legal compulsion from Western governments, the Swiss jurisdiction provides much less protection than it implies.
What "Zero Access" Actually Covers
ProtonMail's "zero access" encryption means they cannot read the content of your emails. Your subject lines, message bodies, and attachments are encrypted client-side before reaching their servers.
What zero access does not cover:
- Sender and recipient metadata — who you email and when
- IP addresses — as demonstrated above, collectable under court order
- Account recovery data — if you provide a backup email or phone for recovery, those are stored in plaintext
- Email with non-Proton recipients — email to Gmail addresses is stored with zero-access encryption, but the recipient's server has no such protection
None of this is hidden. ProtonMail's documentation is clear about it. The issue is that many users assume "encrypted email" provides broader protections than it does.
The Ecosystem Lock-In
Over the past five years, Proton has expanded into a suite: ProtonMail, ProtonCalendar, ProtonDrive, ProtonVPN, ProtonPass. This is a reasonable business strategy — offering a privacy-preserving alternative across common services. But it creates a dependency architecture. The more of Proton's suite you adopt, the harder it is to leave any one piece of it.
More practically: Proton's services are interoperable within the Proton ecosystem and awkward outside it. ProtonMail uses OpenPGP for email encryption. If you want to use a third-party email client like Thunderbird or Apple Mail, you need the Bridge desktop app — a background process that translates Proton's API into IMAP/SMTP. The Bridge is not available on mobile. On iOS and Android, you use Proton's app or nothing.
There Is No Chat
ProtonMail does not have encrypted real-time messaging. You can send emails. You cannot send an instant message to another Proton user in the same interface.
This means most Proton users end up maintaining a split communication stack: ProtonMail for email, Signal (or Telegram, or WhatsApp) for chat. Those are different identities, different apps, different trust assumptions. Contacts who get your encrypted emails are not the same contacts who get your Signal messages, unless you've manually bridged them.
For security-conscious users, this fragmentation is more than inconvenient — it's a real attack surface. Every additional communication channel is a potential exposure point.
OpenPGP's Group Problem
OpenPGP was designed for 1:1 encrypted communication. It works well for that. Group key management, however, is an afterthought — bolt-on implementations vary by client, key discovery is often manual, and adding or removing group members requires distributing new keying material through side channels.
Modern messaging protocols like MLS (Messaging Layer Security, RFC 9420) solve this with cryptographically sound group operations that are auditable, efficient, and support forward secrecy even as membership changes. OpenPGP has no equivalent.
What to Look For in an Alternative
If ProtonMail's constraints are starting to matter for your use case, here's what actually separates strong private email from marketing:
| Property | Why It Matters |
|---|---|
| Client-side key derivation | Your passphrase should never leave your device. Derive encryption keys locally via PBKDF2 or Argon2; send only a derived auth credential to the server. |
| Integrated chat on the same identity | Reduces fragmentation. Your email contacts and chat contacts should be the same people, in the same app. |
| Open protocol for messaging | Proprietary encryption protocols can't be audited by the community. Look for MLS (RFC 9420) or Signal Protocol implementations. |
| Transparent business model | Privacy services that survive on advertising are misaligned with your interests. Paid subscriptions are a better signal. |
| Honest threat model documentation | Any service that claims to protect you from legal compulsion is either lying or self-hosted. Read the fine print. |
A Word on Self-Hosting
If your threat model genuinely requires protection from legal compulsion by your jurisdiction's government, no commercial email service — ProtonMail, Tutanota, Fastmail, or anyone else — will reliably provide it. The only approach that works is infrastructure you control, in a jurisdiction where you trust the courts, administered by someone (you) who can't be compelled to log you without your knowledge.
Self-hosting email is operationally complex and hard to maintain securely. Most people shouldn't do it. But it's worth being honest about: if legal compulsion is your actual threat, you're not shopping for a better SaaS — you're shopping for a different model entirely.
Where Haven Fits
We built Haven because we wanted a single app that handles encrypted email and encrypted real-time chat under the same identity. PGP for email interoperability with the broader world; MLS protocol for group-safe, forward-secret messaging with other Haven users.
Haven is newer than ProtonMail and has fewer years of battle-testing. That's a real trade-off and you should weigh it. ProtonMail has been audited multiple times and has a long track record. Haven's advantage is the integrated model — one app, one identity, email and chat together, with a key derivation model that means your passphrase never leaves your device (not even as a hash of itself).
If you're evaluating alternatives, we think that's the right starting point: not "which service has the best marketing" but "which model matches my actual threat model and usage pattern."