Many logins labelled "two-factor" are really two steps from the same factor category, and auditors, regulators and attackers all treat those very differently from genuine multi-factor authentication. Product teams and consumer services use 2FA, two-step verification (2SV) and MFA almost interchangeably, while NIST SP 800-63B-4, PCI DSS and the EU PSD2 strong customer authentication rules test something stricter: distinct factor categories that fail independently. This guide sets out what each term means, which common methods count as a separate factor, how they map to NIST authenticator assurance levels, and the configuration mistakes that turn MFA back into single-factor login. It is written for identity architects, IAM engineers and compliance leads who must write an authentication policy or defend one in an audit. For attack techniques and phishing resistance, follow the links to the dedicated guides; this page is about the terminology decision and what it means in practice.
Key takeaways
- Factors are categories, not steps: something you know, something you have and something you are. MFA means proof from at least two different categories; two prompts from one category are two-step, not two-factor.
- 2FA is a subset of MFA: exactly two distinct factors. Two-step verification is a user-experience description that may or may not meet that bar, depending on what the second step proves.
- Email codes and security questions rarely add a factor: NIST SP 800-63B-4 says email shall not be used for out-of-band authentication, and a security question is a second "something you know".
- Independence is the real test: PSD2 RTS Article 9 requires that a breach of one element does not compromise the others, and the PCI SSC MFA supplement warns that an OTP received and entered on the same device can nullify the second factor.
- Policy should name assurance, not labels: write requirements as NIST AAL2 or AAL3, or as allowed authenticator types, so a vendor's "2-Step Verification" toggle cannot be mistaken for compliance.
The short answer
MFA (multi-factor authentication) requires evidence from two or more different factor categories. 2FA (two-factor authentication) is MFA with exactly two factors. Two-step verification means the login has two stages; it is genuine 2FA only when the second stage proves a different category from the first. A password followed by a code from an authenticator app on a separate phone is 2FA and MFA. A password followed by a security question is two-step but single-factor. A passkey unlocked with a fingerprint is one step but two factors.
The confusion is partly official. CISA's MFA page lists 2FA, Two Step Authentication and 2-Step Verification as other names for MFA, and Google's help centre describes its 2-Step Verification as "or two-factor authentication". The NCSC uses MFA for organisational services and points individuals to 2-step verification for personal accounts. These are plain-language choices for public audiences. When you write an enterprise policy, a contract or an audit response, use the precise definitions below.
The three terms compared
| Term | What it requires | Who uses it | Typical example | Counts as MFA for an auditor? |
|---|---|---|---|---|
| Two-step verification (2SV) | Two sequential checks; categories not specified | Consumer services, product UIs, NCSC personal guidance | Password then SMS code; password then email link | Only if the second step is a distinct, independent factor |
| Two-factor authentication (2FA) | Exactly two different factor categories | Vendors, older policies, banking | Password plus hardware OTP token | Yes, if the factors are independent |
| Multi-factor authentication (MFA) | Two or more different factor categories | NIST, PCI DSS, CISA, most regulators | Passkey with biometric unlock; smart card plus PIN | Yes, if the factors are independent |
| Strong customer authentication (SCA) | Two or more of knowledge, possession and inherence, independent, producing an authentication code | EU and UK payments law | Banking app approval with device binding plus biometric | Yes, plus PSD2-specific dynamic linking rules |
Factor categories and what each must prove
- Something you know: a password or PIN. In NIST SP 800-63B-4 this is the password authenticator (s3.1.1). Knowledge-based answers do not strengthen it: the same document says verifiers shall not prompt subscribers to use knowledge-based authentication or security questions. See the Security Questions and KBA guide.
- Something you have: a physical authenticator the user controls: a look-up secret, an out-of-band device, an OTP device or a cryptographic authenticator (s3.1.2 to s3.1.7). The proof is possession of a specific device or secret, not access to an account.
- Something you are: a biometric. NIST treats biometrics as never an authenticator by itself; a biometric comparison is permitted only as part of multi-factor authentication with a physical authenticator, and a non-biometric alternative must be offered (s3.2.3).
PSD2 uses the same three ideas under the names knowledge, possession and inherence. Article 4(1) of Delegated Regulation (EU) 2018/389 requires authentication based on two or more elements categorised as knowledge, possession and inherence. Location, time of day and device reputation are useful risk signals, and the PCI SSC MFA supplement notes they can be added, but they are not factors: at least two of the three categories must always be used. See the Risk-Based and Adaptive Authentication Guide for how those signals step authentication up or down.
Which common methods count as a separate factor
The table assumes the first step is a password. "Separate factor" means a different category that does not depend on the password or on the same compromised channel.
| Second step | Factor category | Adds a separate factor? | Notes and source |
|---|---|---|---|
| Security question or memorable word | Know | No | Two knowledge items; prohibited as an authenticator prompt in SP 800-63B-4 |
| Second password or PIN on the same screen | Know | No | Two steps, one category |
| Email OTP or magic link | Arguably have, in practice know | No for NIST AAL2 | SP 800-63B-4 s3.1.3: email shall not be used for out-of-band authentication; email access is often protected only by a password. See the Magic Links and Email OTP Security Guide |
| SMS or voice code | Have (phone number) | Yes, restricted | PSTN out-of-band is a restricted authenticator (s3.1.3.3); alternatives must be offered. See the SIM Swap Fraud Guide |
| Authenticator app TOTP | Have | Yes | Single-factor OTP (s3.1.4); not phishing-resistant. See the Authenticator Apps and OTP Guide |
| Push approval in an app | Have | Yes | Out-of-band device; add number matching against fatigue attacks |
| Printed backup or recovery code | Have (look-up secret) | Yes, for recovery | Look-up secret (s3.1.2); govern as a fallback. See the MFA backup codes and recovery codes guide |
| Hardware security key or passkey | Have, often plus are or know | Yes, and phishing-resistant | Cryptographic authenticator (s3.1.6, s3.1.7) |
| "Remember this device" cookie | Have (weak) | Only as a session convenience | Possession of a cookie, which can be stolen with the session |
Some methods are two factors on their own. A passkey or a FIDO2 security key that requires a PIN or biometric to unlock is a multi-factor cryptographic authenticator in NIST terms (s3.1.7), so a single tap can satisfy MFA without any password. This is why "one step" and "single factor" are not the same thing either. The Passwordless vs Phishing-Resistant MFA guide covers that distinction in depth.
Mapping to NIST authenticator assurance levels
NIST SP 800-63B-4, which supersedes SP 800-63B, avoids the marketing labels altogether and defines assurance levels instead. Writing policy against these levels removes the 2FA versus 2SV argument.
| Level | Factor requirement | Other key requirements | Methods that qualify |
|---|---|---|---|
| AAL1 | Single-factor or multi-factor; verifiers should offer MFA | Reauthentication at least every 30 days (should) | Password alone; any single authenticator |
| AAL2 | Two distinct factors: a multi-factor authenticator, or a physical authenticator plus a password or biometric | At least one replay-resistant authenticator; verifier shall offer a phishing-resistant option | Password plus TOTP, push or SMS (restricted); passkey with unlock |
| AAL3 | Phishing-resistant cryptographic authenticator with a non-exportable key, multi-factor or single-factor plus password or biometric | Syncable authenticators shall not be used; reauthentication at least every 12 hours | Device-bound FIDO2 key or smart card with PIN |
Read AAL2 carefully: two single-factor authenticators satisfy it only when one is a physical authenticator. Password plus security question fails because neither is physical. Password plus email OTP fails because email is excluded from out-of-band authentication. For the full AAL detail, including timeouts and the federal phishing-resistance requirement, see the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
Regulatory definitions: PCI DSS and PSD2
PCI DSS
The PCI SSC information supplement Guidance for Multi-Factor Authentication (version 1.0, February 2017) states that MFA needs at least two of the three factor types and that factors should be independent, so access to one factor does not grant access to another. It gives a sharp example of a same-category trap: if access to a software token depends only on the ability to log in to the device, the process is effectively "something you know" used twice. It also warns that when the same device receives and submits a one-time password, the second factor is effectively nullified.
On feedback between steps, the 2017 supplement said no factor's success or failure should be revealed until all were presented, otherwise the process becomes multi-step rather than multi-factor. The current position is more permissive. PCI SSC FAQ 1584 (September 2024) says PCI DSS v4.x requires the success of all authentication factors before access is granted, but an implementation that indicates one factor succeeded before the next is presented still meets the MFA requirements. It recommends either withholding feedback until all factors are entered, or checking a session-unique factor, such as a one-time password or phishing-resistant factor, before a repeating factor such as a password. See the PCI DSS Requirement 8 Guide for where MFA applies in the cardholder data environment.
PSD2 strong customer authentication
Delegated Regulation (EU) 2018/389, the regulatory technical standards for strong customer authentication, has applied since 14 September 2019. Article 9(1) requires that the breach of one element does not compromise the reliability of the others. Article 9(2) and 9(3) address multi-purpose devices such as phones: where an element or the authentication code is used through one, the provider must mitigate the risk of that device being compromised, for example through separated secure execution environments and mechanisms to detect alteration. In other words, a banking app and an SMS code on the same phone need extra engineering before they count as independent. See the PSD2/PSD3 Strong Customer Authentication Guide.
Why same-category steps fail
Factor categories exist because each category falls to a different attack. Stacking two items from one category means one attack defeats both.
| Weak combination | Single attack that defeats it | Fix |
|---|---|---|
| Password plus security question | Credential phishing page that asks for both; data breach or social media research | Replace the question with a possession factor |
| Password plus email OTP, where email uses the same password | One credential stuffing hit unlocks both | Possession factor; enforce MFA on the mailbox itself |
| Password manager storing both the password and the TOTP seed | Compromise of the vault or the device it runs on | Keep the second factor on a separate authenticator for high-value accounts |
| App and SMS code on one unprotected phone | Malware on that phone | Device integrity checks, secure execution environment (PSD2 Art. 9) |
| Recovery via email reset that skips MFA | Mailbox takeover | Reset must not bypass MFA (ASVS 5.0 V6.4.3) |
Even genuine MFA based on codes or push is not phishing-resistant: a real-time proxy relays the password and the code, which ATT&CK tracks as T1111 Multi-Factor Authentication Interception, and push prompts can be spammed (T1621 Multi-Factor Authentication Request Generation). That is a separate question from whether two factors are present; the MFA Fatigue and Bypass Guide covers it.
Common misconfigurations
- "MFA enabled" with a knowledge fallback: users can choose security questions when the phone is unavailable, so the weakest path defines the real assurance. Audit every enrolled method, not just the default.
- Email as the universal second step: a consumer-style "we emailed you a code" flow adopted for workforce or administrator access, which fails NIST AAL2.
- Password reset that bypasses MFA: a reset link to email logs the user straight in. ASVS 5.0 V6.4.3 requires a reset process that does not bypass enabled MFA.
- Trusted-device skipping without limits: long-lived "remember me" cookies mean the second factor was last checked months ago; a stolen session cookie (T1539) inherits it. See the Top 10 MFA Mistakes.
- Exclusions that become the attack path: legacy protocols, service accounts and break-glass users exempted from MFA policy, then abused. Tampering with MFA configuration itself is tracked as T1556.006. See How to Find Accounts Excluded From MFA and Conditional Access.
- SMS as the only option: NIST requires alternatives to restricted PSTN authenticators, and ASVS 5.0 V6.6.1 says PSTN OTPs should be offered only when stronger methods are also available.
Where non-human identities fit
Factor categories describe people. A service account, API key or workload has no fingerprint and cannot carry a phone, so "MFA for service accounts" usually means something else: binding the credential to a workload identity, a certificate in hardware, a network origin or a short-lived federated token. The mistake is to exempt these accounts from MFA policy and then leave them on static passwords. Track them in the exception register and move them to workload identity or certificate-based authentication. See the Service Account Security Guide and the MFA Exception Register Template.
Decision guidance: what to write in policy
| Population | Minimum requirement to write | Avoid writing |
|---|---|---|
| Administrators and privileged roles | AAL3 or phishing-resistant MFA (FIDO2, smart card) | "2FA required" |
| Workforce remote and SaaS access | AAL2 with phishing-resistant option offered; no email or KBA second step | "Two-step verification enabled" |
| Payment card environment access | PCI DSS v4.x MFA: two factor types, all must succeed before access | Same-device OTP without independence controls |
| EU payment customers | PSD2 SCA with independent elements and multi-purpose device mitigations | Generic "2FA" |
| General consumers | Offer passkeys first; SMS or email only as transitional or recovery options | Calling email OTP "MFA" |
| Service accounts and workloads | Workload identity or certificate binding; documented exceptions | Blanket MFA exclusions |
Small organisations: turn on the identity provider's MFA with an authenticator app or passkeys for everyone, remove SMS and email options for administrators, and check the recovery flow. Large organisations: express requirements as AAL tiers by role, enforce them through authentication strength policies in the identity provider, and report coverage by method.
Worked scenario: an audit finding on "2FA"
A software company's policy says "2FA is required for all staff". The identity provider shows 98 per cent enrolment. A PCI assessor samples accounts and finds that 30 per cent of users have only email OTP as a second method, finance staff can fall back to security questions, and password reset emails log users in directly.
- Rewrite the requirement: replace "2FA" with "AAL2 or higher; allowed second factors are authenticator app, push with number matching and FIDO2; AAL3 for administrators".
- Inventory methods: export every enrolled method per user and flag accounts whose strongest method is email, SMS only or KBA.
- Pilot: enable the new authentication strength for IT and finance first, in report-only mode for two weeks, and watch failed sign-ins.
- Remove weak methods: disable security questions and email as sign-in factors, keep email only for verification, and require MFA re-registration through an already-authenticated session.
- Fix recovery: password reset now requires a registered possession factor or help desk identity verification.
- Roll back safely: keep a break-glass group outside the policy, monitored, so a misconfiguration does not lock everyone out.
Enrolment falls to 91 per cent in week one, then recovers as users register apps; the assessor accepts the evidence because the policy now names assurance rather than a label.
Detection and measurement
- Method mix: report strongest registered method per user, not just "MFA enrolled". See MFA Coverage Measurement.
- Weak-path usage: log sign-ins completed with SMS, email or fallback methods by privileged users.
- Method registration events: new methods added from unusual locations often precede takeover. See How to Detect MFA Method Registration Abuse.
- Bypass paths: resets and legacy protocol sign-ins that completed without a second factor.
| Metric | Target |
|---|---|
| Users whose strongest factor is a distinct possession or inherence factor | 100% of workforce |
| Privileged users on phishing-resistant authenticators | 100% |
| Accounts with KBA or email enabled as a sign-in factor | Zero for workforce |
| Password resets completed without a second factor | Zero |
| MFA exclusions without an owner and expiry | Zero |
Framework mapping
| Requirement | NIST SP 800-53 Rev 5 | OWASP ASVS 5.0 | Other |
|---|---|---|---|
| MFA for privileged accounts | IA-2(1) | V6.3.3 | CSF 2.0 PR.AA-03 |
| MFA for non-privileged accounts | IA-2(2) | V6.3.3 | PCI DSS v4.x Requirement 8 |
| Replay resistance | IA-2(8) | V6.3.3 | SP 800-63B-4 AAL2 |
| Restricted PSTN authenticators | IA-5 | V6.6.1 | SP 800-63B-4 s3.1.3.3 |
| Recovery does not bypass MFA | IA-5 | V6.4.3 | ATT&CK T1556.006 |
| Independence of factors | IA-2 | V6.3.3 | PSD2 RTS Art. 9 |
Practitioner checklist
- Policy names assurance levels or allowed authenticator types, never just "2FA" or "two-step".
- Every allowed second step is from a different category than the first and fails independently.
- Email OTP and security questions are removed as sign-in factors for workforce accounts.
- SMS and voice are allowed only alongside stronger options, and never for administrators.
- Password reset and account recovery require a registered factor and cannot bypass MFA.
- Trusted-device periods are short and reset on risk signals.
- All factors must succeed before access, with minimal feedback between steps.
- MFA exclusions, including service accounts, are recorded with an owner and expiry.
Standards and references
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- PCI SSC: Guidance for Multi-Factor Authentication Information Supplement
- PCI SSC: FAQ 1584 on indicating factor success before subsequent factors
- EUR-Lex: Commission Delegated Regulation (EU) 2018/389 on strong customer authentication
- CISA: Multi-Factor Authentication
- NCSC: Multi-factor authentication for online services
- Google Account Help: 2-Step Verification
Related NHI Mgmt Group resources: MFA Guide · Passwordless vs Phishing-Resistant MFA · NIST SP 800-63B-4 Authenticator Assurance Levels Guide · MFA Mandates Map · Authentication and MFA Policy Template