Examples of MFA: Practical Guide for Individuals & IT Teams

TL;DR:

• Multi-factor authentication combines credentials from different categories, enhancing security beyond passwords alone.
• Organizations should prioritize phishing-resistant methods like hardware keys and passkeys, especially for high-risk accounts.

The most common examples of MFA are: password + SMS one-time code, password + TOTP authenticator app, password + push notification, password + hardware security key (FIDO2/YubiKey), password + biometric (fingerprint or face), smart card/PIV + PIN, PKI certificate + PIN, and passwordless passkey (FIDO2 alone). Each pairs a primary credential with a second or third factor from a different category.

Here is the quick-reference list:

• Password + SMS OTP — a one-time code texted to your phone
• Password + TOTP app — a 6-digit code from Google Authenticator, Authy, or Microsoft Authenticator, refreshing every 30 seconds
• Password + push notification — a tap-to-approve prompt sent to a registered mobile app
• Password + hardware security key — a physical FIDO2 device such as a YubiKey plugged into USB or tapped over NFC
• Password + biometric — fingerprint or face scan on a trusted device
• Smart card / PIV + PIN — common in federal government and healthcare
• PKI certificate + PIN — certificate stored on a device or token, verified cryptographically
• Passwordless passkey (FIDO2/WebAuthn) — replaces the password entirely; the device authenticates via biometric or PIN bound to a cryptographic key
• Email OTP — a code sent to a registered email address (low-assurance fallback)
• Backup codes — static one-time codes generated at enrollment for account recovery

NIST SP 800-63B defines MFA as requiring two or more distinct factors from separate categories. Logmeonce supports the full range above, including passwordless options.

Pro Tip: Start with TOTP or a hardware key for any admin account. SMS is better than nothing, but it is the weakest option on this list and should be treated as a fallback, not a primary second factor.

How authentication factor categories map to real MFA examples

Every MFA method draws from at least two of four factor categories. Understanding the categories tells you immediately whether a combination actually qualifies as MFA or just two instances of the same factor type.

Something you know — a secret only the user holds:

• Password or passphrase
• PIN
• Security question answer (low assurance; avoid as a sole second factor)

Something you have — a physical or digital object in the user’s possession:

• TOTP authenticator app (Google Authenticator, Authy, Microsoft Authenticator)
• Hardware security key (YubiKey, FIDO2 token)
• Smart card / PIV card
• Phone receiving an SMS OTP or push notification
• PKI certificate stored on a device

Something you are — a biometric characteristic:

• Fingerprint scan
• Face recognition (Face ID, Windows Hello)
• Voice recognition (less common; higher error rates)

Something you do / contextual signals — behavioral and location factors used in adaptive MFA to adjust authentication requirements dynamically:

• Typing cadence and mouse movement patterns
• GPS location or IP geolocation
• Device posture and health signals

NIST SP 800-63B and Microsoft guidance both treat the first three categories as the primary factor types for assurance-level calculations. Behavioral and location signals typically serve as risk signals that trigger step-up authentication rather than as standalone factors.

Deep dive: how each common MFA example works

SMS one-time password (OTP)

When you log in, the service sends a 4–8 digit code to your registered phone number via text. You enter it within a short window, usually 5–10 minutes. The code is generated server-side and delivered over the public telephone network.

Pros and cons:

• ✅ No app required; works on any phone
• ✅ Fast to deploy for consumer-facing services
• ❌ Vulnerable to SIM-swapping, SS7 interception, and real-time phishing proxies
• ❌ Fails when the user has no cell signal

CISA explicitly flags SMS OTP as susceptible to MFA bypass attacks and recommends moving to phishing-resistant alternatives where feasible. Deployment cost is near zero, but the security ceiling is low. Best for: consumer accounts where any MFA is better than none, or as a fallback only.

TOTP authenticator apps

Apps like Google Authenticator, Authy, and Microsoft Authenticator generate time-based one-time passwords that rotate every 30 seconds using a shared secret established at enrollment. The code never travels over the network during login — only the user’s input does.

Pros and cons:

• ✅ Works offline; no cell signal needed
• ✅ Much harder to intercept than SMS
• ✅ Free for users; low cost to deploy
• ❌ Still phishable via real-time proxy attacks (attacker relays the code before it expires)
• ❌ Device loss requires recovery flow

Authy adds encrypted cloud backup of TOTP seeds, which simplifies device migration but introduces a cloud dependency. Google Authenticator added encrypted backup in 2023. Microsoft Authenticator ties backup to a Microsoft account. Deployment complexity is low: scan a QR code at enrollment, done. Best for: individuals, SMBs, and most enterprise workloads that cannot yet deploy hardware keys.

Push notifications

The authentication server sends an approve/deny prompt to the user’s registered mobile app. The user taps “Approve” and the session proceeds. No code to type.

Pros and cons:

• ✅ Lowest friction of any second factor
• ✅ Displays context (location, app name) so users can spot anomalies
• ❌ Vulnerable to push fatigue (MFA bombing): attackers send repeated prompts hoping the user taps approve out of frustration
• ❌ Requires internet connectivity and a smartphone

Number-matching and additional context (showing the login location) significantly reduce push fatigue risk. Microsoft Authenticator and similar enterprise apps now require the user to enter a number displayed on the login screen before approving. Best for: enterprise SSO environments where user experience matters and push-fatigue mitigations are enabled.

Hardware security keys (YubiKey, FIDO2/WebAuthn)

A hardware key like a YubiKey stores a private cryptographic key that never leaves the device. During login, the browser or OS sends a challenge; the key signs it with the private key and returns the signature. The server verifies the signature against the registered public key. No shared secret, no code to intercept.

Pros and cons:

• ✅ Strongly phishing-resistant: the key will not respond to a fake domain
• ✅ No battery; works offline for the cryptographic operation
• ✅ FIDO2/WebAuthn is an open standard supported by all major browsers and platforms
• ❌ Hardware cost ($25–$60 per key, typically)
• ❌ Lost key requires a pre-registered backup key or recovery flow
• ❌ Some legacy enterprise apps do not support WebAuthn yet

Statistic: One set of real-world MFA case studies reported a reduction of approximately 70% in unauthorized access events after organizations moved from SMS or basic OTP to stronger app-based or hardware-backed MFA methods.

The USDA deployed FIDO-based phishing-resistant authentication for workers who could not use PIV cards — including large seasonal workforces and staff in environments requiring decontamination — demonstrating that FIDO scales even in operationally constrained settings. Best for: high-value accounts, privileged access, financial services, government, and any environment where phishing is a primary threat.

Biometrics (fingerprint, face recognition)

Biometrics authenticate “something you are” by comparing a live sample against a stored template. On modern devices, the comparison happens locally on a secure enclave (Apple’s Secure Enclave, Android’s Trusted Execution Environment) — the raw biometric data never leaves the device.

Pros and cons:

• ✅ Fast and frictionless for the user
• ✅ Template stored locally; not transmitted over the network
• ❌ Cannot be changed if compromised (unlike a password)
• ❌ Accuracy varies by sensor quality and environmental conditions
• ❌ Regulatory constraints in some jurisdictions on biometric data storage

Biometrics most often serve as the local unlock mechanism for a FIDO2 passkey or hardware key, not as a standalone network factor. Face ID unlocking a passkey is a strong combination. Best for: consumer devices, mobile banking, and any scenario where speed matters and the biometric is device-bound.

Smart cards and PIV certificates

A smart card (or PIV card in federal use) stores a PKI certificate and private key on a tamper-resistant chip. The user inserts the card into a reader and enters a PIN. The card signs a challenge; the server verifies the certificate chain.

Pros and cons:

• ✅ Very high assurance; widely used in federal government under HSPD-12
• ✅ Certificate revocation provides centralized control
• ❌ Requires card readers and middleware; high deployment complexity
• ❌ Card issuance and management infrastructure is expensive
• ❌ Not practical for remote or BYOD workforces without additional tooling

Best for: federal agencies, defense contractors, healthcare systems with strict compliance requirements, and enterprise environments with existing PKI infrastructure.

PKI certificates (device or software-based)

Similar to smart cards but the certificate lives in the device’s certificate store or a software token rather than physical hardware. Mutual TLS (mTLS) uses this model for machine-to-machine authentication.

Pros and cons:

• ✅ No physical token required
• ✅ Transparent to the user once provisioned
• ❌ Certificate lifecycle management is complex at scale
• ❌ Device theft can expose the certificate if not protected by a PIN or TPM

Best for: enterprise device fleets managed by MDM, zero-trust network access, and API authentication between services.

Passwordless passkeys (FIDO2/WebAuthn)

Passkeys replace the password entirely. The device generates a public/private key pair at registration. Login requires the user to verify locally via biometric or PIN, which unlocks the private key to sign the server’s challenge. No password exists to steal or phish.

Pros and cons:

• ✅ Phishing-resistant by design: keys are domain-bound
• ✅ No password reuse or credential stuffing risk
• ✅ Synced passkeys (iCloud Keychain, Google Password Manager) enable cross-device use
• ❌ Recovery requires a fallback method if all devices are lost
• ❌ Enterprise adoption is still maturing; not all IdPs support passkeys fully

Best for: consumer apps targeting mainstream users (Apple, Google, Microsoft ecosystems) and forward-looking enterprise deployments replacing legacy password flows.

Email OTP and backup codes

Email OTP sends a code to a registered email address. Backup codes are static one-time codes generated at enrollment and stored offline by the user. Both are low-assurance options.

• Email OTP security depends entirely on how well the email account itself is secured.
• Backup codes are single-use and should be stored in a password manager or printed and locked away.
• Neither should serve as a primary second factor for high-value accounts.

Best for: account recovery flows and as a last-resort fallback when primary MFA is unavailable.

Security best practices and common pitfalls to avoid

Getting MFA deployed is step one. Getting it deployed well is where most organizations stumble.

Best practices:

• Prefer phishing-resistant MFA (FIDO2/WebAuthn, hardware keys, passkeys) for privileged accounts, remote access, and any system holding sensitive data.
• Use adaptive MFA to trigger step-up authentication only when risk signals warrant it — new device, unusual location, high-value transaction.
• Require MFA on all administrative and remote access paths before anything else.
• Secure the enrollment flow: verify identity before binding a new factor to an account.
• Plan recovery before you need it: pre-register a backup key or backup method at enrollment time.
• Log and monitor authentication events; alert on repeated failed MFA attempts (a sign of push bombing or credential stuffing).

Common pitfalls:

• Relying solely on SMS OTP for high-risk accounts — SIM swapping is a real and documented attack vector.
• Ignoring push fatigue: without number-matching, users under a push-bombing attack often approve the wrong request.
• Weak recovery options that effectively bypass MFA (e.g., “forgot phone? answer these three security questions”).
• Poor enrollment identity proofing — binding a new factor without verifying the requester’s identity defeats the purpose.
• Treating MFA as a one-time project rather than an ongoing program with monitoring and periodic review.

Pro Tip: Per Microsoft session guidance, MFA prompts are typically required only on first sign-in to a new device, after session expiry, or after a password change. Configure session lifetime policies to minimize re-prompting on trusted devices — this cuts friction without reducing security.

How to choose the right MFA method for your situation

The right method depends on your threat model, your users, and your operational constraints. Work through these questions in order.

1. What is your primary threat?

• Phishing or credential theft at scale → FIDO2/WebAuthn or hardware keys, non-negotiable.
• Account takeover on consumer apps → TOTP app as a minimum; passkeys where supported.
• Insider threat or privileged access abuse → smart card/PIV or hardware key plus session monitoring.

2. Who are your users and what devices do they control?

• Corporate-managed devices → certificate-based or FIDO2 via MDM enrollment.
• BYOD or remote workers → TOTP app or push notification with number-matching.
• General consumers → TOTP app or passkeys; SMS as a fallback only.

3. What are your regulatory requirements?

• Federal government: HSPD-12 mandates PIV; NIST SP 800-63B AAL2/AAL3 sets the bar.
• Financial services: FFIEC guidance recommends risk-based, layered authentication.
• Healthcare: HIPAA does not mandate a specific MFA method but requires access controls that meet the standard.

4. What is your budget and timeline?

5. What is your recovery plan?

• Every deployment needs a tested recovery path that does not bypass MFA.
• Pre-register a backup hardware key or backup TOTP device at enrollment.
• For enterprise, use a helpdesk-verified identity-proofing step before resetting any factor.

6. Can you use two-factor authentication as a starting point?

• Yes. Start with TOTP for all accounts, then layer hardware keys for privileged access as the program matures.

How Logmeonce approaches MFA and passwordless authentication

Logmeonce is built around the premise that strong authentication should not require a PhD to deploy. The platform supports the full spectrum of MFA methods covered in this article, with centralized management that works for a single user or a large enterprise team.

Key capabilities relevant to MFA and passwordless:

• Passwordless authentication: Logmeonce’s passwordless version 5.2 supports FIDO-based passkeys across iOS, Android, Windows, and macOS — covering the major platforms where users actually work.
• Hardware key support: Compatible with FIDO2 hardware tokens, so organizations moving toward phishing-resistant MFA can do so within a single management console.
• SSO integration: Single sign-on ties MFA enforcement to every connected application, so one strong authentication event covers the user’s entire session rather than requiring repeated logins.
• Recovery and enrollment flows: Centralized administration lets IT teams manage factor enrollment, set recovery policies, and audit authentication events from one dashboard.
• Individual to enterprise scale: Plans cover personal users who want to secure personal accounts, SMBs deploying MFA for the first time, and enterprise teams with compliance requirements.

For organizations evaluating a move from SMS OTP to TOTP or hardware keys, Logmeonce provides a migration path that does not require ripping out existing infrastructure.

Key Takeaways

Phishing-resistant MFA methods — FIDO2 hardware keys and passkeys — are the strongest options available, and organizations that move from SMS OTP to app-based or hardware-backed MFA typically see a reduction of approximately 70% in unauthorized access.

The trade-off nobody talks about enough

The security community spent years telling people that any MFA is better than no MFA. That was true and necessary — it got millions of accounts off password-only authentication. But it created a secondary problem: organizations deployed SMS OTP, checked the “MFA enabled” box, and stopped there.

SMS MFA is not a destination. It is a starting point that has a known, documented attack surface. SIM swapping is not a theoretical threat; it has been used in high-profile account takeovers across financial services and crypto exchanges. The gap between SMS OTP and a FIDO2 hardware key is not marginal — it is the difference between a factor that can be intercepted in real time and one that is cryptographically bound to a specific domain and device.

The harder truth is that the weakest link in most MFA deployments is not the factor itself — it is the recovery flow. An organization can deploy YubiKeys for every employee and still be wide open if the account recovery process accepts a phone call and a few security questions. Attackers know this. They target the recovery path precisely because the front door is now locked.

The practical move: treat enrollment and recovery as security-critical as the factor itself. Require identity verification before any factor reset. Pre-register backup keys. Audit recovery events the same way you audit failed logins. That is where the real security work happens, and most guides skip it entirely.

Logmeonce makes phishing-resistant MFA practical

Deploying FIDO2 passkeys, hardware key support, and SSO-integrated MFA across your accounts does not have to mean months of infrastructure work. Logmeonce centralizes the whole process — factor enrollment, session policy, recovery flows, and audit logging — in one platform that scales from a single user to an enterprise team.

The platform’s passwordless authentication covers iOS, Android, Windows, and macOS, and hardware key compatibility means you can move toward phishing-resistant MFA without replacing your existing identity infrastructure. If you are ready to move past SMS OTP and toward authentication that actually holds up under attack, visit the Logmeonce cybersecurity page to see plans and start a free trial.

Authoritative sources and further reading

Standards and official guidance:

• NIST SP 800-63B / NIST Glossary: Multi-Factor Authentication — the primary U.S. standard for digital identity assurance levels and factor definitions; the baseline for any serious MFA policy.
• CISA: Multi-Factor Authentication — CISA’s MFA resource hub, including guidance on phishing-resistant methods and implementation checklists.
• CISA: Phishing-Resistant MFA Success Story — USDA FIDO Implementation — a detailed case study showing how FIDO-based MFA replaced weaker methods across a large, operationally complex federal agency.

Product documentation and technical guidance:

• Microsoft: What Is Multi-Factor Authentication? — clear explanation of TOTP, push, and other methods; good starting point for end-user communication.
• Microsoft: Azure MFA Prompts and Session Lifetime — explains when MFA prompts fire and how to configure session policies to reduce friction.
• Palo Alto Networks Cyberpedia: What Is Adaptive MFA? — practical overview of context-aware authentication and how adaptive policies work in enterprise environments.

Real-world examples and method surveys:

• Supertokens: Real-World Examples of Multi-Factor Authentication — survey of MFA deployments across banking, healthcare, education, and e-commerce, with outcome data.
• FFIEC Authentication Guidance — financial sector authentication standards referenced by U.S. banks and credit unions.
• FTC: Gramm-Leach-Bliley Act — the federal statute that drives MFA requirements in financial services; useful context for compliance-driven deployments.

Sadia Israr

Sadia, with her Master of Computer Applications, stands at the intersection of technology and communication. Her academic background has endowed her with a deep understanding of complex technical concepts, which she skillfully simplifies for diverse audiences. Sadia’s extensive experience in both technical realms and writing enables her to translate intricate technical ideas into clear, engaging, and accessible content.