How password managers actually work — the technical model without the jargon

Most explanations of how password managers work stop at 'they store your passwords securely.' That description is accurate at the level of a billboard. It doesn't explain what 'securely' means, what happens to your data when it leaves your device, how the company can claim they cannot read your passwords, or what actually protects you if the company's servers are breached. Understanding the model matters because your behaviour — specifically your master password choices and recovery setup — directly affects how well the model holds.

The model is also not uniform. Different password managers make different architectural choices — about where encryption happens, what metadata they retain, how key derivation is performed, and what the recovery options are. These choices produce products that all describe themselves as 'secure password managers' but have meaningfully different security properties.

The core question to understand is: which party holds which keys, and what can each party access as a result?

The most common assumption is that the password manager company stores your passwords and protects them with its own security. This is backwards. In a zero-knowledge architecture, your passwords are encrypted on your device before they ever reach the company's servers. The company holds encrypted ciphertext. Your master password, which never leaves your device, is what generates the decryption key. The company's security infrastructure protects the ciphertext from being stolen; it has no ability to decrypt it regardless of that infrastructure's strength.

A second assumption is that the master password is sent to the company's servers during login to verify it. It is not. The password manager derives a key from your master password using a key derivation function (PBKDF2, Argon2), uses one part of that derivation to encrypt your vault, and uses a separate part to authenticate to the server. The server receives an authentication token, not your master password. This is why master password recovery by the company is impossible — they have never had it.

A third assumption is that 'encrypted' means all your data is protected. Encryption applies to the credential content: passwords, usernames stored in password fields, secure notes. It typically does not apply to metadata: the website URLs your credentials are attached to, the item titles, your IP address at login, and device information. Most password managers store URL metadata in plaintext on their servers. Proton Pass is the exception in the consumer category.

The technical flow on a zero-knowledge password manager: you enter your master password on your device. The client derives an encryption key using a KDF (PBKDF2 or Argon2). Your vault is decrypted locally using that key. When you save a new credential, it is encrypted locally before upload. The server receives and stores ciphertext only. When you log in on a new device, the encrypted vault is downloaded and decrypted locally with the key derived from your master password. At no point does the server hold a key that can decrypt your data.

Sync works by uploading encrypted changes to a cloud server and downloading them on other devices. The server acts as an encrypted data store and synchronisation layer, not as a credential database the company can query. This architecture is what enables the 'we cannot access your passwords' claim to be technically accurate rather than merely a policy statement.

The model's security properties depend on three things you control: the strength of your master password (which determines how hard it is to brute-force the key from stolen vault data), the KDF and iteration count configured for your account (which determines how expensive each brute-force attempt is), and your recovery options setup (which determines what happens if you lose access). All three are in your control, not the company's.

This model description applies to cloud-based zero-knowledge password managers. Self-hosted deployments (Bitwarden) change the server party in the model — you become the server operator, with the same inability to decrypt vault contents but with full control over the infrastructure holding the ciphertext.

Zero-knowledge architecture protects against the server being compromised or compelled. It does not protect against a compromised device — malware running on your device when the vault is unlocked can read credentials before encryption. The model described here is the server-side architecture; device-side threats require separate consideration.