Choosing where your credentials live

Practical guides · About 7 minutes

"Use a password manager" is good advice that stops exactly where the interesting questions start. Which one, storing what, protected by what, and recoverable how? This guide is about the trade-offs underneath the slogan — enough to make a decision you can defend, without pretending there's one right answer.

First, name the threat you're defending against

Storage debates go in circles because people are quietly arguing about different attackers. There are four worth separating, and each one is defeated by something different:

• Remote attacker with your password. Credential stuffing, a breach at another site, a guess. Defeated by unique passwords and a second factor.
• Someone with your unlocked device. A borrowed laptop, a phone left on a desk, a colleague at a shared machine. Defeated by lock timeouts and re-authentication, not by encryption.
• Someone with your device, locked. Theft, loss, resale. Defeated by full-disk encryption and a vault that stays locked when the device does.
• A breach at your storage provider. The vault vendor itself gets compromised. Defeated only by end-to-end encryption where the provider never holds your key.

Most people's realistic risk sits in the first two. The fourth gets the most argument online and is the least likely to affect you — but it's also the one with the worst blast radius if it happens, which is why it deserves a considered answer rather than a dismissal.

What "encrypted at rest" actually promises

This phrase appears on every vendor's security page and covers two very different architectures.

Provider-managed encryption means the data is encrypted on disk, and the provider holds the keys. It protects against someone stealing the physical disks or dumping the database. It does not protect against a compromise of the running service, a malicious insider, or a legal demand — in all of those cases the plaintext is reachable.

End-to-end (zero-knowledge) encryption means the key is derived from your master password on your device, and the provider stores only ciphertext they cannot read. A full breach of the provider yields encrypted blobs. The trade-off is exact and unavoidable: if you forget the master password, nobody can help you. Recovery has to be something you set up in advance, not something support can do.

The options, honestly

Browser-built-in vaults

The one that's already there and already holding some of your passwords, whether you decided that or not.

Good: zero friction, so it actually gets used. Syncs across your devices. Modern browsers tie it to your OS account and can gate access behind a device unlock. Free.

Less good: it lives inside the single most-attacked application on your machine. It's typically tied to one browser vendor, which makes moving painful. Sharing with another person ranges from awkward to impossible. And by default it often protects entries with nothing more than your logged-in OS session — meaning "someone with your unlocked device" gets everything.

Reasonable for: Tier 3 accounts where the realistic threat is password reuse, not a targeted attacker. See the tiering guide if that term is new.

Dedicated password managers

The default recommendation, and usually the correct one.

Good: designed for this single job. Sensible sharing models for teams. Cross-platform. Most reputable ones are end-to-end encrypted. They handle TOTP codes, secure notes, and structured metadata, which matters more than it sounds when you're tracking which identity signs into what.

Less good: a single point of failure by design. It's a high-value target precisely because it's popular. It costs money for team features. And the convenience of autofill is itself an attack surface worth understanding — see the note on autofill below.

What to look for: end-to-end encryption; support for a hardware key as the vault's own second factor; a real sharing model rather than "send an export"; and a documented, tested export path so you're never locked in.

Self-hosted vaults

Good: you control the data and the availability. No third-party breach to worry about. Often cheaper at team scale.

Less good: you have now taken on operating a security-critical service — patching, backups, uptime, and the fact that if it's down at 2am, you can't get into anything. A self-hosted vault that isn't patched promptly is strictly worse than a managed one. This is a real option, but only if you'll genuinely do the operational work; "I'll get to it" is how self-hosted vaults become the weakest link.

Paper

Genuinely appropriate in one narrow case: the small set of Tier 1 recovery material — master password hints, backup codes, break-glass credentials — stored somewhere physically secure. Paper is immune to every remote attack, which is exactly why it's the right medium for the things you need when everything digital has failed. It's a terrible medium for the forty passwords you use daily. Don't confuse the two uses.

Spreadsheets, notes apps, and chat

Not a storage option. Covered in the access-sharing guide, but briefly: these sync widely, persist in backups and message history, and have sharing settings that drift over time without anyone noticing.

A layered setup that works

You don't have to pick one. Matching storage to blast radius is both safer and less annoying:

The rule holding this together: the thing that unlocks a tier should never be stored inside that same tier. Your vault's own second factor cannot live in the vault. Your Tier 1 backup codes shouldn't sit next to the Tier 1 passwords.

Protecting the vault itself

Whatever you choose becomes your most valuable target, so it gets the strongest protection you have available:

• A long, unique master password you have never used anywhere else. Length beats complexity — a memorable passphrase of several unrelated words outperforms a short string of symbols, and you'll actually remember it.
• A hardware key as the vault's second factor, where supported. This is the single highest-value place to spend one.
• A short auto-lock timeout. A vault that stays unlocked all day is a vault protected by your screen lock and nothing else.
• Full-disk encryption on every device that syncs it. Non-negotiable on laptops and phones that leave the building.
• A tested recovery path — an emergency kit, a break-glass contact, or a printed recovery code, filed before you need it. Covered in the break-glass guide.

A word on autofill

Autofill is the feature that makes any of this bearable, and it carries one specific risk worth understanding: a malicious or compromised page can sometimes coax a vault into filling credentials into a field the user didn't intend.

The mitigations are simple and worth adopting. Prefer a manager that matches on the full origin and doesn't fill across subdomains loosely. Turn off fully automatic fill on page load in favour of an explicit action — one keystroke, and it makes the fill a decision rather than a reflex. And treat a failure to autofill as a signal, not an annoyance: if your manager doesn't recognise the site you think you're on, the most likely explanation is that you're not on it. That reflex catches phishing pages more reliably than reading URLs does, and it's covered further in the phishing guide.

Migrating without a bad afternoon

Moving between managers is a common, and commonly botched, operation. The exports involved are plaintext files containing every password you own.

1. Export from the old manager, straight to an encrypted disk. Never a shared folder, never a cloud drive that syncs.
2. Import to the new one and spot-check a sample across categories — TOTP seeds and custom fields are the most common casualties.
3. Confirm the new setup actually works for a week before dismantling the old one. Don't burn the bridge on day one.
4. Securely delete the export file, and empty the trash. This is the step people skip, leaving a plaintext copy of everything in a Downloads folder indefinitely.
5. Only then remove the old manager and revoke its access.

Don't rotate passwords during the migration. Do one thing at a time; if something breaks, you want to know which change caused it.