Why Passwordless Isn't About Convenience

The most instructive thing I have seen in a passwordless project was a diff that deleted nothing.

The team had done the work. Magic links on the consumer app, email OTP as the fallback, a tidy identifier-first login screen. Signup conversion went up four points. The launch post said "we've eliminated passwords," and by the definition most people use, they had — no password field, no password rules, no "must contain a special character."

A year later someone asked a budget question: what did we turn off? So they went looking, and the answer was almost nothing. The password_hash column was still there, populated, because legacy accounts still had one and nobody had scheduled its removal. The reset flow was still there. The rate limiter was still there — busier, actually, because the OTP endpoint got hammered in a way the login endpoint never had. The lockout logic was still there. The help desk still had a runbook for "I can't get the code." The bcrypt work-factor ticket was still in the backlog, quietly aging.

They had removed the typing. They had not removed the asset. And every operational cost they were paying was attached to the asset, not the typing.

That's the reframe this article is about. Convenience is the least interesting thing passwordless authentication offers, and framing it that way leads teams to ship the version that captures none of the value.

The chain nobody puts on the slide

Here is the argument in one line: a password is not a feature you remove, it is an asset class you hold, and everything expensive about passwords is an obligation attached to holding it.

Walk the chain:

• No shared secret → nothing to store in verifiable form
• Nothing stored → nothing to breach
• Nothing to breach → no corpus to feed back into credential stuffing
• Nothing the user knows and can retype → nothing to phish
• Nothing portable across relying parties → nothing to reuse

Convenience falls out at the end as a side effect. You stopped asking people to remember a thing because there is no longer a thing to remember. That's the correct causal order, and it matters, because a project justified on conversion will happily ship a mechanism that improves conversion while leaving the asset in place. That is exactly what happened above.

flowchart TD
    A["A credential the server must<br/>verify and the human must know"]
    A --> B["Store it (hashed)"]
    A --> C["Transmit it on every use"]
    A --> D["Human-memorable = low entropy"]
    A --> E["Portable across sites"]
    B --> B1["KDF choice, work factors,<br/>algorithm migration debt"]
    B --> B2["Breach blast radius,<br/>offline cracking window"]
    C --> C1["Log/APM/proxy leakage surface"]
    D --> D1["Strength meters, composition rules,<br/>breach-corpus checking"]
    D --> D2["Guessable — so: rate limits,<br/>lockout, and lockout's DoS problem"]
    E --> E1["Credential stuffing economics"]
    A --> F["Humans forget it"]
    F --> F1["Self-service reset flow"]
    F --> F2["Help-desk resets, identity<br/>verification for support"]

None of the boxes on the right are optional once the box on the left exists. That is the whole point. They aren't a maturity ladder you climb; they're the tax you pay for holding the asset, and no amount of engineering discipline retires any of them. The best-run password system in the world still has all of them.

What the asset actually costs

It's worth being concrete about the size of this, because decision-makers hear "we have a password system" as a component and it isn't a component. It's a distributed cost sitting in six budgets.

The help-desk number is the one that gets waved at in vendor decks, so treat it as an order of magnitude rather than a figure: password resets are routinely reported as somewhere between a fifth and a half of all IT service-desk tickets, at a fully loaded cost commonly quoted around $70 each. Both numbers are soft and both are vendor-adjacent. But you don't need the precise value — you need to notice that a 20,000-person organization with two resets per user per year is looking at a seven-figure annual line item for a control that provides no security benefit whatsoever. It is pure custody cost.

Then there's the attacker side, which is the part most cost models omit entirely. Credential stuffing is profitable because the password is portable. A corpus leaked from a hotel booking site is worth something against your bank because a meaningful fraction of humans reused. The industry-observed success rate for stuffing runs is somewhere in the low fractions of a percent — call it 0.1% to 2% depending on the list's freshness — and that is more than enough, because the marginal cost of an attempt is essentially zero and the list is amortized across thousands of targets.

That economic structure is a property of the asset class, not of your defenses. You cannot tune it away. You can only make attempts more expensive, which raises the attacker's cost linearly while their list keeps working everywhere else. Remove the shared secret and the arithmetic inverts: there is no corpus, nothing amortizes, and compromising an account requires per-target work — which is the difference between an industrialized business and a targeted operation.

The properties that make a credential expensive

Here's the part that experienced engineers sometimes get wrong, because "passwordless" is defined by what the login screen looks like rather than by what the system holds.

A session cookie is a shared secret. So is a refresh token. You are never going to reach zero shared secrets, and that's fine — because what makes passwords expensive isn't secrecy. It's a specific bundle of five properties:

1. Server-side verifiable storage — you hold something that can be tested offline against guesses.
2. Transmitted on every use — the actual secret crosses the wire and lands wherever your logs land.
3. Drawn from human memory — so the real entropy is far below the theoretical entropy.
4. Portable across relying parties — the same value works somewhere else.
5. Human-transferable under pressure — a person can be talked into handing it over.

Score the common mechanisms against those five and the picture stops being binary:

Read down the "magic link" and "OTP" columns. They genuinely retire property 4, and that is a real win — killing cross-site reuse kills credential stuffing against those accounts, full stop. They also shrink property 1 from a permanent liability to a minutes-long one, which meaningfully reduces breach blast radius.

But they keep properties 1, 2, and 5, and that means they keep most of the operational surface. You still store something verifiable (you should be hashing those OTPs, and most implementations do). You still need expiry, single-use enforcement, replay protection, per-account and per-IP rate limiting, attempt caps, lockout, and enumeration protection on the "send me a code" endpoint — which is now an unauthenticated endpoint that sends email or paid SMS on demand, so it is also an abuse and cost vector the password login never was.

And property 5 is where the honest assessment gets uncomfortable. An attacker-in-the-middle proxy relays a one-time code as fast as the user types it; a phone call from "your bank's fraud team" extracts one in under a minute. OTPs are more socially transferable than passwords, because the user has been trained that codes are the security step. The related failure in push-based factors is worked through in MFA Fatigue, and the mechanism is the same: the human is in the loop with a transferable value.

There's a second thing the emailed variants do, which is quieter and more structural: they move the trust anchor to a channel you don't control. If the credential is "can receive mail at this address," your account security is your user's mailbox security, and your recovery story is now someone else's recovery story. Sometimes that's a fine trade — a consumer app whose reset flow was already an emailed link has lost nothing by making it the front door, and has gained simplicity by having one path instead of two. Just don't record it as removing an asset class. It relocated one.

flowchart LR
    subgraph ML["Emailed OTP / magic link"]
        S["Server: stores hash<br/>of the code"] -->|"the value itself"| M["Mail provider"]
        M --> I["Mailbox"] --> U["User retypes it"]
        U -->|"and can be talked<br/>into forwarding it"| X["Anyone"]
    end

The test I'd apply, and it's a one-liner: at any moment during authentication, does a value that would authenticate the user exist in more than one place? For a password: yes, permanently. For an OTP: yes, for five minutes, in at least four places. For a WebAuthn assertion: no — what crosses the wire is a signature over a challenge that has already been spent, and the private key never left the authenticator. The mechanics of why that holds are covered in The Magic Behind Passkeys and, at the byte level, in Under the Hood of WebAuthn.

What does not disappear

If the piece stopped here it would be marketing, so let's be precise about the residue. Removing the shared secret removes exactly the obligations attached to the shared secret. Everything else stays, and some of it gets harder.

Enrolment. To register a credential you must already know who you're talking to, and the bootstrap is almost always an emailed link or a temporary password. Your phishing-resistant deployment's floor is set by that channel. An attacker who intercepts a first-login link enrols their own authenticator, and the result is harder to detect and harder to revoke than a stolen password would have been.

Device loss. Not a subset of recovery — an operational reality with a rate. Phones break weekly, in volume, and the "I have exactly one credential" case is the common case unless you designed against it.

Account recovery. Covered below, because it's the real counter-argument.

Session security. A stolen session cookie is a full compromise regardless of how strong the authentication was. Token binding, sensible lifetimes, revocation latency, step-up on sensitive operations — all unchanged, all still your problem. Strong front-door authentication has a way of making teams less careful here, not more.

The fallback tail. Legacy applications, service accounts, shared workstations, assisted channels. Those populations are not converting soon, and while any of them exist you keep the password infrastructure — which means you keep the whole cost table for a shrinking population. Why Passkeys Won't Eliminate Passwords Any Time Soon walks that territory in detail; the relevant conclusion here is that the savings arrive at decommissioning, not at launch, and the interval between them is measured in years.

Recovery is where the asset comes back

This is the strongest objection and it deserves the last substantive section.

If a user's only credential is bound to a device, and the device is gone, you need a path back. Whatever that path is becomes the account's true security level — min(credential, recovery) — and the paths teams reach for first are an emailed link or an SMS code. Which is to say: you removed the shared secret from the front door and reinstalled it at the side entrance, with worse ergonomics and less scrutiny.

A deployment with phishing-resistant login and an emailed-OTP recovery flow has not removed the asset class. It has made the asset rarer, which is worth something — the attack now requires targeting recovery specifically — but the honest description is "we reduced exposure," not "we don't have passwords."

Designing it out is possible, and it's mostly about making recovery not be a channel secret:

• Enrol two credentials, not one. The cheapest recovery is another credential. A second passkey on a second device at first login converts most device-loss events into a normal login. Adoption is the hard part; the design isn't.
• Use the platform's synchronization deliberately. Synced passkeys make device loss a non-event, at the cost of anchoring on the user's cloud account. That's a real trade, and it should be a decision rather than a default nobody examined.
• In workforce contexts, use the fact that you can identify people. Manager attestation, in-person verification, an existing verified device. Enterprises have identity-proofing options consumer products don't, which makes workforce recovery a genuinely solvable problem.
• Make the residual path slow, loud, and rate-limited. If recovery must go through a channel, it should take hours, notify every registered device, and be revocable during the window. Attacks that need patience and silence don't survive that.

The full treatment is in Passkey Account Recovery Is the Whole Problem. The point for a decision-maker is narrower: budget the recovery design before you budget the rollout, because a rollout with an unfinished recovery design produces a system that looks passwordless on the login screen and behaves like an email-secret system everywhere it matters.

A note on what "off" actually means

One structural detail worth naming, because it decides whether the asset ever leaves. For the password store to go away, "no password" has to be an expressible configuration state — not a UI that hides the field.

The platform I work on, ClavionX, is design-phase rather than battle-tested, and I mention it only as a worked example. Password login and WebAuthn are independent per-tenant flags there, with one invariant: at least one of them must remain enabled. A tenant can genuinely turn password authentication off; it just cannot turn off every way to sign in. That's small and load-bearing — "this tenant holds no password material" becomes a state the system can be in and report on, rather than a claim someone makes in a slide. Ask your own platform the same question: can it represent an account that has no password, and can it tell you how many there are?

The ledger to actually keep

Passwords are the only asset class where our industry has accepted permanent hardening in place of deletion. Nobody argues that the right answer to holding unnecessary customer PII is a better encryption scheme; the right answer is not holding it. Password storage got a twenty-year exemption from that reasoning, and the exemption was reasonable while there was no alternative.

So the metric isn't login conversion, and it isn't even the share of authentications that used a strong credential — that number goes up while the asset stays exactly where it is. The metric is custody:

What fraction of accounts hold no server-side verifiable secret at all, and what is the dated plan to retire the rest?

That question has a target, a trajectory, and an end state where code gets deleted, tickets stop arriving, and a class of breach stops being possible. Run it like a data-minimization program: inventory, migrate, verify, decommission, and only then count the savings.

Convenience will show up on its own. It always does — it's what removing an asset feels like from the outside.