Why Password Managers Were the Decade's Biggest Security Win

A few years ago a fraud engineer put a three-year chart on the screen in a review I was sitting in. Two lines. The top one was credential-stuffing attempts against the login endpoint, and it had gone up by something like a factor of forty — new botnets, cheaper residential proxies, a fresh combolist every few months. The bottom line was successful takeovers arising from those attempts. It was flat, and in the last year it had bent downward.

The room spent twenty minutes arguing over which team got to claim it. Fraud pointed at the bot-detection vendor deployed in year two. Security pointed at the MFA rollout. Platform pointed, less confidently, at some rate-limiting work. Everyone had a plausible story, nobody had a controlled experiment, and the credit was allocated the way credit usually is.

The explanation nobody offered — because nobody in the room had done it, and it produced no artifact in any system they operated — was that over those three years a meaningful slice of that product's users had started using a password manager. Not because of anything we shipped: because their browser nagged them, or their phone offered to generate one, or their employer made them. And for each of those users, every combolist in existence had become permanently, structurally useless against that account.

That work happened on other people's laptops. It never appeared in our telemetry. It is, I think, the largest single improvement in consumer account security of the 2010s, and it has almost no advocates, because it is boring and because nobody can point at a graph and say that one's mine.

The claim worth arguing is not that password managers make passwords stronger. Strength is close to irrelevant to the attack that was actually taking accounts. What a manager does is make each account's credential statistically independent of every other account's — and independence, not strength, is what destroys the unit economics of credential stuffing. That is a property of a population of accounts, not of any single password, which is precisely why no defender can observe it in their own metrics, and why the decade's biggest empirical win is also its least credited.

Everything else in this piece follows from taking that seriously, including the parts where it's uncomfortable. Managers moved a lot of risk without removing it, and the honest ledger matters as much as the win.

A note on scope, because this blog has covered adjacent ground. The argument that human memory is the wrong place to store a secret at all — and that managers, passkeys, and hardware keys are the same architectural move — belongs to Stop Asking Users to Remember Secrets. The math on why length beats character classes is in Longer Beats Complex, and the forty-year policy history is in The Password Policy Arms Race. This piece is about economics and outcomes: what the attacker's spreadsheet looked like, what changed in it, and what didn't.

The attack that pays for itself

To see why independence is the load-bearing property, you have to look at credential stuffing the way the person running it does: as a business with a cost line and a revenue line.

The cost line is dominated by things that don't scale with the strength of anybody's password: a one-time acquisition cost for a combolist — email:password pairs aggregated from other people's breaches, which for a several-year-old aggregation is somewhere between free and trivially cheap — plus a per-attempt cost that is mostly an IP address which won't be blocked (residential proxies, priced per gigabyte), sometimes a CAPTCHA solve, and whatever engineering keeps pace with the target's bot defences. Converting a working login into money is a separate cost, varies wildly by target, and is where the actual labour is.

The revenue line is one multiplication: the number of credential pairs tried, times the fraction that work, times the realisable value of an account that works.

That middle term — the hit rate — is the whole ballgame, and it is small. Publicly circulated figures for stuffing runs land in the low fractions of a percent, commonly characterised as somewhere around 0.1% to 2% depending on the list's freshness and targeting; treat that as an order of magnitude rather than a measurement. Google's Password Checkup telemetry around 2019 reported roughly 1.5% of observed logins using a credential known to appear in a breach corpus — a different quantity, same direction. The exact number doesn't matter. The structure does: a fraction-of-a-percent hit rate is wildly profitable when an attempt costs a fraction of a cent and the list amortises across thousands of unrelated targets.

Two consequences fall out of that structure, and both are underappreciated.

First, there is no per-account defence against this attack, because there is no per-account attack. Each account sees exactly one failed login. Every threshold you have configured — five failures then lock, ten then challenge — watches a per-account counter that never reaches two, which is why lockout does nothing here and is actively harmful elsewhere. The attack is invisible at the granularity your controls operate at and visible only in aggregate, which is why the detection industry around it is entirely about aggregate shape: velocity, fingerprint entropy, ASN distribution, timing.

Second, and more importantly: the attacker's hit rate is an average over your user population, and it is composed of two very different kinds of account. Accounts whose owner reused a password that appears somewhere in the corpus have a hit probability that is high — call it "the credential is either in the list or it isn't". Accounts whose owner used a unique, machine-generated string on your site have a hit probability that is not low. It is zero, in the same sense that a decryption key you never generated is not weakly guessable. The credential cannot be in a corpus derived from other sites, because it was never used on other sites.

That distinction — low versus structurally zero — is where the argument lives.

Strength is the wrong axis; independence is the right one

Here is the reframing that I think is genuinely underappreciated, including by people who deploy managers enthusiastically.

If your threat is offline cracking of a stolen hash, strength is the right axis and entropy buys you time; that analysis is real and done properly elsewhere on this blog.

If your threat is credential stuffing, strength does nothing whatsoever, because nobody is searching a keyspace — the attacker is doing a lookup. A twenty-four-character diceware passphrase reused on a hobby forum breached in 2016 is, against stuffing, exactly as strong as hunter2. Both are one row in a file. Conversely a weak but unique password — blue-couch-4, used on precisely one site — is unbreakable by stuffing. It isn't in the list, and it can't be.

So the security property that matters against the dominant account-takeover attack of the last decade is not a scalar attached to a password. It is a relation between passwords: whether knowing the credential for account A tells you anything about the credential for account B.

Under reuse, that relation is near-total. One human with one memorised password and forty accounts has one credential replicated forty times — a rank-one structure in which the worst-operated site in the set compromises all forty. That is the actual mechanism by which a defunct forum's 2014 SHA-1 dump takes over someone's payroll account in 2026, and it is not a failure of the payroll site's password policy. No policy that site can write governs a variable living in a person's head and shared with a forum the site has never heard of.

Under a manager, the relation is severed. Forty accounts, forty independent draws from a uniform generator, zero mutual information. And note the important asymmetry: you get essentially the entire benefit from uniqueness alone. The extra entropy the generator gives you is nice, and it does buy real protection against offline cracking of a specific site's hashes — but the thing that kills the industrial attack is the independence, not the bits. This is why "use a manager" and "use longer passwords" are not the same advice even though they arrive in the same sentence. One of them changes a per-password quantity. The other changes the correlation structure of the whole estate.

flowchart LR
    subgraph reuse["Reuse: one credential, forty doors"]
        H1(("user")) --> R1["forum<br/><i>breached 2014</i>"]
        H1 --> R2["retailer"]
        H1 --> R3["bank"]
        H1 --> R4["payroll"]
    end
    subgraph mgr["Manager: forty independent credentials"]
        H2(("user")) --> V["vault"]
        V --> M1["forum<br/><i>breached 2014</i>"]
        V --> M2["retailer"]
        V --> M3["bank"]
        V --> M4["payroll"]
    end
    style R1 fill:#fdd,stroke:#c66
    style M1 fill:#fdd,stroke:#c66
    style R2 fill:#fdd,stroke:#c66
    style R3 fill:#fdd,stroke:#c66
    style R4 fill:#fdd,stroke:#c66

Both sides look nearly the same, and that's the point: the topology of access is identical. What differs is whether compromise propagates along the edges. On the left, one red node makes every node red; on the right, one red node stays one red node. The vault is a new single point of failure — it gets its own section below — but it is one the user chose and can defend once, rather than an emergent one distributed across forty operators of varying competence, none of whom the user has ever evaluated.

Why the win belongs to the population, not to you

Now push the economics one step further, because there's a corollary here that I've never seen stated plainly and it explains the "underrated" part of the title.

Adoption doesn't reduce the attacker's cost per attempt at all — proxies cost what they cost. It dilutes the numerator, converting some fraction of the account population from "possibly in the corpus" to "definitely not in the corpus." As adoption rises the aggregate hit rate for a given list falls, and every list ever compiled depreciates faster.

This is the same shape as herd immunity, with the same two properties that make it politically invisible. The private benefit is complete and immediate: if you use a manager, your accounts are done with stuffing regardless of what anyone else does. The public benefit — the economics actually breaking — accrues to nobody in particular, because the attack stops being worth running only when enough of the population has moved that expected revenue per list drops below the cost of running it. That threshold is crossed by hundreds of millions of uncoordinated people, and the benefit lands on non-adopters as much as adopters; the attacker who gives up on a target doesn't check who converted them.

There's an ugly wrinkle too. Adoption isn't randomly distributed — it tracks technical sophistication, income, employer security programmes, and owning a recent phone that nags you. So adoption drains the stuffable pool in roughly descending order of value to the attacker: the accounts with money, corporate access, or resale value leave first, and the pool degrades in quality faster than in size. Good news for the aggregate economics, and it means the residual stuffable population is enriched for exactly the people least able to defend themselves. The win is real and it is regressive.

Which brings us to the measurement problem, and I want to be precise about it because it's the reason for the article.

As a defender, you structurally cannot observe this in your own metrics. Your stuffing attempt volume is set by the attacker's list size and target selection, not by your users' hygiene — it can rise while your exposure falls, which is exactly what that opening chart was showing. Your success count falls, but over the same period you also shipped MFA, bot detection, breach-corpus checks at set-time and anomaly scoring, all of which have advocates in the room and none of which can be isolated. Adoption itself is not a field you have; you can infer it weakly at best (set-time password lengths develop a spike at whatever the popular generators default to) and you cannot attribute against it. And the quantity you actually want is the counterfactual — how many takeovers didn't happen — which produces no artifact at all. That's the perennial condition of security work, unusually acute here because the control wasn't deployed by anyone with a budget line.

There's one more trap, and it's the one that makes practitioners actively misread the trend. As adoption rises, your remaining takeovers concentrate in the non-adopting population — older accounts, less technical users, people who reuse. So the profile of a successful ATO gets worse over time: more of them involve credentials from ancient breaches, more of them involve users who ignore every prompt you send. Read naively, your incident reviews will suggest the problem is getting harder and your users are getting worse, at the exact moment total harm is falling. The population is improving and your sample is adversely selected. If you review incidents without a denominator, you will conclude the opposite of the truth.

The ledger: what managers moved rather than removed

Now the honest half. A control that kills one attack class by relocating value is not the same as a control that eliminates risk, and password managers relocated a lot of value. Here's what's on the other side of the ledger, roughly in order of how much I think each one actually matters.

One vault is a concentrated asset, and concentration is the recurring pattern

The user went from forty correlated low-value secrets to one uncorrelated high-value secret. That's the same trade federation made when five hundred applications stopped holding credentials and one identity provider started — including the downside, since every generation of authentication simplifies the edges by concentrating value in the middle, and the value of compromising the middle rises to match.

For an individual it's still usually correct: one asset you can defend deliberately beats forty you can't. For a vendor it means operating one of the highest-value targets on the internet, against the class of adversary willing to spend real money and time on you.

The master password, and the KDF parameter problem nobody budgets for

Underneath most consumer managers is a zero-knowledge design: the vault is encrypted client-side with a key derived from the master password, and the server holds ciphertext it cannot read. That's the right architecture and it's why "the vendor got breached" isn't automatically "every password is compromised."

But it means the offline resistance of everything you own reduces to two parameters: the entropy of one human-chosen secret, and the cost of the key derivation function applied to it. If an attacker obtains a copy of your encrypted vault, they get unlimited, offline, undetectable, un-rate-limitable attempts at that pair, forever. The vault ciphertext is a depreciating asset in exactly the sense a stolen password hash is: whatever work factor protected it in 2015 is worth substantially less against 2026 hardware, and the attacker can wait.

The architectural lesson — and this is the part that generalises well beyond password managers — showed up publicly in the LastPass incidents of 2022, in which backups of customer vaults were exfiltrated. The widely reported detail worth internalising is not the intrusion path; it's that PBKDF2 iteration counts varied across accounts by when the account was created. Defaults had been raised over the years, but raising a default does not re-derive existing keys, and a substantial set of long-standing accounts were reported to be sitting at iteration counts chosen for a much older threat model. Some were far below even the vendor's own then-current default.

That is a completely ordinary engineering failure and it will happen to you. KDF parameters are not configuration; they are a migration problem, needing everything a migration needs: a self-describing record format, an upgrade-on-next-successful-unlock path, a campaign for accounts that never come back, and a report showing the distribution rather than the default. The mechanics are those of migrating password hashes without resetting users, and it gets skipped for the same reason — the work is invisible while it's working, and the stale population grows every quarter you don't do it.

Ask this about any system you own that derives a key from a user secret: what is the distribution of work factors across live records, and what is the oldest one? If the answer is a single number, you're quoting the default, not the data.

Encryption granularity, and what the ciphertext doesn't cover

The other lesson from that same incident is about record structure. In the vault format as it stood, passwords and some fields were encrypted, but other fields — notably the site URLs — were not. From the vendor's perspective this is a reasonable-looking optimisation: matching an entry to the page you're on wants a cleartext index, and the secret is the password.

From an attacker's perspective, a list of every site a person holds an account with is a targeting document. It tells you who banks where, who has a crypto exchange account, who works at which company, and which of the stolen vaults are worth spending cracking time on. It converts an undifferentiated pile of ciphertext into a ranked queue.

The generalisable point: in any envelope-encrypted record, the fields left outside the envelope define an attacker's selection function. Teams reason about encrypted-versus-not per field, correctly in isolation, and never ask what the cleartext fields jointly reveal. Metadata isn't a lesser category of the same data; it's a different asset with a different use, and it's the one that decides where effort goes. That applies to your audit logs, your event streams, and every "we encrypt the sensitive column" review you'll sit in this year.

Autofill, and the origin question the web never actually answered

Here's the piece I think is genuinely under-discussed among people who build authentication.

To autofill, a manager must answer: is the credential stored for site X appropriate to offer on the page currently loaded? That is an origin-equality question, and the web platform has no canonical answer to it. The scheme-host-port tuple is too strict — users store example.com and log in at login.example.com, or at example.co.uk — and eTLD+1 is the pragmatic substitute, which means the matching logic depends on the Public Suffix List: a community-maintained flat file that determines where the boundary of administrative control sits for every suffix on the internet. A large fraction of browser security boundaries lean on that file. Most engineers who rely on it daily have never read it, and it is a text file with a pull request queue.

Around that core question sits a decade of accumulated hazards, mostly found by researchers rather than in production: credentials offered inside cross-origin iframes; script-injected forms harvesting what gets filled; invisible off-screen fields collecting the username alongside the field you meant; autofill triggered by synthesised events; sites where one subdomain hosts user content and another hosts the login. Managers have tightened all of it — user interaction required before filling, no cross-origin frames by default, top-level origin only — and each tightening broke somebody's legitimate flow, which is the permanent tension of the category.

And it all runs in a browser extension with content-script access to every page you visit. That is, by construction, one of the most privileged pieces of software on the machine. Extensions have had vulnerabilities; extension stores have had malicious clones of popular managers; and the whole assembly is exposed to whatever the browser's own extension security model turns out to be worth this year. The manager didn't create the browser attack surface, but it planted an extremely high-value asset in the middle of it.

Phishing resistance is advisory, and that word is doing enormous work

Managers do provide real phishing resistance, and it's the underrated feature: on a lookalike domain, the entry simply doesn't appear. The credential isn't offered because the origin doesn't match. Users who have internalised "if it doesn't autofill, something is wrong" have a genuine, protocol-level signal where before they had only their own reading of a URL bar — and humans are famously bad at that.

But it is a signal, not an enforcement. The user can search the vault, copy the password, and paste it into the phishing page — every manager offers that affordance because it must, since there are too many broken login forms in the world for a fill-only manager to be usable. So the origin check fails open, and it does so precisely when the user has already decided they need to log in and something isn't working, which is the emotional state phishing exists to produce.

This is the sharpest way I know to state the difference between a fifth-generation control and a sixth-generation one. WebAuthn's origin binding is mandatory: the signature covers the origin as the browser computed it, the user has no override, and there is no copy-paste path. A manager's origin check is advisory: correct by default, overridable by a determined user under pressure. Same idea, different modality, and the difference between advisory and mandatory is the entire security gap between the two generations. It is worth being clear-eyed about this when someone claims a manager makes users phishing-proof. It makes them phishing-resistant, which is a real and valuable thing and is not the same word.

The attacker moved to the endpoint, which is a win you should count as one

Once stuffing stops paying against an account and the vault won't fill on a fake domain, the cheapest remaining path to a consumer's accounts is the device: infostealer malware that grabs browser-stored credentials, vault databases, session cookies, and tokens straight out of a compromised machine. The centre of gravity in commodity account takeover has visibly shifted in that direction, and stolen session cookies in particular bypass the entire authentication stack — including MFA and passkeys — because a session artifact is a bearer token and always has been.

Score that honestly in both directions. It is a real limitation: the manager does not defend a compromised endpoint, and on one it arguably concentrates the loss. It is also the intended outcome of a working control. Stuffing costs a fraction of a cent and needs no access to anything the victim owns; endpoint compromise requires getting code onto a specific person's machine. Forcing an economically rational adversary from the first to the second is what raising costs looks like, and the new attack having a scary name doesn't undo the several orders of magnitude between them.

Recovery, as always

Zero-knowledge means the vendor cannot reset your master password, which means losing it loses everything, which means every vendor has built some recovery path: printed one-time recovery keys, device-bound biometric unlock that stores a wrapped key locally, recovery through another enrolled device, enterprise escrow. Each is a second door to the vault, and the security of the vault is the security of the weakest door.

This is the invariant that shows up in every generation of authentication and never gets designed for up front — recovery is the hardest problem in identity, and it is the specific place where an architecture with beautiful cryptographic properties acquires an operational bypass. If you evaluate a vault-shaped product, evaluate its recovery path first. It is the actual security level of the product.

The enterprise gaps, which are mostly not technical

Consumer adoption of managers was driven by browsers and phones. Enterprise adoption has been slower and more partial, and the gaps have a distinct shape.

The shadow credential estate. Employees hold corporate credentials in personal vaults. That isn't misconduct; it's what happens when the sanctioned tool is annoying and the personal one is already open in the browser. Some non-zero portion of your organisation's credentials therefore lives in storage you don't operate, can't inventory, and can't revoke — and departure doesn't change it. Offboarding disables the accounts in your directory; it does nothing to the vendor-portal credential that only one person ever had and that still works.

Shared credentials, which the category handles badly by design. Every organisation has accounts multiple humans use: the vendor portal, the social account, the legacy admin console with one login. Team vaults solve the storage problem and cannot solve the accountability problem — the credential is still shared, the audit trail on the far side names an account rather than a person, and rotation on departure is a manual campaign that gets skipped. A vault makes shared credentials manageable, which is routinely mistaken for making them acceptable.

Service accounts, which are a different problem in similar clothes. A password manager is built around a human unlocking a vault interactively; machine-to-machine credentials need programmatic retrieval, short lifetimes, automated rotation, and workload-identity-based access. Teams put service-account passwords in the human vault because it's there, then discover the audit trail, the rotation story, and the availability model are all wrong for the use case. Identity Isn't Your Secrets Manager works through why these are separate systems.

The correct enterprise move is usually to delete the credential, not to store it better. Every application you bring under SSO removes an entry from every vault in the company, personal ones included, and removes it permanently rather than protecting it. Federation coverage is the metric that actually shrinks the credential estate; vault deployment is the mitigation for whatever federation can't reach. Reversing that order — deploying a vault and calling the credential problem solved — is a common and expensive mistake, because a well-organised vault full of passwords is still a vault full of passwords.

The manager is in your threat model whether you deployed it or not

Here's the security-engineering consequence I'd most like people building login flows to absorb.

For a meaningful share of your users, a password manager is now a mandatory component of the authentication path. It generates the credential, decides whether to present it on your page, stores it, syncs it across their devices, and is the reason they can have a unique credential for you at all. You didn't choose it, you have no contract with it, you can't version it, and you cannot see it. It is nonetheless a load-bearing element of your system's security, and its behaviour on your pages is determined largely by markup you control.

Which means the manager belongs in your threat model as a real component, with two obligations that follow.

The first is don't break it, which is more consequential than it sounds. Every control that fights a manager pushes a user back toward a memorised, reused password — back into the correlated regime where a stranger's breach compromises your account. Blocking paste in a password field is the canonical own-goal: introduced to frustrate automated attacks, it frustrates nothing but the most effective defence your users have. Length caps below 64 characters, banned character sets, split password inputs, dynamically generated field names, and login forms that don't mark themselves up as login forms all do the same thing. These are not usability annoyances; they are controls that increase your exposure to credential stuffing, and they should carry a severity.

The second is cooperate deliberately. There is more surface for this than most teams know about — markup conventions, well-known endpoints, app-to-web association — and almost none of it appears on a standard launch checklist. The last section of this piece is that checklist.

Where managers sit in the arc, and what passkeys inherit

The reason to get the history right is that it tells you what happens next.

Per-site unique credentials were correct advice for about twenty-five years before they were possible advice. "Use a different password for every site," said to an unaided human with forty accounts, is a request the hardware doesn't support. The industry spent two decades issuing composition rules and rotation mandates instead partly out of inertia and partly because those were the only levers that fit inside a model where the user is the storage. Managers didn't win that argument; they removed the constraint. Once the storage exists the advice becomes executable, and the population shifts — slowly, unevenly, permanently.

And then notice what happened architecturally. A synced passkey lives in a credential store that syncs across a user's devices, is unlocked by a device authenticator, has an account-recovery path run by a platform vendor, and decides which credential to offer based on an origin match. That is a password manager. Frequently it is literally the same product: the browser's or the phone's or the third party's, with a new payload type. The vault did not go away. It changed what it stores — from a shared secret that can be replayed, phished, and cracked offline to a private key that cannot.

That change retires every ledger item that was a property of the secret: nothing to phish, nothing for a server breach to leak, no offline-crackable verifier at the relying party, and an origin check promoted from advisory to mandatory. It retires none of the items that were properties of the vault: concentration of value, the strength of whatever unlocks it, recovery as the weakest door, sync as a dependency on a vendor relationship you can't inspect, and the browser as the execution environment. Sort that ledger and roughly half the entries carry forward unchanged. If you understood why vault architecture mattered for passwords, you already understand the security model of synced passkeys — and you should ask their vendors the same questions: what unlocks it, what the recovery paths are, what sits outside the encryption envelope, what happens when the user changes ecosystems. (Cross-vendor portability is in progress; the FIDO Alliance has published draft credential exchange formats for moving credentials between managers, but it's early, and portability is a claim to verify rather than assume.)

The honest summary of the decade, then: managers were the bridge. They made the correct behaviour operationally possible for a large population, they broke the correlation that made an entire criminal industry viable, and they built the muscle memory and the software category that passkeys are now deployed through. They did not fix authentication. They fixed the specific thing that was, empirically, taking most of the accounts — and the fact that this is hard to prove from inside any one organisation is why it gets left off the list of things that worked.

What to do Monday

Not a summary. Five things, in the order I'd do them.

1. Audit your login and registration forms for manager hostility, and file the findings as security defects. Allow paste everywhere, including confirm-password and OTP fields. Accept at least 64 characters and every printable Unicode character; if you truncate, know where and why (bcrypt's 72-byte limit is a real one). Use the standard autocomplete tokens — username, current-password on login, and new-password on registration and change flows, which is the signal that makes managers offer to generate rather than merely fill. Keep field names stable across deploys, don't split the password across inputs, mark up the username field properly if you use a two-page flow, and avoid JavaScript-managed inputs that swallow programmatic fill. Half a day of work, and the highest-leverage security change most consumer login pages could ship this quarter.

2. Publish the well-known endpoints that let managers do their job. /.well-known/change-password — a W3C specification, honoured by major browsers and managers — should redirect to your change-password page, so that when a manager detects a compromised credential it can deep-link the user straight into fixing it rather than into your homepage. If you have mobile apps, publish apple-app-site-association and Digital Asset Links so credentials associate correctly between app and web instead of ending up as two entries. If you run several origins that are genuinely one service, look at WebAuthn's related-origin mechanism rather than making users guess. Each of these is a static file, and each one removes friction from the path that leads users toward unique credentials.

3. Measure the thing you can measure: reuse in your own population. You can't measure manager adoption, but you can measure the property that managers exist to eliminate. Check credentials against a breach corpus at set-time and at login, using the k-anonymity range query so you never transmit the password, or run it against a corpus offline. The percentage of your active accounts using a credential known to be breached is a defensible proxy for your exposure to stuffing, it moves when things get better, and it's the only number in this article you can put on a dashboard honestly. Track it as a rate over the active population, not as a count, so that adverse selection doesn't fool you.

4. Separate the human vault from the machine secret store, and make federation the primary strategy for both. Deploy a team vault for shared credentials that genuinely can't be federated, and treat every entry in it as a known deficiency with an owner and an expiry rather than a solved problem. Put machine credentials in a system built for programmatic retrieval and rotation. Then measure SSO coverage as a percentage of applications, because that is the number that deletes credentials rather than relocating them — every app you federate empties an entry out of vaults you will never see, including the personal ones holding your credentials right now.

5. Write the vault into your threat model explicitly. If you deploy a manager it is a tier-zero dependency: its compromise is an organisation-wide credential compromise and its unavailability is an organisation-wide outage. Ask the vendor the questions this article implies — what unlocks the vault, what the distribution of KDF parameters across your tenant looks like rather than the default for new accounts, which fields sit outside the encryption envelope, what every recovery and escrow path is, and what an administrator with escrow rights can do without the user noticing. If you don't deploy one, write down that your users use one anyway, that you don't know which, and that your login markup is the only interface you have to it. That second document is shorter, more uncomfortable, and the one more organisations should have.

The meta-lesson generalises past passwords. The controls with the best returns are frequently the ones whose benefit is counterfactual, diffuse, and accrues to a population rather than to a system you operate. They win no arguments in review meetings, because the win shows up as an absence in somebody else's metrics. Managers spent a decade quietly destroying the economics of the most profitable account-takeover attack in history, and the people who did it were browser teams, OS vendors, and a few hundred million individuals clicking "yes, save this." Nobody got a slide. That is usually what a real win looks like.