The objection to password managers is immediate and reasonable. Putting every credential in one place creates a single point of failure.
The objection is correct and the alternative is worse, and understanding why requires knowing what actually happens in a breach.
What the alternative actually is
The realistic comparison is not against a perfect system. It is against what people do without one.
Which is: a small number of passwords reused across many services, with minor variations, chosen to be memorable and therefore guessable.
The consequence is credential stuffing. When any one service is breached, and services are breached constantly, the leaked credentials are tried automatically against every other major service.
Reuse means one breach anywhere compromises everything. That is the actual threat most people face, and it is far more common than a password manager being compromised.
How the encryption works
The technical point that addresses the objection directly.
Well-designed password managers encrypt the vault on your device with a key derived from your master password. The provider stores only the encrypted blob and never has the key.
Which means that if the provider is breached and attackers take everything, what they take is encrypted data they cannot read without each user's master password.
This is the architecture, it is verifiable in the open source implementations, and it has been tested in practice.
What happened when one was breached
Worth describing because it is instructive rather than reassuring.
A major provider suffered a significant breach in which encrypted vaults were taken along with some unencrypted metadata, including the web addresses stored in those vaults.
The encrypted contents remained encrypted. Users with strong master passwords and current key-derivation settings were in a reasonable position.
Users with weak master passwords, or on older accounts with weaker settings that had never been upgraded, were genuinely exposed to offline brute-force attempts against their stolen vaults.
And the unencrypted metadata was itself sensitive, revealing which services each user held accounts with.
The lessons are specific: the architecture held, the implementation details mattered enormously, and what was stored unencrypted mattered more than anybody had considered.
What that implies for how to use one
A long, unique master password, which is the one credential everything else rests on. Length matters more than complexity for resisting brute force, and a passphrase of several random words is both stronger and more memorable than a short complex string.
Two-factor authentication on the manager itself.
Checking the key-derivation settings on an older account, since defaults have strengthened over time and existing accounts are not always migrated.
And knowing what the provider stores unencrypted, which reputable ones document.
Local versus hosted
The choice worth making deliberately.
Hosted managers synchronise across devices, which is convenient and is why most people use them. The vault sits on somebody's servers, encrypted.
Local managers keep the vault on your machine. Nothing to breach centrally, and you handle backup and synchronisation yourself.
The trade is a real one. Local removes the central target and introduces the risk that you lose the file, which is a mundane failure mode and a much more likely one for most people.
Either is a substantial improvement on reuse.
The parts that matter more than the manager
Two things that do more for account security than any choice of vault.
Two-factor authentication on important accounts, which defeats credential stuffing entirely even if a password is known. App-based or hardware-key methods are meaningfully stronger than codes sent by text, since text-based codes are vulnerable to number-porting attacks.
And passkeys, which replace passwords with cryptographic keys held on a device. There is nothing to reuse, nothing to phish in the conventional sense, and nothing to leak in a breach. Adoption is uneven and the direction is clear.
The practical recommendation
Use a manager, because the alternative is reuse and reuse is the actual threat.
Make the master password long.
Put two-factor on everything that matters, especially the manager.
Adopt passkeys where they are offered.
And accept that this is risk management rather than risk elimination, which is the honest framing for all of it.
Recovery, which people neglect
The failure mode that is more likely than a breach.
If the master password is lost, and the design is genuinely zero-knowledge, the provider cannot recover the vault. That is the point of the architecture and it is unforgiving.
Which makes recovery planning essential. Most providers offer emergency access arrangements, recovery codes, or a designated contact.
Setting one up, and storing a recovery code somewhere physical and safe, takes a few minutes and prevents the specific disaster of being locked out of everything at once.
It is also worth considering what happens if you are unavailable and somebody else needs access, which is an unpleasant thought and a real planning problem.
Shared credentials
The situation most households and small teams handle badly.
Accounts used by several people end up shared by message, by email, or on paper, all of which are worse than the reuse problem this whole exercise is meant to solve.
Most managers support shared vaults, which allow a credential to be available to several people, changed once, and revoked when somebody leaves.
That last property is the important one. A shared password that has been sent by message cannot be un-sent, and the practical consequence is that it is never changed.