The most useful thing to understand about a password manager is that its greatest strength and its most alarming limitation are the same design decision, viewed from two angles.
The provider cannot read your vault. That is why a breach at the provider usually does not expose your passwords — attackers get encrypted blobs they cannot open. It is also why, if you forget your master password, nobody can recover it for you. There is no "reset my vault" because there is no copy of the key to reset it with.
Once you see that trade-off clearly, most of the advice around password managers stops feeling arbitrary. So here is what actually happens when you save a password, where the real risks sit, and what the official guidance now says — which has reversed almost everything people were taught about passwords.
What Happens When You Save a Password
The sequence matters, because every security property follows from where each step happens.
- You type your master password. It stays on your device.
- Your device runs it through a key derivation function — a deliberately slow, salted hashing process — to produce an encryption key. Slowness is the point: it makes guessing attempts expensive.
- Your vault is encrypted on your device with that key.
- Only the encrypted result is sent to the provider's servers.
The provider therefore stores something it cannot read. It never receives your master password and never holds the derived key.
NIST's requirements for how any system should store secrets follow the same logic. Under SP 800-63B, memorized secrets "SHALL be salted and hashed using a suitable one-way key derivation function," the salt "SHALL be at least 32 bits in length," and for PBKDF2 the iteration count "SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations." Deliberate slowness is not a quirk of password managers; it is the standard.
Why a Provider Breach Usually Doesn't Expose Your Passwords
When a password manager company is breached, the headline sounds catastrophic and the reality is usually far less so. What leaks is the encrypted vault data. Opening it requires the key, and the key exists only on user devices.
That said, the honest version has two caveats worth knowing:
A weak master password becomes the whole problem. If an attacker has your encrypted vault, they can attack it offline — no rate limits, no lockouts, as many guesses as they like. The key derivation function makes each guess slow, but a short or common master password can still fall. This is precisely why the master password should be long and unlike anything you have used elsewhere.
Not everything in a vault is encrypted equally. Some designs leave metadata — the list of site addresses, for instance — less protected than the passwords themselves. Knowing which services someone uses is useful to an attacker for targeted phishing even without a single password.
So the correct summary is not "a breach doesn't matter." It is: a breach converts a remote problem into a local one that your master password strength decides.
The Same Design Means No Recovery
Now the other face of the same coin. Because the provider never holds your key, it has nothing to reset. Forgetting the master password generally means losing the vault.
This is why the setup advice is insistent about things that feel excessive:
- Write the master password down and store it physically. A sheet of paper in a locked drawer is not the weak link in your security model. Forgetting it is.
- Save the emergency kit or recovery code that most managers issue at signup, offline.
- Set up an emergency-access or inheritance contact if the tool offers one.
Some services now offer account recovery through a device you have already authorised. That is genuinely useful, and worth enabling — but understand it works by having another of your devices hold key material, not by the provider keeping a copy.
Where the Real Risk Sits
The vault encryption is rarely the weak point. Here is the honest threat model, in rough order of how often each actually causes harm.
| Risk | How likely | What stops it |
|---|---|---|
| Reusing a password because you had no manager | Very common | Using a manager at all — this is the whole point |
| Weak master password | Common | Long passphrase, unique to the vault |
| Phishing the master password on a fake login page | Common | A passkey or security key on the vault itself |
| Malware or keylogger on your device | Occasional | Device hygiene, OS updates, full-disk encryption |
| Provider breach with a strong master password | Occasional, low impact | Already handled by the design |
| Someone cracking modern vault encryption directly | Negligible | Not a practical attack |
The top row deserves emphasis, because it reframes the whole question. The realistic alternative to using a password manager is not a perfectly memorised set of unique passwords — it is reuse. And reuse is what turns one company's breach into a problem across your other accounts, which is exactly the mechanism behind credential stuffing. We cover the aftermath of that in what to do after a breach notification.
Row three is the one most people overlook. Your vault login is itself a login, and it can be phished like any other. Putting the strongest available second factor on the vault matters more than on almost any other account — and our comparison of 2FA methods explains why a passkey and an SMS code are not close substitutes here.
What the Official Guidance Now Says
Most people's password habits were shaped by advice that standards bodies have since abandoned. NIST SP 800-63B is explicit, and the reversals are striking.
| Old advice | Current NIST position |
|---|---|
| Change passwords every 90 days | Verifiers "SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)" |
| Force symbols, digits, mixed case | Verifiers "SHOULD NOT impose other composition rules" |
| Short but complex is fine | Verifiers "SHOULD permit... at least 64 characters in length" |
| Never write it down | Physical storage is a reasonable protection against loss |
| Blocking paste improves security | Verifiers "SHOULD permit claimants to use 'paste' functionality" |
| Any password you invent is fine | Verifiers "SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised" |
That final point is worth dwelling on. NIST recommends allowing paste and states plainly that it "facilitates the use of password managers." The official position is not neutral about these tools; it is built around them.
The composition-rule reversal has a clean rationale too. Forcing symbols and quarterly changes produces predictable human patterns — Summer2025! becoming Autumn2025! — while length adds real difficulty. A long passphrase of ordinary words beats a short scramble of symbols, and it is far easier to type on a phone.
Setting One Up Sensibly
Pick almost any reputable manager. The differences between mainstream options are small next to the difference between using one and not. Built-in browser and operating-system managers are legitimate choices and much better than reuse; dedicated tools tend to offer better cross-platform support, sharing, and breach monitoring.
Make the master password a long passphrase. Several unrelated words, memorable to you, used nowhere else. Length is doing the work.
Put a strong second factor on the vault. A passkey or hardware key if supported. This is the account where it matters most.
Store the recovery kit offline and confirm you can actually find it.
Then migrate gradually. Import what you can, and each time you log into something, let the manager replace the old password with a generated one. Prioritise email first, then financial accounts — the same order that applies after a breach, and for the same reason.
Keep it even as passkeys arrive. Passkey support is growing fast — the FIDO Alliance reported five billion passkeys in use in 2026 — but coverage is far from universal, so you will hold passwords for years yet. Most managers now store passkeys alongside them, which makes the manager the natural home for both. See what passkeys fix and what they don't.
Common Misconceptions
"Putting all my passwords in one place is dangerous." It concentrates them, which feels risky, but it replaces reuse — and reuse is the thing that actually causes cascading compromise. A single strong vault with unique passwords everywhere is a much better position than twenty accounts sharing three passwords.
"If they get breached, my passwords are exposed." Usually not. Attackers get encrypted data, and the key never left your device. What determines the outcome is your master password strength, since they can now guess at it offline without limits.
"I can just use my browser's built-in one." You can, and it is far better than nothing. Dedicated managers generally do better on cross-platform access, sharing, and breach alerts — but the browser option is a legitimate choice.
"I should change my passwords every few months." Current NIST guidance advises against arbitrary periodic changes, because it produces predictable patterns. Change a password when there is evidence of compromise, which NIST does require.
"A password with symbols is stronger than a long phrase." Length generally contributes more than character variety, which is why NIST dropped composition rules and asks verifiers to accept passwords up to at least 64 characters.
The Bottom Line
A password manager works by encrypting your vault on your device with a key derived from your master password, then handing the provider a box it cannot open. Every consequence follows from that: a provider breach yields useless ciphertext, and nobody — including the provider — can recover your master password if you lose it.
So the setup that matches the design is: one long, unique master passphrase; the strongest available second factor on the vault; the recovery kit stored offline where you will actually find it; and a written copy of the master password somewhere physically secure. Do that and the tool eliminates password reuse, which is the single most consequential security habit most people can change.
The official guidance has moved decisively in this direction — NIST now asks systems to permit long passwords, stop forcing rotation and complexity, and support pasting specifically so that password managers work. Explore more in our cybersecurity hub.
Frequently Asked Questions
Are password managers actually safe?
Yes, for the threats most people face. Your vault is encrypted on your device with a key derived from your master password, and the provider never receives that password or the key — so a breach at the provider yields data it cannot decrypt. The meaningful risks are a weak master password, malware on your device, or being phished for the master password. All three are manageable, and none is as likely as the password reuse a manager eliminates.
What happens if the password manager company gets hacked?
Attackers obtain encrypted vault data rather than readable passwords. The important consequence is that they can then try to guess your master password offline, with no rate limiting, which is why length matters so much. Some designs also protect metadata such as stored site addresses less thoroughly than the passwords themselves, which can enable targeted phishing. A long, unique master password keeps a provider breach from becoming your breach.
What if I forget my master password?
In most cases the vault is unrecoverable, and that is by design rather than poor service — the provider has no copy of your key to reset. This is why managers issue a recovery kit or emergency code at signup, and why writing the master password down and storing it physically is sensible advice rather than a security failure. Some services offer recovery via a device you have already authorised, which is worth enabling.
Is a browser's built-in password manager good enough?
It is much better than reusing passwords, and for many people it is a perfectly reasonable choice. Dedicated managers typically offer stronger cross-platform support, easier sharing, breach monitoring, and passkey storage across ecosystems. The gap between a browser manager and a dedicated one is small compared with the gap between either and no manager at all.
How often should I change my passwords?
Not on a schedule. NIST guidance states that verifiers should not require memorized secrets to be changed arbitrarily or periodically, because forced rotation produces predictable patterns like incrementing a year. NIST does require a forced change when there is evidence of compromise — so change a password when a service is breached or you have reason to think it has leaked, and otherwise leave a strong unique password alone.
Do passkeys make password managers obsolete?
Not for years. Passkey adoption is substantial — five billion were in use as of 2026 — but far from universal, so you will keep passwords on many sites for a long time. Most managers now store passkeys as well as passwords, which makes them the practical place to keep both while the transition happens.
Sources
- NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management — National Institute of Standards and Technology
- More than a Password: multi-factor authentication guidance — Cybersecurity and Infrastructure Security Agency (CISA)
- Next Level MFA: FIDO Authentication — CISA
- FIDO Alliance Reports Accelerating Global Passkey Adoption on World Passkey Day 2026 — FIDO Alliance
- Web Authentication: An API for accessing Public Key Credentials, Level 3 — W3C
- Credit Freezes and Fraud Alerts — Federal Trade Commission, Consumer Advice
