8 Types of Multi-Factor Authentication and How to Choose

Multi-factor authentication (MFA) requires proof from at least two distinct factor categories: something you know, have, or are. A password plus a code from an enrolled authenticator can be MFA. A password plus a security question is still two knowledge checks, not two independent factors. The practical choice is not simply “turn on MFA”; it is which authenticators users can enroll, what happens when one is lost, and whether the fallback preserves the protection you intended.

This guide compares eight authenticator and challenge families. Some are general industry options, not a list of features Frontegg supports. If you are configuring Frontegg specifically, use the current MFA management documentation for the supported methods and account/application policy controls.

Factors, methods and policies are different things

The three familiar factor categories are knowledge (for example, a password), possession (an enrolled phone or security key) and inherence (a biometric characteristic). A method is how an authenticator proves a factor: a time-based code, a signed WebAuthn challenge, or a bound push approval. A policy decides when and for whom to require that proof. Adaptive MFA is a policy, not a ninth authenticator.

Nor does every convenient login route create MFA. A magic link used on its own is a passwordless login route; social login delegates authentication to another provider; a security question after a password is another knowledge test. Any of these may sit inside a broader journey, but the journey must actually establish two distinct factors before it is called MFA. NIST SP 800-63B uses this independence as the basis for its AAL2 requirements. Its rules apply to systems claiming that federal assurance profile; they are not a blanket compliance mandate for every SaaS product.

1. Authenticator-app codes (TOTP)

An enrolled app generates a short-lived code from a shared secret. The user types the code after their primary login step. TOTP works without cellular coverage and is widely understood. It is still phishable: a fake site can ask for the current code and relay it to the real site before it expires. Treat enrollment-secret protection, rate limits, device replacement and recovery as part of the design. Frontegg documents authenticator apps as an available MFA method.

2. Hardware one-time-password tokens

A dedicated token displays or generates a code, so the user does not need a smartphone. This can help an organization with users who cannot install an app or bring a personal phone. The operator must distribute, bind, replace and revoke devices; a typed code can still be relayed through a phishing site. Do not confuse a hardware code token with a WebAuthn security key simply because both are physical.

3. SMS or voice-delivered codes

A code sent to a registered number can provide a familiar possession check. It also depends on the phone network and the security of number enrollment and changes. SIM swaps, number porting and real-time phishing are relevant threats. NIST treats PSTN-based out-of-band authentication as restricted and calls for alternatives; that is a useful design warning, not a claim that SMS never counts as MFA. Frontegg documents SMS as an MFA option. Confirm the exact primary-login/MFA combination in your integration rather than assuming the same SMS code can serve as two independent factors.

4. Email-delivered codes

An email code is accessible when a user has no enrolled phone or authenticator app. It is weaker when the same mailbox also resets the primary credential, and it can be intercepted or relayed. NIST’s current AAL guidance does not permit email as an out-of-band authenticator; do not label a password-plus-email-code flow “NIST AAL2 compliant” without a separate assessment. Frontegg’s MFA docs list email, but its documented setup paths have version and interface details; verify availability for your deployment before promising it to customers.

5. Push challenges in an enrolled authenticator app

A device-bound app can ask the user to approve a login. A bare “Approve/Deny” prompt is susceptible to fatigue attacks if someone sends repeated requests. A design that asks the user to transfer or match a displayed code ties the approval more closely to the transaction. NIST describes this out-of-band challenge model. Push is a general MFA method here; do not infer from this list that Frontegg currently offers every push variation.

6. Built-in WebAuthn authenticators

A device’s platform authenticator can sign a challenge for the legitimate website, commonly after a local fingerprint, face check or PIN. Unlike a typed OTP, a properly configured WebAuthn credential is bound to the relying party’s origin and is phishing-resistant. The biometric usually unlocks the device-bound credential locally; it is not a reusable fingerprint sent to the website. NIST requires biometrics to be paired with a physical authenticator in its assurance model. Frontegg documents built-in WebAuthn authenticators as an MFA option and notes the custom-domain requirement for domain-specific credentials.

7. Roaming WebAuthn security keys

A separate key or compatible cross-platform authenticator signs an origin-bound challenge. It can be a strong choice for tenant admins, support operators and users with elevated privileges, provided enrollment and recovery are workable. Requiring a PIN or local biometric to activate the key can make one cryptographic ceremony multi-factor; merely possessing a key without an activation factor is not the same claim. Frontegg lists WebAuthn security keys as an MFA method. Plan for a second enrolled key or a controlled recovery route so a lost device does not force an unsafe help-desk bypass.

8. Smartcards and certificate-backed authenticators

Enterprise smartcards and similar PKI devices use a private key rather than a code delivered through email or SMS. They can fit managed-device and regulated workforce environments, but provisioning, readers, certificate lifecycle and customer support increase the operational burden for a broad B2B SaaS user base. This is an industry option, not a Frontegg feature claim. Do not list it as a recommended customer MFA choice without confirming your application and identity-provider architecture can use it.

Where do passkeys fit?

A passkey is a WebAuthn credential often used for passwordless sign-in, not automatically an additional step after a password. A passkey ceremony can itself satisfy two factors when a physical authenticator requires a local PIN or biometric activation; the assurance of a particular deployment depends on that authenticator and policy. Passkeys are phishing-resistant at the authentication ceremony because the credential is bound to the legitimate origin. They do not, by themselves, fix a compromised application session or an authorization mistake.

Frontegg documents passkey sign-in separately from its MFA methods and describes restrictions on stacking passkeys with another WebAuthn challenge. If you plan to offer both, test the exact enrollment, login and recovery combinations instead of promising a double-WebAuthn step.

How should a B2B SaaS team choose?

Start with the attack you are trying to stop. If privileged customer admins face phishing or account takeover risk, an origin-bound WebAuthn route is preferable to a typed code. If your user base cannot reliably use keys or modern devices, offer a documented alternative—but decide whether that alternative is a routine option, a controlled recovery path, or an exception for a limited group. A phishing-resistant main method with an always-available weak fallback may leave the attacker a simpler route.

Then test the deployment contract:

1. Enrollment: Can a new user register an authenticator without letting an attacker attach their own device? Who approves the first device and a replacement?
2. Account and application scope: Which customers require MFA, and can the vendor control the available methods separately from a tenant admin’s enforcement choice? Users with multiple accounts or apps should see a predictable effective policy.
3. Fallback and accessibility: What happens when a device is lost, a user has no smartphone, a WebAuthn credential cannot be used, or an enterprise IdP already enforces its own policy? Accessibility and recovery are security requirements, not afterthoughts.
4. Negative tests: Try repeated push requests, a real-time relay of a TOTP or SMS code, a SIM/number change, enrollment from an untrusted session, and a help-desk reset. Measure whether a strong method can be downgraded silently.
5. Session and resource boundary: MFA confirms an authentication event. The application must still validate the active tenant, permissions and ownership of every sensitive resource. See the authorization guide for that separate decision.

In Frontegg, the MFA management guide describes enforcement options and available methods, while MFA per application separates vendor-controlled method settings from account-level enforcement and remember-device controls. Account admins can tighten policy within the vendor’s configured boundaries; they cannot assume a method unavailable to the application into existence. Verify the exact effective policy, passkey interaction and recovery behavior with Product/Engineering before making a customer-facing promise.

For the commercial overview of Frontegg’s login and MFA capabilities, see Frontegg Authentication; use the developer guides above for implementation details.