Home › Password Managers › Guide

Password Managers: What Actually Matters When Choosing One

Table of contents

1. Why the feature lists mislead
2. Zero-knowledge architecture: the one design decision that matters
3. Recovery: where most people actually get burned
4. Audits and breach history
5. Migration cost: the exit you are buying
6. Comparison: free, paid, and self-hosted patterns
7. Bottom line
8. Red flags to watch for
9. Recovery and the master-password trap
10. Leaving a password manager: the export test
11. FAQ

Why the feature lists mislead

Password manager marketing has converged on a shared feature list: unlimited passwords, cross-device sync, a browser extension, dark-web monitoring, maybe a document vault. Because every serious product has all of it, the feature list no longer discriminates. What separates products is structural — how the vault is encrypted, what happens when you lose your master password, what independent reviewers have found, and how hard the product is to leave. Those four questions organize this guide, and they can all be answered from public material in under an hour.

Zero-knowledge architecture

"Zero-knowledge" means the service's servers hold only encrypted data, and the key to decrypt it is derived from your master password on your device — never sent to the server. The consequence is the entire point: a breach of the company's servers yields ciphertext, and a subpoena yields ciphertext too.

The way to evaluate this claim is not to trust the phrase but to read its mechanics, all of which are documented by the serious products:

• Key derivation. The master password should be stretched with a deliberately slow function (argon2 or PBKDF2 with a high iteration count). Slow derivation is what makes a stolen vault expensive to attack. Product whitepapers publish these parameters; vagueness here is a warning sign.
• Where decryption happens. Some products decrypt in the cloud and stream results; zero-knowledge products decrypt locally. The distinction is usually in the security whitepaper, not the homepage.
• What the vendor can see. URLs of vault items, usernames, and notes should all be inside the encrypted blob. Some products keep certain fields (like item titles used for sync indexing) in plaintext metadata — a smaller point, but the honest vendors disclose it.

Recovery: where most people actually get burned

The real-world failure mode of password managers is not cryptographic. It is a forgotten master password with no recovery path — or worse, a recovery path so permissive that it undermines the zero-knowledge design. Products handle this tension differently, and the differences are decisive:

• No recovery at all. Forget the master password, the vault is gone. Maximally secure, maximally unforgiving; suits users with disciplined backups of the emergency kit.
• Recovery key generated at setup. A long random string printed and stored offline can reset access without the vendor ever learning it. This is the pattern most products have converged on, and it is a good balance.
• Emergency access / designated heir. A time-delayed handoff to a trusted contact. Valuable for families and estate planning; check whether the grantee's access is end-to-end encrypted or whether the vendor mediates it.
• Family plans with admin override. Convenient, but an admin who can reset a member's vault has a technical master key to household secrets. Decide whether that is a feature or a liability for your household.

The habit to adopt at setup, whatever the product: generate and physically store the recovery kit the product offers, then test it once on a second device.

Audits and breach history

Established password managers publish third-party security audits, and the better ones repeat them. As with VPNs, an audit is a snapshot: read what was examined, when, and what was fixed. Some audit summaries are published in full; some are one-paragraph attestations. The depth of disclosure is itself a signal.

Breach history deserves the same calm reading. The industry's most instructive incident remains the 2022 LastPass disclosure, in which encrypted vaults were taken from cloud storage; the debate that followed centered on how much of each user's vault was exposed by the strength of that user's master password and the product's key-derivation parameters at the time the vault was created. The durable lesson is not "never trust a vendor" but "the master password and the derivation parameters are load-bearing" — which is exactly why the zero-knowledge section above tells you to read the whitepaper.

Migration cost: the exit you are buying

Every reputable manager supports the standard CSV export, which means migrating out is usually a weekend afternoon, not a project. But CSV export quality varies: some products export everything including attachments and TOTP seeds; some export logins only and drop secure notes and identities. Before committing long-term, check the export documentation — the generosity of the exit is a better predictor of vendor behavior than the generosity of the welcome discount.

Two migration notes that recur in practice: TOTP seeds exported in CSV are plaintext secrets and should be re-enrolled rather than carried over; and browser-saved passwords, the usual previous home, export cleanly but arrive with messy titles — dedupe after import, not before.

Comparison: free, paid, and self-hosted patterns

Bottom line

Choosing a password manager is choosing a custodian for one file that matters more than almost anything else you store in the cloud. The products worth considering have all passed the basic bars: local decryption, published derivation parameters, repeated audits, honest breach communication, and a clean export path. The choice among them is then about fit — recovery philosophy, family sharing semantics, and price — rather than security theater. Pick one, store the recovery kit offline, and stop reusing passwords; that combination outperforms any feature comparison.

Red flags to watch for

• No published security whitepaper. Every serious product maintains one. Its absence means you are being asked to trust marketing instead of documentation.
• "Bank-level encryption" as the only security claim. True but empty — the phrase describes the same standard everyone uses and tells you nothing about the architecture around it.
• Browser-extension-only products with no export. If you cannot leave, you are not a customer; you are a hostage.
• Lifetime deals on subscription products. Password managers carry ongoing sync infrastructure and security-response costs. A lifetime price is a bet on solvency, not a bargain.
• Recovery that emails you your master password. Any recovery path that can reconstitute your master password at the vendor's end means the vendor can read your vault. This should end the evaluation immediately.

Recovery and the master-password trap

The recovery section above describes the patterns vendors offer. It is worth being explicit about why the master password is the one credential you cannot casually reset, because the marketing around "account recovery" often blurs two different things: recovering access to your account, and recovering the contents of your vault.

In a zero-knowledge design these are the same only if the recovery mechanism is itself zero-knowledge. If the vendor can "reset your password and email you a link," what they have actually reset is their ability to let you log in to their service — but if the vault is encrypted such that only your master password derives the key, a reset link gets you into an empty account, not your data. That is the trap: users expect a password reset to restore their vault, and in a properly designed zero-knowledge product it cannot. The vault is only recoverable through the mechanisms set up in advance — the offline recovery key, or a granted emergency-access contact.

This is why the "store the recovery kit offline and test it once" habit appears in the guidance, and why it is the single most important setup step. A recovery key you have never tested is a hope, not a backup. The test is cheap: on a second device or a clean browser profile, use the recovery key to regain access and confirm the vault opens. If it does not, you have discovered the gap before you actually need it.

Emergency access deserves a closer look for households. The useful variant is time-delayed and end-to-end encrypted: the designated contact requests access, you are notified, and a delay gives you time to cancel if the request is fraudulent. The weaker variant routes the handoff through the vendor, who then holds or mediates the key — which reintroduces exactly the custodial risk the architecture was meant to remove. Read the emergency-access documentation line by line before granting it to anyone.

Leaving a password manager: the export test

Migration cost was covered above as a structural criterion. Here it is framed as an action you can take before committing, not after: run the export test during your trial, not on the day you decide to leave. The test answers two questions a feature table never will — what the product actually exports, and whether that export is usable elsewhere.

The practical steps:

• Export the full vault, not just logins. Check whether secure notes, identities, attachments, and TOTP seeds are included. A product that exports logins only is quietly raising your exit cost.
• Inspect the file before trusting it. Open the CSV in a plain-text editor and confirm it is what you expect. TOTP seeds and any exported secrets appear in plaintext, which is the correct format for portability but a risk if the file is left lying around — delete or encrypt it after the test, and re-enroll TOTP rather than carrying seeds to a new manager.
• Confirm import on the other side. The real test is not "can I export" but "can I import this somewhere else." A clean round-trip through a second product, or through a self-hosted option, proves the exit is real.
• Note the format lock-in. CSV is universal but lossy for structured items; some products also offer an encrypted native export. Both matter: CSV for portability, native for a faithful backup you control.

The generosity of the exit is, as noted, a better predictor of vendor behavior than the welcome discount. A product confident in its value has no reason to make leaving hard, and the export documentation tells you which kind you are dealing with.

FAQ

Are browser-built-in managers enough?

For one device and one ecosystem, a browser built-in is better than reusing passwords and is a reasonable starting point. It typically falls short on zero-knowledge cross-device sync, structured secure notes, granular sharing, and a documented emergency-access path. "Enough" depends on whether you live in one browser on one platform or across several.

What is zero-knowledge architecture?

A design in which the vendor's servers store only encrypted data and the key is derived from your master password on your device, never transmitted. A server breach or a legal demand then yields ciphertext, not your passwords. The claim must be checked against the whitepaper, not the homepage.

Can a password manager be hacked?

Anything online can be attacked, but the relevant question is what an attacker gains. In a sound zero-knowledge design, a stolen vault is ciphertext, and its value depends on the strength of your master password and the product's key-derivation parameters. The 2022 LastPass disclosure remains the clearest illustration: the exposed vaults were only as strong as each user's master password and the derivation settings in force when the vault was created.

What happens if I lose the master password?

In a genuine zero-knowledge product, the vendor cannot reset it for you, because the vendor never holds the key. Recovery is possible only through a recovery key you stored offline or an emergency-access grant you set up in advance. This is the single most important thing to configure at setup.