Best MFA Providers for Developers

Two things are true about multi-factor authentication at the same time, and most buying decisions only account for one of them.

The first is that MFA stops the attack that actually happens to your users. Credential stuffing against a password database someone else leaked is the highest volume attack on the internet, and a second factor breaks it regardless of how bad the password was. Whatever else you conclude from this article, having some second factor beats having none by a margin nothing else in your security budget matches.

The second is that a second factor is a step you added to every login, and every step you add loses people. Enrolment is where it bites hardest: the prompt appears, the user does not have the app, does not want to install one, is on a train, and taps “remind me later” forever. The cost does not appear on a security dashboard. It appears as signups that do not complete and dormant accounts that were never protected, and nobody who approved the MFA project budgeted for it.

Between those two facts sits the thing that actually decides your design, which is that “MFA” is not one control. A time based code, a push approval, an SMS message and a hardware backed key resist completely different attacks. Two of them are defeated by an attacker who is sitting in the middle of the login in real time, which is the attack that has been industrialised. Ranking them honestly is the first job.

Key takeaways

• SMS is the weakest widely deployed factor because it is defeated by SIM swap, an attack that requires no technical access to the user at all. It is still better than nothing and should not be your default.
• TOTP and push both fall to a real time relay, where the attacker proxies the login and forwards the challenge. Number matching mitigates push fatigue; it does not fix phishing.
• Phishing resistance only comes from origin binding, which means WebAuthn credentials. Everything else is a shared secret that a convincing page can collect.
• Recovery codes are where most implementations are weakest. Generated once, shown once, never rotated, often stored where a support agent can read them, and frequently accepted without any rate limit at all.

TOTP, push and SMS: what each one actually resists

TOTP is a published algorithm, not a product. So is the HOTP counter variant underneath it. No vendor in this article invented them and none can improve them; what vendors sell is the enrolment UX, the delivery infrastructure, the policy engine and the recovery surface around them. Understanding the mechanism tells you which of those actually matter.

What TOTP gives you

A shared secret is generated at enrolment, displayed as a QR code, and stored by an authenticator app. Both sides derive a code from that secret and the current time in fixed intervals, so the code is verifiable offline with no network round trip and no per message cost.

That last property is the whole appeal. TOTP has no delivery dependency. There is no SMS gateway to pay, no push service to reach, no inbox to land in. It works on a plane. For a developer facing product whose users already have an authenticator app, it is the cheapest credible factor available.

What TOTP does not do

It does not resist phishing. The code is a shared secret typed into whatever page asked for it. A proxy site that renders your login, collects the password and the code, and immediately replays both to you has defeated it. This class of attack is not hypothetical or expensive; it is packaged toolkits.

It does not protect the secret at rest on your side. You are storing a symmetric secret that generates valid codes forever. If your database leaks, every enrolled user’s second factor leaks with it. Encrypt those secrets with a key held outside the database, and treat the seed store with the same seriousness as a password hash store.

It does not survive a lost phone. The secret lives in the app. A user who reinstalls without a backup loses the factor and lands in your recovery flow, which is why authenticator apps that sync across devices have become the norm and why your recovery design carries more load than you expect.

Clock drift is a real support case. Codes are validated within a small window of intervals. A device with a badly wrong clock produces codes you reject with no useful error, and the user experiences it as “my app is giving me wrong codes.”

Push notifications

Push approval sends a prompt to a registered device and the user taps approve. It is the best of the shared secret family on UX, because there is nothing to type, and it carries context: the vendor can show the application, the location and the device requesting access.

Its characteristic failure is push fatigue, sometimes called MFA bombing. The attacker has the password and simply triggers the prompt repeatedly, at night, until the user taps approve to stop the phone buzzing. This works, it has worked against sophisticated targets, and it is a human factor problem that no amount of notification design fully removes.

Number matching is the mitigation that works. Instead of an approve button, the login screen shows a number and the user must select or type that number on their phone. An attacker triggering a prompt out of band cannot supply the number, so a blind approval is impossible. If you are deploying push, number matching should not be optional, and the vendor’s support for it is a real differentiator.

Push also has the same real time relay weakness as TOTP: an attacker proxying the login in real time triggers a legitimate push that the user was in fact expecting, and approves. Number matching helps here only to the extent the number shown to the user is bound to the real session, which it is not when the attacker is relaying faithfully.

And push adds a delivery dependency back in. It needs the device online and the notification service reachable, which reintroduces the availability question TOTP removed.

SMS

SMS is the most widely deployed second factor because it requires nothing of the user, and it is the weakest one in common use. Rank it honestly:

SIM swap. An attacker persuades or bribes a carrier representative to move the victim’s number to a new SIM. No technical access to the victim’s device is required at any point. Once the number is theirs, every SMS factor tied to it is theirs, including the ones protecting your password reset. This is the attack that should end the conversation about SMS as a primary factor for anything valuable.

Network and protocol interception. Signalling network weaknesses allow message interception in ways an application cannot detect or defend against.

Device level exposure. Codes render on the lock screen by default on most phones, so physical proximity is often enough.

Carrier and delivery reality. Delivery is not guaranteed, latency varies by country and route, and international delivery costs real money per message. An SMS factor is a per login cost line that scales with your user base, which is why products that started with SMS end up pushing users toward apps on economic grounds alone.

None of this means remove SMS tomorrow. For a consumer population where a meaningful share of users will not install an app, SMS enrolment beats no enrolment. Treat it as the floor: offer it, do not default to it, do not permit it as the recovery path for a stronger factor, and never let it protect an administrative account.

Where WebAuthn sits

The only factor in common use that resists phishing by construction is a WebAuthn credential, because the signature is bound to your origin and a lookalike site cannot obtain a usable one. That property is categorically different from everything above, and it is why workforce security programmes with real adversaries end up on hardware keys or platform authenticators. The mechanism is covered in the passkey and WebAuthn provider guide; for this article the relevant conclusion is that if you need phishing resistance, no amount of TOTP or push configuration gets you there.

Needs first-hand data: Pull your own factor mix: how many enrolled users hold SMS only, TOTP only, push, and a WebAuthn credential, segmented by account value or plan tier. The interesting number is the share of your highest value accounts whose only factor is SMS, because that is the population an attacker would work through first and you can migrate them deliberately.

Enrolment drop-off is the cost nobody budgets

Every MFA project has a security case and no enrolment plan, and the enrolment plan is where the money is.

The mechanics of the loss are boring and predictable. The prompt interrupts a task the user came to do. Installing an authenticator app is a context switch onto a second device. The QR code is on the screen the user is trying to photograph with the phone they are trying to enrol. Any one of these is survivable; stacked, they produce a meaningful population that never enrols.

What actually reduces the loss:

Ask at the right moment. The worst time is mid signup, when the user has not yet received any value from your product. Better moments are immediately after the first genuinely valuable action, or at the point where the user does something that clearly warrants protection.

Offer a factor the user already has. A passkey using the platform authenticator requires no app install and no typing, and on a modern phone it is one gesture. That is the lowest friction enrolment available today, and it is also the strongest factor, which is an unusually good alignment.

Make the second device optional. Requiring a phone excludes users at desktops without one to hand. Platform authenticators, hardware keys and desktop authenticator apps all avoid this.

Never show a recovery code once and move on. The user who skipped past that screen is a future support ticket with an irritated human attached.

Be careful what mandatory means. Enforcement for administrators and privileged roles is straightforward and should be immediate. Enforcement for all users is a migration with a communication plan, a grace period, and a support load spike you should staff for. For B2B products, per tenant enforcement is the usual answer, because your enterprise customers will require it and your self-serve users will leave over it. The tenancy shape for that is covered in the B2B SaaS auth guide.

Remember trusted device duration is an enrolment decision too. If a successful MFA lets a device skip the challenge for a reasonable period, users tolerate a stronger factor. If they are challenged on every login, they optimise for whatever is fastest, which is usually the weakest thing you offer.

Needs first-hand data: Instrument the enrolment funnel as four distinct steps: prompt shown, factor type selected, factor verified, recovery codes acknowledged. Measure it separately for the signup flow and for a post-value prompt. The difference between those two curves is the strongest argument you will have for when to ask, and it is specific to your product.

Step-up authentication, and doing it properly

Step-up is re-authenticating before a sensitive action rather than only at login, and it is the feature that turns MFA from a login speed bump into an actual control.

The reason it matters: a session token stolen after a successful MFA login carries the full privilege of that session. MFA at login does nothing against session theft, and session theft is exactly what a real time relay attack produces. Step-up is the control that limits what a stolen session can do.

What a good implementation needs from a provider:

A challenge API you can call from your own code, not just at login. You need to be able to say “this user must satisfy a factor now, for this action” and get back a verifiable result. Vendors differ a lot here; some expose it cleanly, some only support step-up inside their hosted login flow, which is useless for an action deep inside your application.

A recorded authentication time and method in the session. Your authorisation logic needs to ask when the user last authenticated and with what, so a step-up satisfied ten seconds ago is not re-prompted and one satisfied yesterday is. OIDC has standard claims for this, and providers that populate them honestly make your life easier.

Binding the challenge to the action. A step-up that merely proves the user did something with their phone is weaker than one that displays what is being approved. For payments and destructive administrative actions, the challenge should name the action.

Policy that is configurable without a deploy. The set of actions requiring step-up changes as the product changes, and it should not be a code release every time.

The actions that usually deserve step-up: changing an email address or password, adding or removing an MFA factor, viewing or creating API credentials, initiating a payment or payout, changing payout destinations, exporting user data, and any administrative action affecting other users. Note that the first two are also the actions an account takeover needs, which is exactly why they are on the list.

Recovery codes, and why they are the weakest part

This is the part of MFA implementations that is most often wrong, and it is wrong in ways that are easy to check.

They are credentials, so store them like credentials. Recovery codes are a bearer secret that bypasses your second factor. Hash them. Do not store them in plaintext, do not log them, and do not make them visible to support staff in an admin console, because a support tool that can read a recovery code is an insider path into every account.

Single use, and invalidate the set on use. Each code works once. Using one should mark it consumed, and a good implementation prompts the user to regenerate the remaining set afterwards.

Rate limit them like a password. This is the most commonly missing control. A recovery code endpoint with no throttling is an offline-grade guessing surface exposed online, and the codes are often shorter than a password. Rate limit per account and per source, and alert on repeated failures.

Show them once, but make the user acknowledge them. A download or copy action plus an explicit confirmation is the minimum. A screen the user can dismiss without reading produces the lockout you will pay for later.

Notify on use. A recovery code redemption should send a message to every channel on file, because a legitimate user knows they did it and a victim finds out early.

Have a second recovery route for the users who will lose the codes anyway. For consumer products that is usually a verified alternate factor. For B2B it is usually an administrator in the customer’s own tenant who can reset a user, which is far better than your support desk doing it. Delegated administration is worth real money here: it moves the identity check to someone who actually knows the person.

Audit every recovery event. Recovery bypasses your primary control, so it should be an auditable event with the actor, the method and the outcome recorded and retained. If you are already centralising audit trails, the log management guide covers where those events should land.

Auth0

Auth0 covers MFA as part of a full identity platform: TOTP, push through its own authenticator, SMS and voice, email codes, WebAuthn with both platform authenticators and roaming keys, and recovery codes. The differentiator is the policy layer, because adaptive MFA and the actions pipeline let you decide at runtime whether a given login needs a challenge based on your own signals rather than a fixed rule.

Pros

• The widest factor coverage in one place, so serving consumer and workforce populations does not mean two integrations
• Actions let you implement step-up and custom risk logic inside the authentication pipeline without standing up a service
• Adaptive MFA using device and behavioural signals reduces challenge frequency, which directly protects your enrolment and completion rates
• Mature audit and log streaming, which is what an auditor asks for when you claim MFA enforcement

Cons

• Adaptive MFA and the stronger security features sit in higher tiers, so the price you evaluate is rarely the price you end up on
• SMS and voice are a metered cost on top of the user based subscription, and they grow with login volume rather than user count
• Platform configuration complexity is real, and MFA policy drift between tenants and environments is a recurring source of incidents
• Migration away later is a project rather than a switch, as covered in the Auth0 alternatives guide

Best for: Organisations that need every factor plus runtime policy from one platform, and who will use the adaptive layer rather than a static rule.

Pricing: Monthly active user tiers with adaptive MFA and advanced security in higher tiers; SMS and voice billed as separate usage.

Okta

Okta is the workforce identity incumbent, and its MFA story is the most complete in this list for employees rather than customers. Okta Verify with push and number matching, TOTP, WebAuthn with hardware keys, and a policy engine that evaluates network zone, device posture and application sensitivity to decide what challenge applies. If your problem is employees accessing internal applications, this is the shape of product built for it.

Pros

• The deepest policy engine here: per application, per group, per network zone and per device posture rules without custom code
• Device trust integration means a managed, healthy device can be treated differently from an unknown one, which is the practical way to reduce prompts without reducing security
• Strong administrative surface for large populations, including enrolment campaigns and factor lifecycle management
• Extensive integration catalogue, so applying one MFA policy across the existing estate is configuration rather than engineering

Cons

• Priced and designed for workforce identity; using it for a consumer facing product means the customer identity product, a different fit and a different bill
• The administrative surface is substantial enough to need an owner, and an unowned Okta configuration drifts into policy exceptions nobody remembers approving
• Per user pricing across a large organisation is the most common reason buyers look at the Okta alternatives
• Custom MFA experiences inside your own product are constrained compared to an API first vendor

Best for: Organisations securing employee access to many applications, where policy per application and device posture matter more than embedding MFA in your own product.

Pricing: Per user per month by product module, with advanced policy and device trust in higher tier modules.

Descope

Descope’s visual flow model applies unusually well to MFA, because MFA is conditional logic: challenge if the risk signal fires, choose the factor the user has enrolled, fall back if the primary factor fails, enforce for this tenant but not that one. Expressing that as an editable flow rather than as code in your auth service is what makes changing an MFA policy a five minute operation instead of a release.

Pros

• Step-up is a flow you can invoke from your application, which is exactly the capability many platforms hide inside their hosted login
• Per tenant MFA enforcement without forking your login code, which is the requirement that appears with your first enterprise customer
• Factor coverage including TOTP, passkeys, email and SMS codes in one product, so changing the factor mix is configuration
• Flow changes deploy independently of your application, which matters during an incident

Cons

• Authentication policy living in a vendor console means review, diffing and rollback are the vendor implementation, not your git history
• Deep customisation pushes you back to the SDK, at which point the visual layer is overhead
• Younger vendor, which matters in enterprise procurement and when you need an answer to an obscure question at 2am

Best for: Teams whose MFA requirements vary per tenant or per action and who want that logic editable outside the release cycle.

Pricing: Per monthly active user tiers, with tenancy and advanced flow features gated to higher tiers and messaging metered separately.

Stytch

Stytch offers MFA as API primitives rather than as a hosted flow: TOTP enrolment and verification, SMS and email codes, passkeys, and session objects that record which factors were satisfied. For teams building a custom authentication experience, that last part is the important one, because it lets your own authorisation logic ask what the session actually proved.

Pros

• Factors exposed as clean APIs you call from your own flow, which makes in-product step-up straightforward rather than a workaround
• Sessions carry the authentication factors that produced them, so step-up policy can be enforced in your code with real information
• Device fingerprinting and fraud signals available alongside the factors, which is what adaptive challenge decisions need
• Separate B2B product line with organisation level MFA policy, so per tenant enforcement is supported by the data model

Cons

• More work than a drop in solution: the enrolment UI, the recovery code screens and the factor management surface are yours to build
• SMS costs are passed through and grow with login volume, so an SMS heavy design has a meter you should model early
• The B2C and B2B lines have different models and meters, so it is easy to read the wrong documentation

Best for: Teams building a custom login experience who need factor primitives and session level factor tracking rather than a hosted flow.

Pricing: Metered on monthly active users with separate B2C and B2B meters; SMS and voice delivery billed as pass through usage.

Duo

Duo is the workforce MFA specialist, and it is the product most often deployed to put a second factor in front of systems that were never designed for one: VPNs, remote desktop, SSH, on-premise applications and legacy internal tools. Its push experience with number matching is the reference implementation most others are compared against, and its device health checks let you block access from devices missing patches or disk encryption.

Pros

• Coverage of legacy and infrastructure access that application focused vendors simply do not address, including VPN, RDP and SSH
• Device health and posture checks at authentication time, which turns MFA into a device compliance gate as well
• Push with number matching done properly, and a self-service enrolment flow that large organisations can actually run
• Straightforward to deploy in front of an existing identity system without replacing it

Cons

• It is a second factor product, not an identity platform: users, directories and sessions still live elsewhere
• Aimed at workforce access rather than at embedding MFA in your own customer facing product
• Now part of a much larger vendor’s security portfolio, which means the roadmap and the commercial conversation come with that portfolio attached
• Per user pricing across a large workforce is the usual trigger for evaluating alternatives

Best for: Organisations adding strong MFA and device posture checks to existing workforce access, including infrastructure that predates modern identity.

Pricing: Per user per month in tiers, with device health, trust policies and advanced access controls in higher tiers.

Twilio Verify

Twilio Verify is the delivery layer as a product. It handles sending and validating one time codes across SMS, voice, WhatsApp and email, plus TOTP and push through its own SDK, with the routing, fallback and fraud controls that come from being part of a large messaging platform. If you have an identity system and need a reliable way to deliver and verify codes, this is the narrow, well built option.

Pros

• Multi-channel delivery with fallback between channels, which is the practical answer to SMS delivery failing in a specific country
• Fraud controls aimed at SMS pumping, which is a real and expensive attack where an attacker triggers volumes of premium route messages
• Global routing and regulatory handling for messaging, which is genuinely difficult to do yourself
• Verification is an API call, so it slots into an existing auth system without changing your identity model

Cons

• Not an identity product: enrolment state, factor management, policy and recovery are all yours to build and store
• Optimising for SMS makes it easy to build your MFA on the weakest factor because the integration is convenient
• Per verification pricing with wide variation by country and channel, so the cost model needs real attention before you scale
• Using it well still requires you to implement rate limiting and abuse controls on your own side

Best for: Teams that already own their identity layer and need reliable, multi-channel code delivery with fraud controls they will not build themselves.

Pricing: Per verification attempt, varying by channel and destination country, on top of underlying messaging costs.

Keycloak

Keycloak supports TOTP and WebAuthn as configurable authenticators inside its flow editor, with per realm policy for required actions, credential lifetimes and acceptable authenticators. It is the option for organisations that want MFA policy under their own control with no vendor in the authentication path, and the flow editor is genuinely capable once you accept its learning curve.

Pros

• Full control over the authentication flow, so conditional MFA and step-up are built from configurable authenticator steps
• WebAuthn policy per realm including user verification and attestation requirements, which is finer grained than most commercial products expose
• No vendor in the login path and no per user meter, which changes the economics entirely at large user counts
• Extension points allow custom authenticators when the built-in steps do not cover your requirement

Cons

• You operate it: HA, database, key rotation, upgrades and the CVE that lands on a Friday afternoon
• Push notifications and SMS are not built in; you integrate a delivery provider yourself and own that reliability
• The flow editor is powerful and unforgiving, and a misconfigured authentication flow can lock out a realm
• Default user facing screens need real work before a consumer product would ship them

Best for: Organisations running their own identity infrastructure who want MFA policy control without a per user bill or a vendor dependency.

Pricing: Open source with no licence cost; you pay in infrastructure, delivery provider costs and the engineering time to operate it.

LoginRadius

LoginRadius is a customer identity platform with MFA as one component of a consumer scale identity product, alongside social login, progressive profiling, consent management and regional data residency. The orientation matters: this is built for large consumer user bases where enrolment friction, regional delivery and privacy regulation drive the requirements more than device posture does.

Pros

• Consumer scale orientation, so MFA sits alongside the progressive profiling and consent tooling large user bases need
• Regional data residency options, which is often the requirement that decides a consumer identity purchase in regulated markets
• Multiple factor types with configurable enforcement per application and per user segment
• Full CIAM feature set, so MFA does not arrive as a separate integration next to your identity provider

Cons

• Less developer mindshare than the API first vendors, so there is a smaller body of community answers and examples
• A broad platform means some capabilities are present but shallower than a specialist’s, particularly around adaptive risk
• Customisation of the hosted flows is more constrained than a headless API approach
• Enterprise oriented commercial motion, so evaluating it is a sales conversation rather than a self-serve trial

Best for: Consumer facing businesses with large user bases and regional privacy requirements who want MFA inside a full CIAM platform rather than bolted on. See also the CIAM platform guide.

Pricing: Platform subscription scaled by monthly active users with feature tiers, quoted rather than self-serve.

SuperTokens

SuperTokens offers MFA as a recipe alongside its passwordless, social and session recipes, deployable self-hosted or managed. Its practical advantage in this category is that the session layer records which factors have been completed, which makes step-up enforcement something your backend can actually check rather than something you infer.

Pros

• Self-hosting keeps factor secrets, including TOTP seeds, in your own database and your own compliance boundary
• The session recipe tracks completed factors, so step-up is enforceable in your own authorisation logic
• Open source, so you can verify exactly how secrets are stored and how recovery codes are handled rather than trusting a datasheet
• Composes with the other recipes, so adding MFA to an existing deployment does not change your user model

Cons

• Self-hosting puts a core service on the path of every authenticated request, with the availability obligation that implies
• Fewer factor types out of the box than the platforms, with push and voice notably absent
• Enterprise policy features such as per application rules and device posture are not part of the product
• Smaller community, so unusual problems have fewer existing answers

Best for: Teams who want self-hosted MFA with factor aware sessions, without adopting a full identity platform or a per user meter.

Pricing: Open source and free to self-host at infrastructure cost; the managed service is metered on monthly active users with paid add ons.

How to choose

Answer these in order, because each one eliminates options.

Is this workforce access or your own product’s login? Workforce means policy per application, device posture and coverage of legacy systems, which points at Okta or Duo. Product login means APIs, embedded UI and a per user meter that scales with your customer base, which points everywhere else. Most articles on this query confuse the two and the buyers are different people.

Do you need phishing resistance specifically? If your threat model includes targeted attacks or you have a regulatory requirement, the answer is WebAuthn and everything else is a compensating control. Choose a provider whose WebAuthn support is real rather than a checkbox, using the criteria in the passkey guide.

Do you need step-up inside your application? Check specifically whether the vendor exposes a challenge API you can call from your own code for an arbitrary action, or whether step-up only exists inside their hosted login. This eliminates more shortlists than any other question and it is rarely visible on a feature page.

Will you enforce per tenant? B2B products need enterprise customers to mandate MFA for their own users while self-serve accounts remain optional. That requires a tenancy model with policy attached, not a global setting.

What will SMS actually cost you? If you support SMS at consumer scale, model the per message cost against your login volume rather than your user count, and include the abuse case where someone triggers volumes of messages to premium routes. That line has surprised a lot of teams.

Option	Shape	Picks itself when
Auth0	Full identity platform	You want every factor plus runtime adaptive policy
Okta	Workforce identity	Employees, many applications, device posture policy
Descope	Visual flow platform	Per tenant and per action policy must change without a deploy
Stytch	API primitives	You are building a custom flow and need factor aware sessions
Duo	Workforce MFA specialist	VPN, RDP, SSH and legacy systems need a second factor
Twilio Verify	Delivery layer	You own identity and need reliable multi-channel code delivery
Keycloak	Self-hosted IAM	You want policy control with no vendor and no per user meter
LoginRadius	CIAM platform	Large consumer base with regional residency requirements
SuperTokens	Open source framework	Self-hosted MFA with factor aware sessions

The highest return work is not in the vendor. Enforce a strong factor on administrators today rather than on everyone next quarter. Turn on number matching if you use push. Rate limit and hash your recovery codes. Put step-up in front of the actions an account takeover actually needs, which are changing the email address and adding a factor. Those four things cost days, not quarters, and they close the paths attackers actually use. The wider platform decision sits in the authentication provider hub.

Frequently asked questions

Is SMS based MFA still worth using?

Yes as a floor, no as a default, and never as the recovery path for a stronger factor. SIM swap requires no technical access to the victim and defeats it completely, so any account with real value should not rely on it. But for a consumer population where a significant share of users will not install an authenticator app, an SMS factor still stops credential stuffing, which is the highest volume attack there is. Offer it, make a stronger option the prominent one, and prohibit it for administrative accounts.

What is push fatigue and how do I stop it?

The attacker already has the password and repeatedly triggers approval prompts until the user taps approve to make the buzzing stop. The fix that works is number matching: the login screen displays a number that the user must enter or select on their device, so an out of band prompt cannot be blindly approved. Rate limiting prompts per account and showing the requesting application, location and device all help. If your provider offers number matching as an option, treat it as mandatory.

What is step-up authentication?

Requiring a factor at the moment of a sensitive action rather than only at login. It exists because MFA at login does nothing about a session stolen afterwards, which is exactly what a real time phishing proxy produces. The actions that usually deserve it are changing an email or password, adding or removing a factor, creating API credentials, and moving money. The first two matter most, because they are the steps an account takeover needs to become permanent.

How should recovery codes be stored and handled?

Like passwords. Hash them, never log them, never expose them in a support console, make each one single use, invalidate the remaining set after one is used, notify the user on every redemption, and rate limit the redemption endpoint the way you would rate limit a login. That last one is the most commonly missing control and turns an offline-grade guessing problem into an online one. Then give users a second recovery route, because a portion of them will lose the codes regardless of what you do.

Related reading

• Best authentication providers for developers — the platform decision that determines which MFA options you actually have.
• Best passkey and WebAuthn providers — the only factor family that resists phishing by construction.
• Best passwordless authentication providers — what happens when the second factor becomes the only factor.
• Best session management libraries — recording which factors a session satisfied, and revoking it when recovery happens.
• Best auth providers for B2B SaaS and enterprise — per tenant MFA enforcement and the requirements enterprise deals bring.
• Best enterprise SSO solutions — when the customer’s own identity provider owns the factor instead of you.