Why “how many factors?” is the wrong question

Every security questionnaire has the question. Do you support multi-factor authentication? It is a reasonable thing to ask and it has been a reasonable thing to ask for twenty years. It also assumes that every account has a password, and for a growing number of products that is no longer true.

Why everyone asks about MFA

The password is a terrible authenticator, and it is terrible in a way that gets worse at scale. People pick memorable ones. They reuse them everywhere. The reuse means a breach at any company becomes a credential list usable at every other company. Attackers automate that, and a convincing replica of your login page collects them directly from users who have no reliable way to tell it from the real thing.

None of this was fixable by making passwords better. Complexity rules produced Password1! and rotation policies produced Password2!. So the industry did the sensible available thing: it left the weak first factor in place and bolted a second one on top. That is what MFA is. It is a patch, and it was a good one.

Counting factors made sense because each extra factor made up for a credential everyone knew was bad. More factors meant more safety.

The reset link

Take a password-based system with a second factor and ask a specific question: what happens when the user forgets their password?

They click the link. An email arrives. They set a new password. They are in.

So anybody who controls that inbox can become that user. They don’t need to defeat the password. They use the flow that was built to rescue people from it, and the password never gets in their way.

In almost every password system in production today, the account is already only as strong as the inbox. You can’t fix that in the implementation. Any secret that people forget needs a recovery path, and the recovery path is email.

That leaves the password in an awkward spot. The inbox is what actually protects the account. What the password adds is a credential that can be stolen from your database, reused from someone else’s, guessed at scale or phished. It looks like an extra lock, and in practice it is one more thing to attack.

What passwordless email sign-in actually changes

If you send a one-time link or code to the inbox and make that the sign-in, the inbox dependency is still there. It is the same dependency, now out in the open instead of hidden in the recovery flow.

So be precise about the limit. Against an attacker who has compromised the inbox, passwordless email sign-in is roughly equivalent to password-plus-email-code. It is no better. We would rather tell you that here than have you work it out later.

The gain is everywhere else, and everywhere else is where most attacks happen. There is no credential database to breach, no password leaked from another site to reuse or stuff into your login form, and nothing for a phishing page to harvest, because the user has no standing secret to type into it.

Equal against one kind of attack, and several kinds of attack gone entirely. We think that is a good trade.

Passkeys

Email is the fallback. The default is a passkey, and with a passkey the second factor is built in rather than added on top.

When you sign in with a passkey, two things happen in one gesture. Your device proves it holds a private key that never leaves it (something you have). And the device only lets that key be used after it has checked your fingerprint, face or PIN (something you are, or something you know). You get two factors without retyping a code or opening an authenticator app.

It also resists phishing without relying on the user to spot the fake. The credential is bound to the origin it was created for, so the browser will not offer it to a replica of your login page on a lookalike domain. However careless the user is, there is nothing for them to hand over.

NIST says the same. NIST SP 800-63B-4, final as of July 2025, requires that Authentication Assurance Level 2 “SHALL use either a multi-factor authenticator or a combination of two separate authentication factors”, and it treats a passkey activated by biometric or PIN as a multi-factor cryptographic authenticator in its own right. Synced passkeys are permitted up to AAL2; device-bound ones reach AAL3.

So a passkey doesn’t need a second factor added to it. It already is a multi-factor authenticator.

So: do we support MFA?

This is the answer we give when a questionnaire asks, in full rather than as a tick in a box:

• Passkey sign-in is multi-factor by design — possession of your device plus the biometric or PIN that unlocks it. NIST SP 800-63B-4 treats that as a multi-factor cryptographic authenticator at AAL2.
• No factor we offer is a password. There is no password field, no password storage and no reset flow, because we never built them.

What we will not tell you is that an emailed code by itself is multi-factor authentication. It is one factor. When a user falls back to email, they are signing in with a single factor. The fallback exists because passkeys don’t work everywhere yet, and it is weaker than a passkey.

“How many factors?” is a question about how thoroughly the password has been compensated for. If there is no password, the number stops measuring anything useful. Better questions are what happens when your credential store is breached (for us, nothing, because we don’t have one) and whether a convincing fake of your login page can capture anything worth having.

You can answer those two concretely. You can’t do that with a count.