Why we never built passwords

Most auth platforms support passwordless login. It is worth being precise about what that sentence means.

It means the platform has passkeys, or magic links, or both, available as an option alongside the password system it already had. The password system is still there. The endpoints still exist. The hashing code still runs. The reset flow is still wired up. Somewhere there is a boolean, and somebody can set it back.

We never wrote any of it. It isn’t disabled or hidden behind a feature flag; it was never written. There is no password column in our database, no hashing library in our dependency tree, no reset endpoint in our router, and no code path that could create one. That sounds like a smaller claim than “passwordless”. In practice it is a much bigger one.

The toggle problem

Here is a sentence from Auth0’s own passkey documentation, describing a constraint rather than a preference:

Database connections with passkeys enabled must also still have passwords enabled.

On that platform you cannot turn passwords off. Passkeys sit alongside the password. So every account with a phishing-resistant passkey also has a password, and the attacker gets to choose which one to go after. They will not choose the passkey.

The same thing happens with any setting. Sooner or later someone changes it: a migration, a support engineer unblocking an angry customer, a new hire who doesn’t know why the flag was set, an acquisition that merges two user stores. Nobody can re-enable a code path that doesn’t exist.

What goes away when the password does

Quite a lot of work and risk goes with it:

• The credential database as a target. The recurring news story where a company discloses that N million hashed credentials were taken cannot happen to us. We don’t have that table.
• Credential reuse. Your users reuse passwords, across your services and everyone else’s. A breach at an unrelated company becomes your incident. If your users have no password with you, a leaked one from somewhere else gets an attacker nothing.
• Credential stuffing. Automated login attempts with lists bought elsewhere are most of the hostile traffic a login endpoint sees. Without a password field, those lists are useless against you.
• The phishing page. A convincing replica of your login screen harvests passwords. It cannot harvest a passkey: the browser binds the credential to your real origin and won’t offer it to the fake one.
• Reset tickets. Whoever answers your support email spends a share of every week on forgotten passwords. The FIDO Alliance’s 2025 consumer survey found 47% of people abandon a purchase when they have forgotten the password. That sample was US, UK, China, South Korea and Japan rather than European, so treat the number as a rough guide.

Where passkeys fall short

Passkeys don’t work everywhere yet. Support is good and improving, but there are still devices, browsers and situations where a user can’t use one: a borrowed laptop, a corporate machine with a locked-down authenticator, a phone that just went into the sea.

So passkeys are the default and email is the designed fallback: a one-time link or a six-digit code. We built it as part of the sign-in flow from the start. It is how people recover access and how they sign in without a passkey, and it is the same flow either way.

The obvious objection: if the fallback is email, the account is only as strong as the inbox. That is true, and it is true of password systems too — their reset flow also runs through email, so the inbox already governs the account there. The difference is that the password system has an inbox dependency and a stealable credential. We have only the first. There is more to say about that than fits in a paragraph, so we wrote a separate article about factor-counting.

Signup disappears

Removing passwords collapses registration into login. There is no “create an account” form distinct from “sign in”, because there is nothing to create: a first-time visitor enters their email, proves they control it, and they are in. Whether they had an account a moment ago is for us to sort out.

A signup form with an email field, a password field, a confirm-password field and a strength meter asks for four decisions and a rule before someone has seen your product. We removed it for security reasons. It turned out to help conversion too, which we did not plan and will happily take.

Why we didn’t make it a setting

Security controls get bypassed. Sooner or later there is an exception process, and an incident where somebody turned the control off for a good reason. The ones that hold are the ones there is no switch for.

We never added passwords, so there is nothing to switch back on. If you ask us to support them because a customer insists, we can’t. The software has no way to do it, and we think that is a stronger promise than any policy.