What zero-knowledge actually protects — and the gap most people miss

Zero-knowledge is the most cited security property in password manager marketing. Every provider in the mainstream category claims it. The phrase implies that the company knows nothing — that your data is entirely opaque to them. This is partially true. It is not completely true. Understanding the distinction is more practically useful than taking the claim at face value.

The 2022 LastPass breach made the gap concrete for millions of users. LastPass is a zero-knowledge password manager. Its credentials are encrypted on device. The company cannot decrypt vault contents. And yet the breach produced information that was genuinely useful to attackers: the list of every website every affected user has accounts on. That data was stored in plaintext. Zero-knowledge didn't cover it.

The question worth asking about any password manager is not 'do you have zero-knowledge architecture?' but 'what specifically does your zero-knowledge model cover, and what does it leave outside?'

The standard assumption is that zero-knowledge means the company has no readable information about you. The architecture ensures they cannot read your credentials. It says nothing about the metadata structure around those credentials. Website URLs, vault item titles, usernames stored outside password fields, the number of items in your vault, your login frequency, the IP addresses you connect from, and your account email address are all potentially visible to the provider depending on implementation choices. Most providers store URL metadata in plaintext alongside encrypted vault entries.

A second assumption is that zero-knowledge is a binary property — either a provider has it or they don't. In practice there are degrees. Standard zero-knowledge covers credential content. Extended zero-knowledge — implemented by Proton Pass among consumer managers — extends encryption to URL metadata, item titles, and usernames. Full zero-knowledge with self-hosting (Bitwarden's architecture) removes even the encrypted ciphertext from the provider's infrastructure entirely. These are materially different implementations of the same claimed property.

A third assumption is that legal compulsion is irrelevant under zero-knowledge because the provider has nothing to hand over. For credential content, this is largely correct — a zero-knowledge provider served with a court order can produce encrypted blobs that are useless without the master password. For URL metadata stored in plaintext, the situation is different. That data is readable and producible under legal process in any jurisdiction.

Zero-knowledge in practice means: your passwords and secure notes are encrypted on your device before leaving it, and only you hold the key derived from your master password. The provider stores ciphertext they cannot read. Legal compulsion produces that ciphertext, which is computationally impractical to decrypt without the master password. This is a genuine and valuable property.

What zero-knowledge doesn't automatically cover: URL metadata (which websites you have accounts on), login frequency and timing patterns, device fingerprints and IP addresses at authentication, the count and structure of vault items, and account-level information like billing details and email address. The providers who claim zero-knowledge without qualification are describing their credential content architecture, not their complete data handling model.

The practical implication: choosing a zero-knowledge password manager is necessary but not sufficient for a complete privacy posture. Choosing one that also encrypts URL metadata (Proton Pass), is open-source so those claims are verifiable (Bitwarden, Proton Pass), and is incorporated in a jurisdiction with limited legal reach (NordPass in Panama, Proton Pass in Switzerland) adds layers beyond the zero-knowledge baseline.

Zero-knowledge architecture is a server-side property. A compromised device where malware is running when the vault is unlocked defeats zero-knowledge entirely — the attacker reads credentials before encryption. This guide discusses server-side protections; device security is a separate but equally important consideration.

No external party can fully verify that a provider's production systems behave identically to their published architecture or audited code. Open source reduces this uncertainty significantly; it does not eliminate it. Reproducible builds — where the published code can be verified to match the distributed binary — represent the gold standard and are not yet fully implemented by any mainstream password manager.