MFA vs 2FA: two factors is the minimum, not the definition

2FA (two-factor authentication) means a login that requires exactly two different factors. MFA (multi-factor authentication) means a login that requires two or more. Every 2FA is MFA; not every MFA is 2FA.

The words get mixed because most deployments use two factors, so the two terms describe the same screen in practice. The difference matters when you write a policy, answer a security questionnaire, or design a login that uses three factors.

What counts as a factor

A factor is a category of evidence, not a step in the flow:

• Something you know: a password, a PIN, an answer to a security question.
• Something you have: a phone, a hardware key, a passkey on a device.
• Something you are: a fingerprint, a face, a voice.

Two passwords are one factor used twice. A password plus a one-time code from an app is two factors, because the code proves possession of the device. A passkey that requires a fingerprint to unlock can be multi-factor inside a single authenticator: possession of the private key plus the biometric check.

Location, time of day and device reputation are risk signals. They can strengthen a decision, but they are not authentication factors.

Side by side

Why the distinction matters

Compliance language is exact. Frameworks often say "multi-factor authentication" and mean at least two distinct categories. A vendor that counts two passwords as two steps does not meet the requirement, even if the login screen has two fields.

Risk-based policies can add a third factor. For an administrator signing in from a new device, a system might require a password, a passkey and a hardware key. That is MFA with three factors, not 2FA.

Recovery flows are part of the policy. A login protected by MFA but recoverable with a single email link is only as strong as the mailbox. Auditors increasingly ask about recovery, not just the primary flow.

Common mistakes

• Calling SMS "MFA" and stopping there. SMS is a possession factor, so it is technically MFA when paired with a password, but it is the weakest one. NIST classifies SMS as a restricted authenticator.
• Counting two steps of the same factor. Two passwords, or a password and a security question, are not multi-factor.
• Treating "remember this device" as a factor. It is a convenience that skips the check, not evidence of identity.
• Forgetting service accounts. API keys and machine credentials need their own policy; MFA for humans does not cover them.

Choosing factors in practice

For most teams the useful order is:

1. Passkeys or hardware keys for administrators and high-risk users, because they resist phishing.
2. TOTP apps for everyone else as the default second factor.
3. SMS only as a fallback, with monitoring, for users who cannot install an app.

Then add step-up rules: demand a stronger factor when the user changes a password, adds an administrator, or signs in from a new country.

How Casdoor handles it

Casdoor supports multiple second factors per organization, including TOTP authenticator apps, SMS, email and RADIUS, and WebAuthn credentials as a primary or additional factor. Policies are set per organization, so you can require passkeys for administrators and allow TOTP for everyone else from the same deployment. See the MFA documentation.

Related reading: what MFA covers, passwordless authentication and what passkeys are.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.