Affiliate links present. Disclosure
Password Managers — Guide
The limits of zero-knowledge — what your password manager can and cannot protect
What makes this confusing
Zero-knowledge architecture is a genuine and valuable security property. It also has a name that creates unrealistic expectations. 'Zero knowledge' means the provider has zero knowledge of your credential content — your passwords, secure notes, and other vault items. It does not mean the provider knows nothing about you. It does not mean your data is protected in all circumstances. It does not mean your vault is invulnerable to every attack vector.
Password manager marketing leverages this name extensively. The technical claim is accurate and meaningful. The gap between the technical claim and the implied broader protection creates a trust surface that security incidents — particularly the 2022 LastPass breach — have exposed concretely. Users who understood zero-knowledge to mean 'complete privacy' discovered that URL metadata, billing information, and usage patterns were in attacker hands despite the vault contents remaining encrypted.
This guide maps the specific boundaries of what zero-knowledge architecture covers and what falls outside it. The goal is calibrated trust, not reduced confidence — zero-knowledge is genuinely valuable when you understand what it actually protects.
What people usually assume
The assumption 'zero-knowledge means the company knows nothing about me' conflates credential content protection with complete privacy. Zero-knowledge covers what's inside the encrypted vault. It does not cover: your email address (used for account management and marketing), IP addresses at login (logged for fraud detection and legal compliance), device fingerprints and browser information, login timestamps and frequency, the count and structure of vault items, and URL metadata stored alongside encrypted credentials by most providers. All of this is potentially visible to the provider under standard implementations.
A second assumption is that zero-knowledge makes the provider immune to legal compulsion. For vault credential content, this is substantially true — the provider can produce ciphertext that is computationally impractical to decrypt without the master password. For the metadata categories above, the provider can potentially produce readable data under legal process. The strength of this protection depends on both the implementation details and the jurisdiction of incorporation.
A third assumption is that zero-knowledge protects against all threat actors. Zero-knowledge protects against the provider being breached or compelled. It does not protect against: malware on the user's device that reads credentials from an unlocked vault; phishing that captures credentials as they are autofilled; an attacker who has your master password; or recovery mechanisms that, when improperly configured, create backdoors.
What's actually true
Zero-knowledge architecture effectively protects: encrypted vault contents from server-side breach; credential content from legal compulsion directed at the provider; and vault data from provider employees. These are the threat scenarios zero-knowledge was designed to address, and it addresses them well. A provider served with a court order can produce encrypted vault data that is useless without the master password. A provider breached by an attacker exposes the same useless ciphertext. This is a genuine and valuable property.
Zero-knowledge does not protect: URL metadata in implementations that store it in plaintext (all providers except Proton Pass); account metadata including email address and billing information; usage patterns and access logs; device and IP information logged at authentication; or anything visible to the provider on the application layer before encryption happens. These categories are outside the zero-knowledge scope by design or by implementation choice.
The strongest overall privacy posture combines zero-knowledge credential content protection (all providers), metadata encryption (Proton Pass only in this comparison), favourable jurisdiction (NordPass in Panama, Proton Pass in Switzerland), open-source verification (Bitwarden, Proton Pass), and self-hosting to remove the provider entirely (Bitwarden). Each layer addresses a different gap in the zero-knowledge model.
Where this leads
If you want zero-knowledge extended to URL metadata — the specific gap that standard zero-knowledge doesn't cover — Proton Pass is the only option in this comparison that encrypts URL fields, item titles, and usernames.
Proton Pass — extended zero-knowledge including metadataIf you want to remove the provider from the zero-knowledge equation entirely via self-hosting — Bitwarden's self-hosted deployment means your encrypted vault exists on infrastructure you control. The zero-knowledge property still holds; the provider trust question disappears.
Cloud vs. self-hosted — removing the provider from the trust modelIf jurisdiction matters because legal compulsion of metadata is a concern — the jurisdiction guide covers which countries' legal frameworks apply to which providers and what 'legal protection' realistically means in practice.
Password manager jurisdiction — what it means in practiceLimits of this guide
This guide addresses the server-side and architecture-level limits of zero-knowledge. Client-side threats — device compromise, phishing, session hijacking — are outside the zero-knowledge model entirely and require different defences. Zero-knowledge is a meaningful and valuable property within its defined scope; it is not a comprehensive security posture by itself.
© 2026 Softplorer