MFA best practices

Multi-factor authentication (MFA) is no longer optional. It’s one of the most effective ways to stop account takeovers, protect sensitive data, and defend against phishing, credential stuffing, and brute-force attacks. Yet, many teams still struggle with implementing MFA in a way that feels both secure and seamless.

The truth is: strong security without thoughtful design often frustrates users. On the other hand, focusing too much on convenience can create weak points that attackers exploit. The best MFA strategies balance protection and usability—and they look different depending on whether you’re building a consumer app (B2C) or an enterprise platform (B2B).

In this article, we’ll break down:

• Core MFA best practices every product should follow
• Real-world examples of what works (and what doesn’t)
• UX patterns that make MFA flows more user-friendly
• Security patterns that make MFA flows more robust
• Key differences between B2C and B2B MFA requirements

By the end, you’ll have a clear framework for implementing MFA that keeps users safe and keeps them happy.

MFA 101

MFA requires users to present two or more forms of verification, typically:

• Something you know: password or PIN
• Something you have: device, token, or authenticator app
• Something you are: biometrics like fingerprints or face ID

This layered defense dramatically reduces the risk of compromised accounts, even if a password is stolen. The strongest MFA strategies pair factors from different categories, making it significantly harder for attackers to bypass all layers simultaneously. This approach protects against single-point failures. An attacker who steals a password still can’t bypass the fingerprint requirement.

Many financial institutions now combine a user’s password (something you know) with a one-time code delivered through a mobile banking app (something you have). This pairing makes it much harder for attackers to gain access, even if credentials are stolen.

Best practices for MFA implementation

There’s no single way to implement MFA, but there are common patterns that consistently lead to stronger security and better user experiences. Below are the core practices every team should consider when rolling out MFA.

1. Offer multiple authentication options

Not every user can or wants to use the same factor. Offering flexibility—authenticator apps, backup codes, and biometric options—improves adoption. But not all MFA methods are created equal. SMS and email can be intercepted, while app-based OTPs are still vulnerable to phishing. The gold standard is phishing-resistant MFA, such as hardware security keys, passkeys, or device-bound biometrics.

For example, GitHub requires stronger factors like security keys for administrators, but also supports app-based OTP for broader users, striking a balance between inclusivity and assurance.

How to do it right:

• Provide at least two distinct MFA methods.
• Always offer at least one phishing-resistant method (e.g., passkeys, WebAuthn hardware keys) alongside fallback methods.
• Encourage users to enroll in a backup factor during the setup process.
• SMS MFA is fundamentally insecure, so avoid relying on it for high-security use cases. Use it only as a fallback.

2. Use adaptive, risk-based authentication

Not every login carries the same level of risk. Challenge users with additional factors only when something looks unusual, like a new device, suspicious location, or high-value transaction. This keeps friction low in everyday scenarios while raising the bar in riskier contexts.

For example, Google uses contextual signals in Gmail and Google Workspace, stepping up authentication only when activity seems risky. For everyday logins, users experience minimal friction.

Implementation tips:

• Always step up MFA for sensitive actions (password resets, payments, admin changes).
• Define risk triggers such as geo-velocity anomalies (impossible travel), new devices, or suspicious IP ranges. Tools like WorkOS Radar can automate this detection and response.
• Trust known, compliant devices for smoother logins, but re-check when circumstances change.

3. Enforce MFA enterprise-wide

For organizations, MFA must apply across all access points—cloud services, VPNs, and internal apps. Gaps in enforcement are opportunities for attackers, and partial rollouts create inconsistent user experiences. Clear policy and universal enforcement ensure MFA becomes a trusted, expected part of every login.

For example, Microsoft reported that accounts without MFA are 99.9% more likely to be compromised. As a result, they now require MFA across their Azure and Microsoft 365 environments.

Recommended approach:

• Require MFA for all privileged accounts (admins, root, developer access).
• Extend MFA to every application, not just the primary login portal.
• Use conditional access policies to mandate MFA for remote or third-party logins.
• Audit MFA enrollment regularly to ensure no one is bypassing controls.

4. Guard against MFA fatigue

Push-based MFA is convenient, but it can be abused. In 2022, Uber experienced a breach after attackers bombarded an employee with push notifications until one was mistakenly approved—a technique now known as MFA fatigue. This incident underscores why guardrails against over-prompting are essential.

For example, Cisco Duo added “number matching” to push approvals, where users must confirm a code shown on the login screen. This reduces the risk of blind approval under fatigue attacks.

To prevent this, enforce clear limits:

• Allow only 3–5 push requests in a short window (e.g., 5 minutes).
• Limit users to ~10 pushes per hour and ~30 per day, with alternate factors required after that.
• Introduce a short cool-down period (30–60 seconds) between attempts, increasing if suspicious patterns continue.
• Features like number matching or displaying login details (device, location, app) help users spot malicious requests.
• Flag accounts that exceed limits and alert admins if unusual push volumes are detected.
• Limit MFA prompts for low-risk sessions (e.g., within the same device/browser), but always re-challenge on high-risk actions such as:
  
  • Changing email or password
  • Accessing admin dashboards
  • Viewing sensitive data (PII, payment info)

5. Plan for fallbacks

Devices get lost, SIMs change, and hardware keys fail. Provide clear, secure backup flows such as recovery codes or administrator resets. Having these options available builds user confidence and prevents MFA from becoming a barrier to productivity.

For example, GitHub allows users to generate backup codes for when their authenticator device is unavailable, ensuring they don’t get locked out while still maintaining strong security.

Practical steps:

• Offer single-use recovery codes during enrollment and encourage safe storage.
• Provide two or more backup factors (e.g., email, SMS, help desk override).
• Require extra verification for resets (e.g., identity checks for admin-assisted recovery).
• Log and monitor recovery attempts for suspicious activity.

6. Combine MFA with SSO & strong access control

MFA on its own dramatically reduces account takeover risk, but it shouldn’t live in isolation. To build a truly resilient identity layer, MFA must be paired with single sign-on (SSO) and granular access control.

• SSO integration. Let users authenticate through trusted identity providers, and enforce MFA upstream at the IdP. This reduces password sprawl, centralizes policy enforcement, and gives admins a single place to monitor activity.
• Role-based access controls (RBAC). Even with MFA, not every user should have the same level of access. Limit sensitive actions (like admin changes, financial approvals, or production access) to roles that require them.
• Contextual policies. Combine MFA with conditional rules based on IP, device compliance, or geography to reduce risk. For example, require MFA re-authentication before a high-value transaction or when a login comes from an unusual country.

MFA should be one layer among many. By pairing it with SSO and access controls, you reduce the blast radius of a compromised account and give your security team better visibility.

7. Mind the UX

Security shouldn’t come at the cost of usability. A confusing MFA flow can frustrate users or drive them to seek workarounds. From our own UX Best Practices for MFA:

• Minimize friction: Prompt for MFA only when necessary.
• Clarity and guidance: Use clear, friendly instructions.
• Mobile-friendly design: Optimize for small screens and autofill OTPs.
• Accessible experiences: Support users with disabilities and provide alternatives to biometrics.
• Consistency and trust: Keep visual design aligned with your brand to reinforce legitimacy.

For example, Apple Pay balances convenience and security by using biometrics (Face ID/Touch ID) seamlessly integrated into the device’s UX, making strong authentication almost invisible to the user.

Practical UX tips:

• Use plain, non-technical language (“Enter the code from your app” vs. “Provide TOTP”).
• Keep code entry short-lived (30–60 seconds) but allow autofill for speed.
• Provide visual indicators (e.g., “Code expires in 25 seconds”) to reduce confusion.
• Ensure screens work across mobile and desktop without breaking formatting.

8. Lock down the details

Designing MFA that looks good on the surface is one thing—but ensuring it’s bulletproof under the hood is another. The real strength of MFA comes from how challenges, secrets, and verifications are handled behind the scenes.

Key practices to implement:

• Challenge tokens (e.g., SMS or TOTP) should have short lifetimes. WorkOS defaults to 10 minutes for SMS.
• Never allow reuse of a successful MFA challenge. After a successful verification, the challenge ID should be marked as consumed or invalidated. WorkOS enforces this already — lean on that logic.
• Log all MFA enrollment, challenge, and verification attempts. Include metadata like IP address, user agent, timestamp, and the MFA method used.
• Provide mechanisms for users to securely update, re-enroll, or reset their MFA devices. If suspicious activity is detected, force re-enrollment or invalidate existing factors.
• Periodically test that MFA is enforced where expected. Run integration tests to verify that challenges, expirations, and verifications behave correctly.
• Secure secrets:
  
  • Never expose the TOTP secret or SMS challenge codes outside of controlled flows.
  • Always store factor and challenge IDs securely.
  • Store secrets securely (e.g., encrypted at rest, never in logs).
• Use HTTPS when displaying the QR code or accepting user input.

B2C vs. B2B: Different MFA needs

Not all applications are the same. MFA strategies that work for consumer apps may not be appropriate for enterprise environments, and vice versa. Understanding the difference is key.

B2C (Consumer applications)

Consumer apps live and die by ease of use. MFA in this context must feel quick, familiar, and forgiving, or users will simply abandon the flow.

• Prioritize speed and convenience. Users expect frictionless login, so biometrics or push-based MFA often win.
• Broad device support. Users log in from personal laptops, phones, or shared devices.
• Recovery matters. Lost access must be easy to fix, or users churn.

Instagram offers MFA via SMS or authenticator apps: simple, mobile-first methods that align with a broad consumer audience. Netflix also emphasizes recovery, making it simple for users to re-secure their accounts after device loss or password compromise, critical for retention in consumer apps.

How to approach it:

• Offer easy enrollment flows and make MFA opt-out difficult but possible.
• Provide SMS fallback since it remains widely accessible, but encourage stronger methods.
• Allow “remember this device” options for trusted personal devices.

B2B (Enterprise applications)

Enterprises operate with higher stakes and stricter requirements. MFA in this context must integrate with existing systems and withstand advanced threats.

• Stronger assurance. Enterprises demand robust MFA, often with hardware keys or enforced device management.
• Federated identity integration. Support for SAML, SCIM, and OAuth ensures compatibility with corporate IdPs.
• Policy enforcement. Admins must be able to enforce MFA universally and monitor compliance.

AWS requires MFA for root accounts and strongly recommends hardware keys for administrative roles, reflecting the higher stakes of enterprise environments. Similarly, Okta and Google Workspace mandate MFA for admins and encourage enterprise-wide enforcement, providing dashboards that help security teams ensure compliance.

Recommended approach:

• Require MFA for all privileged accounts with no exceptions.
• Support FIDO2 security keys or device certificates for higher assurance.
• Enable admin reporting dashboards to monitor compliance.
• Allow policy-based exceptions (e.g., stricter MFA for contractors or external users).

MFA best practices checklist

‍

• Provide at least two distinct MFA methods (e.g., app-based OTP + SMS backup).
• Encourage users to enroll in a backup factor during setup.
• SMS MFA is fundamentally insecure, so avoid relying on it for high-security use cases. Use it only as a fallback.
• Always step up MFA for sensitive actions (password resets, payments, admin changes).
• Define risk triggers, such as geo-velocity anomalies (impossible travel), new devices, or suspicious IP ranges (see how Radar can help).
• Trust known, compliant devices for smoother logins, but re-check when circumstances change.
• Require MFA for all privileged accounts (admins, root, developer access).
• Extend MFA to every application, not just the primary login portal.
• Use conditional access policies to mandate MFA for remote or third-party logins.
• Audit MFA enrollment regularly to ensure no one is bypassing controls.
• Enforce clear limits to defend against MFA fatigue attacks:
  
  • Allow only 3–5 push requests in a short window (e.g., 5 minutes).
  • Limit users to ~10 pushes per hour and ~30 per day, with alternate factors required after that.
  • Introduce a short cool-down period (30–60 seconds) between attempts, increasing if suspicious patterns continue.
  • Features like number matching or displaying login details (device, location, app) help users spot malicious requests.
  • Flag accounts that exceed limits and alert admins if unusual push volumes are detected.
• Offer single-use recovery codes during enrollment and encourage safe storage.
• Provide two or more backup factors (e.g., email, SMS, help desk override).
• Require extra verification for resets (e.g., identity checks for admin-assisted recovery).
• Log and monitor recovery attempts for suspicious activity.
• Follow UX best practices:
  
  • Use plain, non-technical language (“Enter the code from your app” vs. “Provide TOTP”).
  • Keep code entry short-lived (30–60 seconds) but allow autofill for speed.
  • Provide visual indicators (e.g., “Code expires in 25 seconds”) to reduce confusion.
  • Ensure screens work across mobile and desktop without breaking formatting.
• Harden the security:
  
  • Use short challenge lifetimes (e.g., 10 minutes for SMS).
  • Invalidate MFA challenges after successful use—no reuse allowed.
  • Log all MFA activity with metadata (IP, user agent, method, timestamp).
  • Provide secure flows for device updates, resets, and re-enrollment.
  • Regularly test MFA enforcement with integration checks.
  • Protect secrets: never expose TOTP/SMS codes, encrypt at rest, and keep them out of logs.
  • Always use HTTPS for QR codes and MFA inputs.
• For B2C apps:
  
  • Offer easy enrollment flows and make MFA opt-out difficult but possible.
  • Provide SMS fallback since it remains widely accessible, but encourage stronger methods.
  • Allow “remember this device” options for trusted personal devices.
• For B2B apps:
  
  • Require MFA for all privileged accounts with no exceptions.
  • Support FIDO2 security keys or device certificates for higher assurance.
  • Enable admin reporting dashboards to monitor compliance.
  • Allow policy-based exceptions (e.g., stricter MFA for contractors or external users).

How WorkOS can help

Building strong MFA and identity flows from scratch can be complex. WorkOS takes away that heavy lifting by providing enterprise-grade authentication features out of the box—so you can focus on building your product, not your identity stack.

• MFA and Passwordless: Easily add modern MFA methods or passwordless login (like passkeys or magic auth) to your app with developer-friendly APIs and SDKs.
• SSO integration: Connect to any enterprise Identity Provider with just a few lines of code, so B2B customers can bring their own IdP.
• WorkOS Radar: Proactively stop account takeovers by detecting suspicious logins. Radar uses device fingerprinting to tell legitimate users apart from malicious ones. This ensures automated protections block or challenge threats without disrupting real users. Detailed logs and insights give your team visibility into authentication activity and help meet compliance requirements.
• Developer-first experience: Pre-built UI components, SDKs, and clear documentation mean you can ship secure flows in days, not months.

And because WorkOS user management is free for up to 1 million monthly active users (including MFA among other features), you can implement enterprise-grade security from day one without worrying about cost.

Final thoughts

MFA is no longer optional—it’s a foundational element of modern authentication. But the best MFA strategy isn’t just about adding layers of security; it’s about designing flows that protect without frustrating.

Whether you’re building for millions of consumers or an enterprise workforce, consider your context, apply best practices, and design with user experience in mind. Done right, MFA can be both secure and seamless.

And you don’t have to build it all yourself. Tools like WorkOS make it simple to implement MFA, passwordless login, and SSO, while providing advanced protections like Radar. That way, you can deliver enterprise-grade security from day one, without slowing down your roadmap.

The sooner you start, the sooner your users are protected—and with WorkOS, you can be up and running in days.