MFA Factors: TOTP, Push, FIDO2, and Beyond

Not all second factors are created equal. The difference between SMS-based OTP and a FIDO2 hardware key is not incremental — it is the difference between a factor that an attacker can intercept in real time and one that is mathematically impossible to phish. As a GRC Engineer, you need to understand each factor well enough to evaluate whether an organization's MFA deployment actually mitigates the threats it claims to address, or whether it creates a false sense of security that collapses under a targeted attack.

This lesson covers every MFA factor you will encounter in enterprise environments, explains the technical mechanisms behind each one, and maps them to the compliance questions auditors actually ask.

When MFA locks YOU out on a Monday morning

The three factor categories

Every authentication factor falls into one of three categories. These categories are defined in NIST SP 800-63B and referenced across SOC 2, ISO 27001, and every major compliance framework:

Something you know — passwords, PINs, security questions. Knowledge factors are the weakest category when used alone because knowledge can be shared, phished, guessed, or extracted from breached databases.
Something you have — a phone receiving a push notification, a hardware security key, a smart card. Possession factors are stronger because an attacker must obtain the physical object (or compromise the device) to authenticate.
Something you are — fingerprint, face scan, iris scan. Inherence factors are the hardest to forge remotely, but also the hardest to revoke if compromised. You cannot rotate your fingerprint.

Multi-factor authentication requires credentials from at least two different categories. A password plus a security question is NOT multi-factor — both are something you know. A password plus a push notification IS multi-factor — something you know plus something you have.

SMS and voice OTP

SMS-based one-time passwords are the most widely deployed second factor and the weakest one still in common use. The flow is simple: you enter your password, the system sends a 6-digit code via SMS or an automated voice call, and you enter the code.

The problems are well-documented:

SIM swap attacks: An attacker calls your carrier, social-engineers the support representative into transferring your phone number to a new SIM card, and receives your OTP codes. This is not theoretical — SIM swap attacks have been used in high-profile cryptocurrency thefts, corporate breaches, and targeted attacks on executives.
SS7 interception: The SS7 signaling protocol that routes SMS messages between carriers has known vulnerabilities that allow interception. State-level actors and sophisticated criminal groups have exploited SS7 to intercept OTP codes in transit.
Malware on the device: If the user's phone is compromised, malware can read incoming SMS messages and forward the codes to an attacker.
Social engineering: An attacker who has already phished the user's password can call the user pretending to be IT support and ask them to read the code that was "just sent for verification."

NIST SP 800-63B explicitly restricts SMS-based OTP, classifying it as a "restricted authenticator" and recommending that organizations offer alternatives and assess the risk before relying on SMS as a second factor. Despite this, SMS remains common because it requires no app installation, no hardware distribution, and no user training.

TOTP: Time-based one-time passwords

TOTP — used by Google Authenticator, Authy, Microsoft Authenticator (in TOTP mode), and 1Password — works by sharing a secret between the service and the authenticator app during enrollment. Both the service and the app use this shared secret combined with the current time to generate a 6-digit code that changes every 30 seconds.

The mechanism is straightforward: during enrollment, the service generates a random secret and encodes it in a QR code. The user scans the QR code with their authenticator app. From that point forward, both the service and the app can independently compute the same code for any given 30-second window using HMAC-SHA1 (or SHA-256/SHA-512 in newer implementations).

TOTP is significantly better than SMS because the code never travels over a network — it is computed locally on the user's device. SIM swap and SS7 attacks are irrelevant. However, TOTP has a critical weakness: it is phishable. The user reads the code off their phone and types it into whatever login screen is in front of them. If that login screen is a phishing proxy controlled by an attacker, the attacker receives the valid TOTP code and replays it to the real site within the 30-second window. The user has no way to verify whether the site requesting the code is legitimate.

Quick check

Why is TOTP considered phishable despite the code being generated locally on the user's device?

Because the shared secret can be intercepted during enrollment

Because the user manually types the code into whatever login page is displayed, which could be a phishing proxy that replays it to the real site

Because TOTP codes are transmitted over SMS

Because the 30-second window is too long for the code to be secure

Push notifications

Push-based MFA — Okta Verify, Microsoft Authenticator (in push mode), Duo — sends a notification to the user's registered device asking them to approve or deny the login attempt. The user taps "Approve" and the authentication completes. No code to type, no code to intercept.

Push is more convenient than TOTP and eliminates the manual code entry that makes TOTP phishable to replay attacks. However, push notifications introduced a new attack vector: MFA fatigue, also known as push bombing.

In an MFA fatigue attack, the attacker has already obtained the user's password (through phishing, credential stuffing, or a breach). They repeatedly trigger login attempts, sending a flood of push notifications to the user's phone. The user, annoyed or confused, eventually taps "Approve" to make the notifications stop — or taps "Approve" accidentally while trying to dismiss them. The attacker is in.

This is not theoretical. The 2022 Uber breach used exactly this technique. The attacker bombarded an Uber employee with push notifications until the employee approved one.

Number matching mitigates MFA fatigue. Instead of a simple approve/deny prompt, the login screen displays a two-digit number and the push notification asks the user to enter that number. The user must look at both the login screen and the phone, matching the number. This prevents blind approval because the attacker (who triggered the login) does not know which number is displayed on the victim's screen. Microsoft Entra ID, Okta, and Duo all support number matching, and it should be required in any enterprise deployment.

FIDO2 and WebAuthn

FIDO2 — encompassing the WebAuthn browser API and the CTAP2 protocol for communicating with authenticators — is fundamentally different from every factor discussed so far. It uses public key cryptography instead of shared secrets, and it is origin-bound, meaning the authenticator cryptographically verifies the domain of the site requesting authentication.

Here is how it works: during enrollment, the authenticator (a hardware key like YubiKey or a platform authenticator like Touch ID) generates a public/private key pair. The private key stays on the authenticator and never leaves it. The public key is registered with the service. During authentication, the service sends a challenge. The authenticator signs the challenge with the private key — but only after verifying that the requesting origin (the domain in the browser's address bar) matches the domain registered during enrollment.

This origin-binding is what makes FIDO2 phishing-resistant. If an attacker sets up a phishing site at accounts-g00gle.com and the user visits it, the authenticator checks the origin. The registered origin is accounts.google.com. The origins do not match. The authenticator refuses to sign the challenge. The attack fails silently — the user does not even have the option to authenticate to the wrong site.

There is no shared secret to steal, no code to replay, no notification to approve blindly. The cryptographic proof is bound to the legitimate domain at the hardware level.

Hardware keys (YubiKey, Google Titan, Feitian) are physical FIDO2 authenticators that connect via USB, NFC, or Bluetooth. They are the gold standard for privileged accounts because the private key exists only on the physical device and cannot be extracted.

Platform authenticators (Touch ID, Windows Hello, Android biometric) are FIDO2 authenticators built into the device's secure enclave. They provide the same cryptographic guarantees as hardware keys but are tied to a specific device.

Passkeys: The evolution of FIDO2

Passkeys extend FIDO2 by allowing credentials to sync across devices within an ecosystem (Apple Keychain, Google Password Manager, 1Password). A passkey created on your iPhone is available on your Mac, iPad, and any device signed into the same Apple ID.

Passkeys retain the phishing resistance of FIDO2 — they are still origin-bound and use public key cryptography. The difference is portability. Traditional FIDO2 hardware keys require you to have the physical key present. Platform authenticators require you to be on the specific device. Passkeys follow you across devices.

The industry trajectory is toward passkeys replacing passwords entirely. Google, Apple, and Microsoft all support passkeys as a primary authentication method. For GRC Engineers, this means evaluating whether passkey implementations meet the same security bar as hardware keys — in most cases they do for general workforce use, but hardware keys remain the recommendation for the highest-privilege accounts because the private key on a hardware key provably cannot be extracted or synced.

Weakest                                                              Strongest
◄──────────────────────────────────────────────────────────────────────────────►

SMS/Voice OTP     TOTP            Push          Push + Number     FIDO2/Passkeys
┌──────────┐   ┌──────────┐   ┌──────────┐    Matching          ┌──────────────┐
│ SIM swap │   │ Phishable│   │ MFA      │   ┌──────────────┐   │ Origin-bound │
│ SS7      │   │ via proxy│   │ fatigue  │   │ Stops blind  │   │ Public key   │
│ Intercept│   │ replay   │   │ attacks  │   │ approval     │   │ crypto       │
│          │   │          │   │          │   │ Still proxy-  │   │ Phishing     │
│ NIST     │   │ No origin│   │ No origin│   │ vulnerable   │   │ resistant    │
│ restricted│  │ binding  │   │ binding  │   │              │   │              │
└──────────┘   └──────────┘   └──────────┘   └──────────────┘   └──────────────┘

MFA phishing resistance spectrum: each step represents a meaningful security improvement over the previous factor

Comparison table

Factor	Phishing Resistant?	User Experience	Deployment Cost	Recovery Complexity
SMS/Voice OTP	No — codes can be intercepted or replayed	Simple, no app needed	Very low	Low — just need a phone number
TOTP	No — user types code into any page	Moderate — requires app install	Low	Medium — backup codes or re-enrollment
Push Notification	No — MFA fatigue, proxy attacks	Good — tap to approve	Medium — requires app + enrollment	Medium — device re-registration
Push + Number Matching	Partially — stops fatigue, still proxy-vulnerable	Good — enter matching number	Medium	Medium — device re-registration
FIDO2 Hardware Key	Yes — origin-bound, no shared secret	Moderate — must have key present	High — $25-50 per key, logistics	High — backup key required
Passkeys	Yes — origin-bound, synced across devices	Excellent — biometric tap	Low — built into OS	Low — synced via cloud account

GRC Engineer's focus

When auditors evaluate MFA, they ask four questions that go beyond "is MFA enabled?" First: What is the MFA enrollment rate? — 100% enrollment is the target, and any gap is a finding. Second: Which factors are allowed? — if SMS is the only option, the auditor will note the risk. Third: Are phishing-resistant factors required for privileged accounts? — SOC 2 CC6.1 and NIST 800-53 IA-2 increasingly expect phishing-resistant MFA for administrators, cloud infrastructure engineers, and anyone with elevated access. Fourth: What is the fallback if a user loses their device? — the recovery process must be documented and secure. An insecure recovery flow (like "call the help desk and they reset MFA with no identity verification") undermines the entire MFA deployment. Map each of these to your control library and ensure you have evidence for all four.

Quick check

An organization deploys Okta with push notifications for all employees but does not enable number matching. An attacker obtains an employee's password from a credential breach and repeatedly triggers login attempts. What is this attack called, and what is the most effective mitigation?

Credential stuffing — mitigated by rate limiting login attempts

MFA fatigue (push bombing) — mitigated by enabling number matching so the user must enter a displayed code instead of just tapping Approve

SIM swap — mitigated by switching to TOTP

Phishing — mitigated by training users not to click suspicious links

What to carry forward

MFA factors exist on a spectrum from easily bypassed to cryptographically phishing-resistant. Knowing where each factor sits on that spectrum is essential for writing accurate risk assessments, recommending appropriate controls for different user populations, and evaluating whether an organization's MFA deployment actually matches its stated risk tolerance.

In the next lesson, you will see exactly how a phishing attack bypasses TOTP and SMS in real time — and why FIDO2 stops it cold. Understanding the attack is what makes the policy recommendation credible.