Zero-Access Encryption

An encryption model where data is encrypted on the user's device with a key the provider never holds, so the provider cannot decrypt stored content even under legal compulsion or a server breach.

Zero-access encryption means the service provider stores your data only in encrypted form, with a key derived from your password or device that never leaves your side. Even if a court orders the provider to hand over your files, mailbox, or vault, the result is ciphertext the provider cannot read.

Zero-access vs end-to-end encryption

The two terms overlap but answer different questions:

• End-to-end encryption describes data in transit between two parties. Messages are encrypted on the sender’s device and can only be decrypted by the recipient. Used by Signal, Threema, and Proton Mail between Proton users.
• Zero-access encryption describes data at rest on the provider’s servers. The provider holds only ciphertext and cannot decrypt it, regardless of who is asking.

A service can be end-to-end encrypted without being zero-access (if the provider holds the keys), and zero-access without being fully end-to-end (if encryption happens only on the provider side). The strongest model combines both.

How it works in practice

1. Key derivation on your device. Your password runs through a key derivation function (Argon2, PBKDF2, scrypt) to produce an encryption key. This step happens locally.
2. Encryption before upload. Data is encrypted with that key before anything reaches the provider’s servers.
3. Server stores ciphertext only. The provider receives encrypted blobs and stores them. The key never touches their infrastructure.
4. Decryption on your device. When you access your data, the provider sends back the ciphertext, and your device decrypts it locally using the same key.

The key difference from provider-managed encryption (Dropbox, Google Drive, Gmail) is that those services can decrypt your data on request, because they hold the keys. Zero-access providers architecturally cannot.

Why it matters

• Server breach protection. If the provider’s servers are compromised, attackers get encrypted blobs with no practical path to decryption.
• Legal compulsion protection. A court order to hand over user data yields ciphertext. The provider cannot be compelled to decrypt what they do not hold the keys to.
• Trust minimization. You do not have to trust the provider’s internal access policies. The cryptography enforces the boundary, not an HR rule.

Services using zero-access encryption

• Proton Mail encrypts inbox contents with a key derived from the account password. Even Proton cannot read stored messages.
• Tresorit encrypts files client-side before upload, with a key hierarchy wrapped by the user’s password.
• Proton Drive and Proton Pass follow the same architecture across the Proton ecosystem.
• NordPass, Bitwarden, and 1Password all use zero-access (often called “zero-knowledge” in the password manager space, which is the same idea).

What zero-access encryption does not protect

• Account takeover. If an attacker gets your master password, they get the key. 2FA is essential.
• Device compromise. If malware runs on your device, it can read decrypted data in memory.
• Metadata. Providers may still see who logged in when, from which IP, and how much data was accessed. Contents are encrypted, but connection metadata is often not.
• Shared data. When you share encrypted data with a recipient, the recipient’s device now holds the plaintext. The encryption boundary ends where the sharing begins.

Why it matters for Swiss businesses

Under the nDSG, businesses must implement “appropriate technical and organizational measures” to protect personal data. Zero-access encryption is one of the cleanest ways to meet that requirement for cloud-hosted data: the provider architecturally cannot leak what they cannot read. Combined with Swiss jurisdiction, it gives businesses a defensible answer to the question “what happens if your provider is compelled to hand over customer data?”