How Password Managers Work

The five layers of a password manager

1. 1. Vault data. Logins are the core, but many products also store passkeys, secure notes, payment cards, identities, and one-time-password seeds. Which fields and metadata are encrypted differs by product.
2. 2. Vault encryption. The app encrypts vault records before hosted data leaves the device. Modern designs use authenticated encryption, or encryption plus a separate integrity check, so tampering can be detected.
3. 3. Key protection. A random vault key encrypts the data. A key derived from your account password, sometimes combined with a device-held secret, protects that vault key.
4. 4. Authentication and sync. Signing in proves to the service that you may download the encrypted vault. Authentication should not require giving the provider a usable vault key.
5. 5. Device unlock and recovery. Biometrics can release a key already protected by the operating system; they do not replace the underlying vault cryptography. Recovery determines what happens when every trusted device or secret is lost.

From account password to encryption key

Passwords are variable-length, human-created input. Encryption needs a fixed-size, high-quality key. A key derivation function (KDF) combines the password with a unique salt and deliberately repeats expensive work to produce that key.

A salt prevents attackers from reusing one precomputed table across many users. Expensive KDF parameters make every password guess costlier. Argon2id also requires memory, which makes large parallel guessing systems more expensive. PBKDF2 is older but remains common when configured with a sufficiently high iteration count.

KDF names alone do not decide security. A long unique account password, a device-generated secret such as 1Password's Secret Key, rate limits for online login, authenticated encryption, and an upgrade path for parameters all matter.

Authentication is not decryption

These are separate jobs. Authentication tells the service which encrypted vault you may download. Decryption turns that encrypted data into readable records on an approved device. A strong architecture keeps the provider from receiving the material needed for the second job.

"Zero knowledge" is useful shorthand, but not a complete specification. Check what data is end-to-end encrypted, which metadata remains visible, how new devices are approved, and whether recovery can recreate decryption access.

How current password-manager architectures differ

The products below all protect credentials, but they make different choices about password hardening, device secrets, storage, sync, and recovery. This is an architecture comparison from published documentation, not a security ranking.

What happens during sync?

In a hosted end-to-end encrypted manager, a device encrypts a change and sends the ciphertext to the service. Another approved device downloads the ciphertext and decrypts it locally. The server still handles account routing, versions, sharing membership, and availability, so it may retain operational metadata even when it cannot read vault fields.

Local-first tools such as KeePassXC remove the hosted vault service from this picture. You control the encrypted database file and may sync it through a separate file service. That increases control but makes conflict handling, backup, and recovery your responsibility.

Recovery is part of the security model

If only you hold the decryption material, losing every copy can make the vault unrecoverable. Products address this with trusted devices, emergency kits, family or administrator recovery, recovery contacts, or escrowed keys protected by other credentials. Each convenience changes who can restore access and under what conditions.

Before committing to a manager, test recovery without deleting your working vault. Confirm that you can locate required secrets, understand what a helper or administrator can do, and have a safe physical backup where appropriate.

Are browser password managers different?

Built-in managers from Google, Apple, and Mozilla now generate, save, sync, and fill passwords; several also support passkeys, sharing, and breach alerts. They can be the right answer for someone who lives in one ecosystem.

Dedicated managers usually earn their keep through broader browser and operating-system support, richer vault types, family or team controls, and more deliberate export and recovery workflows. The security question is not "browser bad, app good"; it is which trust boundary and workflow fit you.

What if the service or device is compromised?

• Stolen server data: attackers may try account-password guesses against encrypted vaults offline. Strong KDFs and high-entropy secrets reduce this risk.
• Compromised client update: code running on an unlocked device can potentially capture readable data. Signed updates, reviews, and rapid patching matter.
• Compromised device: malware or an attacker controlling an unlocked session may read filled or displayed credentials regardless of server-side design.
• Phishing: autofill can help by matching domains, but users can still reveal credentials or recovery material to a convincing attacker.

A practical safety checklist

• Use a long, unique account passphrase and never reuse it elsewhere.
• Enable multi-factor authentication and protect recovery codes.
• Keep the manager, browser, and operating system updated.
• Review signed-in devices and remove ones you no longer control.
• Test recovery and export before an emergency.
• Lock devices quickly and use full-disk encryption.

Frequently asked questions

Primary sources

• 1Password security design
• Bitwarden security white paper
• Proton Pass security model
• Apple iCloud Keychain security overview
• KeePassXC user guide

Product details were checked against these vendor sources on July 25, 2026.