What makes authentication multi-factor?
Count factors, not screens
Alex enters a password, then answers a security question on the next screen. Cedar Inc. has asked twice, but both answers depend on something Alex 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.
Alex 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 Alex 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 Alex 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.