What Is Two-Factor Authentication? 2FA Methods and Their Tradeoffs

Key takeaways

• Two-factor authentication requires evidence from two different factor categories.
• SMS and authenticator-app codes can block password-only attacks but remain vulnerable to phishing relays.
• FIDO authentication binds cryptographic proof to the service instead of exposing a transferable login code.
• Recovery, credential enrollment, and session protection remain part of the account's security.

Two-factor authentication, or 2FA, requires two different kinds of evidence to authenticate. A familiar example is a password combined with a code from an enrolled authenticator app.

The factors are commonly described as something you know, something you have, and something you are. A password and a security question are both knowledge checks. Asking for both does not make the flow two-factor authentication.

Imagine an attacker obtaining the password for a small business’s administrator account through a breach at another service. A second factor can prevent that password alone from granting access. What happens next depends on the method the business chose.

2FA Is a Specific Form of MFA

Multi-factor authentication, or MFA, requires more than one factor. Two-factor authentication uses two.

The factors do not have to appear as two separate screens. A cryptographic authenticator can require both possession of its credential and a local PIN or biometric verification.

Conversely, several visible steps can still rely on the same factor. NIST’s authentication guidance distinguishes factor categories from the way an interface presents them.

The question is what evidence the service actually verifies.

SMS Codes Add a Barrier With Important Limits

With SMS, the administrator receives a code at a registered phone number. The attacker with only the password cannot finish that login.

However, control of the phone number can be attacked through processes such as fraudulent SIM replacement. A fake login page can also request the code and relay it to the real service while it remains valid.

SMS can improve protection over a password alone, but it should not be described as phishing-resistant. The phone number and the mobile account become dependencies in the authentication design.

Authenticator Apps Remove the SMS Dependency

A time-based one-time password, or TOTP, is generated from a shared secret and the current time. The authenticator app can generate it without receiving a text message.

The TOTP specification describes this mechanism. Because the app and verifier share the secret, the service can check the submitted code against the permitted time window.

That avoids the SMS delivery path, but the code remains transferable. An attacker operating a live phishing page can ask for the current value and submit it immediately.

The enrollment QR code contains sensitive setup material. Someone who copies that secret may be able to generate matching codes later.

Push Approval Needs Context

A push system asks the administrator to approve a login on an enrolled device. Repeated unexpected prompts can pressure or confuse someone into approving an attacker’s attempt.

Number matching makes blind approval harder by requiring the user to connect the phone prompt with information from the login they initiated. Microsoft’s number-matching documentation illustrates this approach.

It does not make every push flow phishing-resistant. Users should reject unexpected requests and investigate through a known account or organizational support channel.

In the business example, unexplained prompts may mean the password has already been obtained.

Security Keys Change What the Attacker Can Relay

A FIDO security key can act as a second factor after a password. It produces cryptographic evidence tied to the intended service instead of displaying a code for the user to copy.

The service verifies the response with the registered public key. WebAuthn’s relying-party and origin checks prevent an unrelated site from simply requesting the real site’s credential. See the WebAuthn authentication model.

A suitable authenticator can also support passwordless login. Whether a particular flow provides multiple factors depends on its verification requirements, not merely whether it uses a security key.

Compare the Methods by Their Failure Modes

Method	Useful protection	Main limitation to consider
Password plus SMS	Blocks many attempts using only a stolen password	Number takeover and phishing relay
Password plus TOTP	Adds possession evidence without SMS delivery	Shared-secret exposure and phishing relay
Password plus push	Convenient approval on an enrolled device	Accidental approval and social engineering
Password plus FIDO key	Adds service-bound cryptographic authentication	Key availability and recovery planning

A method that blocks password reuse attacks may still fail against interactive phishing. That distinction is especially relevant to administrator accounts.

Recovery Is Another Way Into the Account

Losing a phone should not force the business to improvise an insecure reset.

Enroll an appropriate backup method and protect recovery codes as credentials. Factor replacement should require meaningful verification, and account owners should be notified about important changes. OWASP’s MFA guidance covers these lifecycle concerns.

A support process that removes 2FA after a weak identity check can undermine an otherwise strong login method.

Protect the Session After Sign-In

Once authentication succeeds, the application commonly issues a session credential. If that credential is stolen, an attacker may be able to use the session without repeating the original factors.

Sensitive actions such as changing recovery details or adding an administrator may therefore require fresh authentication. Access permissions should also limit what the authenticated account can do, consistent with zero trust principles.

For the business administrator, enabling 2FA is an important step. Choosing a suitable method, preparing recovery, and protecting the resulting session make that step effective over the account’s lifetime.

Count the independent evidence required to sign in, rather than the number of screens in the login flow.