What makes authentication multi-factor?
Count factors, not screens
Avery enters a password, then answers a security question on the next screen. Cedar Inc. has asked twice, but both answers depend on something Avery knows. Two screens have not produced two different kinds of evidence.
Multi-factor authentication (MFA) uses more than one factor type. A password followed by a code from an enrolled authenticator app can combine knowledge and possession. A passkey that requires a local PIN or biometric can combine factors in one interaction.
Avery may have an authenticator app registered and sign in without using it. Cedar Inc. cannot count that app as a second factor for this attempt.
Compare the evidence
| Journey | Verified evidence | MFA? |
|---|---|---|
| Email address and password | Knowledge of the password. The address is an identifier. | No. |
| Password and security question | Two knowledge checks. | No. |
| Password and enrolled TOTP app | Knowledge and control of the app's secret, with both checks accepted. | Yes, in this example. |
| Security key with touch only | Control of a private key and user presence. | No second factor is established by touch alone. |
| Passkey with required, verified local PIN or biometric | Control of the key and local user verification. | Yes, with the required authenticator and verification properties. |
A single phone can hold a passkey and perform a biometric check. The device count is one, but the sign-in can still use possession and local user verification. A password typed on a laptop and a security-question answer entered on a phone remain two knowledge checks.
Separate factor types can also be compromised together. If Avery stores both a password and an authenticator app's enrollment secret in the same unprotected backup, someone who gets that backup may be able to reproduce both checks.
Passwordless and phishing resistance
Passwordless means signing in without an account password. An email magic link can do that, but opening the link does not necessarily demonstrate two independent factors.
A password and authenticator-app code can provide MFA. If Avery types both into a fake site, someone may relay them to the real site while they are still valid. Phishing resistance addresses that problem by binding authentication to the intended service. A passkey with required user verification can be passwordless, multi-factor, and phishing-resistant.
Try an authentication decision
Choose a fictional sign-in and the evidence Cedar Inc. requires. Compare an accepted TOTP code with an expired one, or a security key used with touch only against a passkey used with local verification.
Simulation only. This browser exercise uses fixed fictional cases. It does not sign anyone in, issue credentials, or change a real authentication policy.
An expired code or denied approval fails the pending sign-in when that check is required. Accepting the earlier password does not erase the failed second check, even for an action that one method would satisfy, because the failure may mean that someone else knows the password.
Each of these journeys assumed Avery's methods were already set up. Enrollment, replacement, and recovery follows how a method is added in the first place, and what happens when one is lost.