Password Manager: What Is a Password Manager & Do I Trust It?

The Question Behind the Question

Nobody asks what a password manager is out of curiosity. They ask because they have been told to use one and something about it feels wrong: putting every password in one place, with one company, behind one password, sounds like the opposite of security.

That instinct deserves a real answer rather than reassurance. So this page is about the mechanism — what the thing actually does, how the encryption works, what happens when the provider is breached, and where the model genuinely fails. If you want the argument for adopting one, that is why you need a password manager. If you want a product recommendation, that is best password managers 2026. This is the how-it-works.

What It Actually Is

A password manager is an encrypted database — the vault — plus three pieces of software around it: a generator, a filler, and a synchroniser.

The vault holds entries. Each entry is typically a site, a username, a password, and optional extras such as notes, card details, or a time-based code seed.

The generator produces passwords no human would choose: long, random, and different for every entry. This is the part that does the actual security work, and it is the part people underuse.

The autofill puts credentials into login forms so you never type them. This is what makes unique passwords survivable — you are not remembering two hundred strings, you are remembering one.

The sync copies the encrypted vault between your devices, usually through the provider's servers.

You remember one master password. The software handles everything downstream of it.

The Part That Answers the Instinct

The reason "all my passwords in one place" is not as reckless as it sounds is zero-knowledge encryption, and it is worth understanding rather than accepting on faith.

Your vault is encrypted on your device, before anything leaves it. The key used is derived from your master password, and the master password itself is never sent to the provider. What reaches their servers is ciphertext and nothing else.

The consequence is the thing that matters: the provider cannot read your vault. Not because they promise not to — because they do not possess the key. If their servers are breached, what an attacker takes is an encrypted blob. Without the master password it is not a database of your passwords, it is noise.

This is an architectural property, not a marketing claim, and it is checkable. It is why reputable providers commission independent audits and publish them, and why the audit — who performed it, against what scope, and when — is the thing worth looking at rather than the word "audited" on a pricing page.

How the Master Password Becomes a Key

The step between "a phrase you can remember" and "a key that resists attack" is deliberately slow, and the slowness is the point.

A key derivation function takes your master password and grinds it through a large number of iterations, or through a memory-hard process, to produce the encryption key. The purpose is to make each guess expensive. An attacker with a stolen vault has to run that same expensive process for every candidate password they try, which turns an attack that would take minutes into one that takes an impractical amount of time — provided the master password is long and genuinely random.

That proviso is doing a lot of work. Key derivation buys time proportional to how hard the password is to guess. A short or predictable master password fails no matter how good the derivation is. The method for choosing one that does not is in how to create a master password, and it is the single highest-leverage thing on this page.

What It Protects You From, and What It Does Not

The autofill row is more useful than it looks. A manager fills credentials only on the domain the entry was saved for, which means a convincing replica at a lookalike address gets nothing. You have to override it deliberately. That silent refusal to fill is one of the better phishing defences most people have, and it works precisely because it is automatic.

Where the Model Genuinely Fails

Three honest failure modes, because a page that only lists benefits is not an explanation.

The endpoint. Once the vault is unlocked on a compromised machine, encryption has already done its job and stopped mattering. Malware with a foothold can read the screen and the clipboard. No arrangement of vaults changes that, which is why device hygiene sits underneath all of this.

The master password. It is a single point of failure by design. Lose it and, in a genuinely zero-knowledge system, the provider cannot recover your vault — that is the same property that protects you from them. Guess it, and everything is open.

Circular lockout. If the recovery codes for the vault are stored inside the vault, there is no way in when you cannot open it. This trap is common and the fix is unglamorous: the manager's own recovery codes go on paper, outside the manager. The rest of that discipline is in 2FA recovery codes explained.

What to Look For in One

• Zero-knowledge architecture, confirmed by a published audit rather than asserted in the marketing.
• A named, dated independent audit. The scope and the date are the informative parts.
• Second-factor support on the vault itself, ideally including hardware keys.
• Genuine cross-platform coverage — every operating system and browser you actually use, because a manager that does not work somewhere is a manager you will work around.
• Breach monitoring, so a credential in your vault appearing in a known breach reaches you.
• An export path. A vault you can leave is a vault you chose to stay in, and the day you want to move is the wrong day to discover the door is locked.
• Emergency access, so a trusted person can reach it after a delay if something happens to you.

Two products worth knowing while you are comparing: NordPass and Proton Pass both sit in this bracket, and the head-to-head against the open-source alternatives is in 1Password vs Bitwarden.

Getting From Here to Working

The adoption failure is trying to do it all in one sitting, deciding it is unbearable, and abandoning it. It does not have to be one sitting.

Install the app and the browser extension. Set a long random master passphrase and turn on a second factor for the vault, keeping its recovery codes on paper. Import whatever your browser has already saved — every manager supports this. Then stop.

From that point, let it work opportunistically: each time you log in to something, let the manager replace that password with a generated one. Nothing is scheduled, nothing is a chore, and within a couple of months the accounts you actually use have all been rotated. The ones you never use were not worth an afternoon anyway.

The whole stack, set up in order and in one go if you would rather, is in how to set up a complete security stack.

The Counter-Argument, Fairly Put

There is a coherent position that says a browser's built-in manager is enough for most people. It is free, it is already there, it generates and syncs, and the friction of adopting nothing new is a real advantage — the best security tool is the one that gets used.

It is a fair argument and it is largely right for a low-stakes account list. Where it stops being right is at the edges: cross-browser and cross-platform coverage, sharing credentials with another person safely, storing things that are not passwords, an export path that is not tied to a browser vendor, and a vault protected by a second factor of its own. If none of those matters to you, the built-in one is a defensible choice and it is far better than reuse. If any of them does, the dedicated tool earns its keep.