Passwordless authentication

In short

Passwordless authentication is the set of methods that allow proving an identity with no secret that the person knows and the system stores. What replaces the password is possession of a device, a cryptographic key, or a biometric trait verified locally.

The goal is not convenience, even though it brings it. It is eliminating the class of attacks that depend on there being something that can be guessed, leaked, or asked for through deception.

The password fails because of what it is, not how it is used

Before replacing it, it helps to be clear on what is being replaced, because not every password problem gets solved by the same substitute.

• It gets reused — the same key repeats across services, and a leak in any one of them enables credential stuffing against all the rest.
• It gets handed over — an impersonation site asks for it and the person types it in. It is the mechanism behind phishing, and no complexity policy prevents it.
• It has to be stored — the system has to keep something that lets it validate the password, and that something is a permanent target.
• It costs to operate — password resets are a constant support burden and, at the same time, one of the preferred paths for taking over other people's accounts.

The password does not fail because of user carelessness. It fails because it is a shared secret, and a shared secret always has two places it can escape from.

Removing the secret is not the same as hiding it

Under the same label live two families of methods with different security properties. This is the section that makes the term worth it and that avoids buying one promise for another.

• [Passkeys](/glosario/passkeys) and [FIDO2](/glosario/fido2) credentials — there is no shared secret. The device signs a challenge with a private key that is never sent to the site, and the credential is bound to the domain, so an impersonation site cannot ask for it.
• On-device biometrics — the trait is compared locally and unlocks a key. It does not travel to the server. When it backs a FIDO credential, it belongs to the family above.
• Magic link — the system sends a one-time link to the email inbox. There is no password at login, and the secret has become access to the inbox.
• [OTP](/glosario/otp) as the only factor — there is also no password, and there is a transcribable code that can be requested through deception or intercepted depending on the channel.

The last two remove the password from the login screen and keep a secret in transit. They are better than a reused password and are not equivalent to a cryptographic credential.

A passwordless flow with password recovery still has a password

It is the category's most frequent implementation failure, and it is not visible on the login screen, which is where everyone looks.

A product can remove the password from login and keep it in the reset flow, in the support channel, or when registering a new device. The attacker does not argue with the front door: they use the service entrance. The effective security level of access is that of the weakest path that returns an account.

Removing the password then forces solving two things that used to stay hidden behind it:

• How access is recovered when the device is lost. Without a password, recovering access becomes a question of identity again rather than of credentials: you have to establish once more that whoever is asking is the account holder.
• How a new device is registered, which is the same problem under another name.

Both are identity verifications, not authentication factors. And the quality with which they are solved defines what the whole scheme is worth, because the digital identity sustaining the account is what lets you recognize the account holder when they no longer have anything to show.