What Is MFA? Factors, SMS Risk, and Phishing-Resistant Auth

Authentication factors fall into three categories. Knowledge factors are something you know — a password, PIN, or passphrase — and are the cheapest to deploy but also the easiest to steal, guess, or reuse across sites. Possession factors are something you have — a phone running an authenticator app, a one-time-code generator, or a hardware security key — and prove the person holds a specific device. Inherence factors are something you are — a fingerprint, face, or other biometric — read by a sensor and matched against a stored template. NIST's Digital Identity Guidelines build MFA on exactly these three classes.

A control only earns the term multi-factor when it draws on at least two of these categories. Two knowledge factors — a password plus a memorable date, for example — remain a single class and can be harvested in one phishing session, so they do not qualify. NIST layers assurance on top of this rule through Authenticator Assurance Levels: AAL1 permits a single factor, AAL2 requires proof of possession of two distinct factors and that a phishing-resistant option be offered, and AAL3 demands a hardware-based, phishing-resistant authenticator whose cryptographic keys cannot be exported. The higher the assurance level, the narrower the set of methods that satisfy it.

Two-factor authentication (2FA) is a subset of multi-factor authentication, not a competing idea. 2FA means exactly two factors; MFA is the umbrella term for two or more. Every 2FA setup is therefore MFA, but an MFA flow can combine three factors — a password, a security key, and a biometric — for higher-assurance access to sensitive systems. In everyday product marketing the two terms are used interchangeably, and for most business logins the practical target is genuine two-factor coverage drawn from two different categories.

The label matters less than whether the two factors come from different categories and how resistant each one is to interception. A vendor can honestly claim MFA while shipping a password-plus-SMS-code flow that an attacker can defeat with a real-time phishing proxy. That is the core misconception worth retiring: turning on MFA is not the same as becoming unphishable. What determines real protection is the strength of the weakest enrolled factor, which is why the rest of any serious evaluation focuses on how each method actually fails rather than on whether the MFA box is checked.

A one-time code sent by text message is real MFA — it adds a possession factor — but it is the most exposed option and is now formally discouraged. NIST SP 800-63-4, the revision of the Digital Identity Guidelines published July 31, 2025, classifies out-of-band codes sent over the public telephone network, including SMS and voice calls, as a restricted authenticator: permitted only with extra risk mitigations, such as checking for recent SIM swaps, and only when the service also offers subscribers an alternative method.

Three attack paths explain the caution. In a SIM-swap, an attacker socially engineers a carrier into porting the victim's number to a new device and receives the codes directly. SS7 signaling-network weaknesses can let codes be intercepted in transit. And an adversary-in-the-middle phishing page can relay a texted code to the real site the instant the victim types it, because the code is just a short string with no tie to the domain requesting it. None of these require the victim's password to be strong; they route around password quality entirely.

Authenticator apps improve on SMS by generating codes on the device itself, with no carrier in the path. The common scheme is TOTP (time-based one-time password), defined in IETF RFC 6238, which derives a rotating numeric code — usually every 30 seconds — from a shared secret and the current time. That removes SIM-swap and SS7 exposure, but it does not remove phishing: a victim can still be tricked into typing a valid code into an attacker-controlled page that relays it to the real service within the 30-second validity window.

Push-approval apps replace typing a code with a tap, but introduce push-fatigue attacks — also called push bombing. An attacker who already has the password triggers approval prompts repeatedly until a worn-down or confused user taps Approve; the technique, paired with social engineering, featured in the 2022 Uber breach attributed to a Lapsus$-linked actor. Number matching — typing a server-shown number into the app rather than tapping once — has become the standard mitigation, but it still does not make push notifications phishing-resistant against a real-time relay. TOTP and standard push are stronger than SMS, yet remain phishable.

Phishing-resistant MFA closes the relay gap with cryptography rather than a shared code. FIDO2 — the pairing of the W3C WebAuthn browser API with the CTAP2 protocol for external authenticators — generates a unique public/private key pair for each website at registration. The private key never leaves the security key or device; the service stores only the public key. Crucially, the credential is origin-bound: it is tied to the exact domain it was registered to, so a look-alike phishing site cannot coax a valid signature out of it, which is the specific behavior that defeats real-time relay.

PKI smart cards reach the same bar by a different route. PIV cards, defined by NIST's FIPS 201 standard under Homeland Security Presidential Directive 12, and the Defense Department's parallel Common Access Card (CAC), store X.509 certificates and private keys on tamper-resistant hardware and authenticate by signing a challenge. Because both FIDO2 keys and PIV/CAC cards prove domain-bound possession of a non-exportable private key, NIST calls them verifier-impersonation-resistant, and CISA identifies these two categories as the phishing-resistant methods it recommends. SMS, TOTP, and plain push do not clear that bar.

For a fleet rollout, the useful question is not whether a system supports MFA but which methods it can enforce and at what assurance level. Security requirements increasingly cite NIST's AAL2/AAL3 language, and hardware authenticators bought for regulated environments are typically expected to hold FIPS 140-3 cryptographic-module validation, with identity systems touching federal personnel expected to be FIPS 201 / PIV compatible. Payment-handling buyers face a concrete deadline that has already passed: PCI DSS v4.0.1 expanded mandatory MFA from remote and administrative access to any access into the cardholder data environment, effective March 31, 2025.

Federal cybersecurity direction has moved the same way, steering agencies and their contractors toward phishing-resistant methods rather than accepting any MFA implementation; defense suppliers evaluate their posture against NIST SP 800-171 controls. It is worth being precise about what that means: supporting FIDO2/WebAuthn or PIV/CAC is a technical-compatibility fact, not a government endorsement, certification, or contracting status, and standards documents describe requirements for agencies rather than confer credentials on any vendor. The practical takeaway for a buyer is to specify the authenticator category, confirm the enforcement controls, and treat the weakest allowed factor as the real security ceiling.