Hanad KubatVisit Website →
← Back to blog

Engineer Led MFA for SaaS: FIDO2, Session Binding, Fixed Price

September 30, 2026
Engineer Led MFA for SaaS: FIDO2, Session Binding, Fixed Price

Phishing-resistant MFA, FIDO or WebAuthn through your identity provider, is the baseline every SaaS platform should aim for. When that is out of reach today, app-based authenticators with number-matching are the practical fallback, not SMS. Enforce whichever method you choose at the IdP layer where possible, bind the MFA assurance to the session or JWT, and treat account recovery as its own security problem before you roll anything out.

TL;DR:

  • Phishing-resistant MFA methods like FIDO2 and WebAuthn are ideal but often unavailable, so app-based authenticators with number-matching provide a practical fallback.
  • SMS and voice codes should only be used as a last resort, as they are highly vulnerable to interception and SIM-swap attacks.
  • Enforcing MFA at the identity provider level via federation simplifies management and enables centralized auditing, but app-level enforcement remains necessary for direct signups.
  • Adaptive MFA that considers device, location, and sensitive actions helps balance security with user experience, especially for admin accounts requiring always-on MFA.
  • Proper implementation requires careful session management, comprehensive API validation, and strong recovery process controls to prevent bypasses and reduce attack vectors.
Hanad Kubat
hanadkubat.com
Build MFA Into Real Software
Hanad Kubat builds working SaaS products with payments, logins and maintainable code, using a fixed scope and fixed price.
Discuss your SaaS build

Table of Contents

Why MFA matters for SaaS platforms

SaaS login pages are a constant target. Credential stuffing, where attackers replay stolen username and password pairs from other breaches, works because people reuse passwords across services. Phishing kits harvest credentials directly, and once an attacker has a working login, they have a path into your customer's data, your billing system, and often your other customers through shared infrastructure. CISA treats the strength of the MFA a provider chooses as part of that provider's overall security posture, not a footnote. A weak MFA setup shows up later in due-diligence reviews, security questionnaires, and, worse, in breach notifications.

MFA does not stop every attack, but it closes off the ones that rely purely on a stolen password.

  • Credential stuffing: a correct password alone no longer grants access.
  • Basic phishing: even a captured password is useless without the second factor.
  • Automated account takeover: bots testing thousands of logins per hour get stopped at the second step.

The gap is what happens after that second step. A phished OTP code or a fatigued approval on a push notification can still get through, which is why the method you pick matters as much as the decision to require one at all.

Core MFA methods: pros, cons, and suitability for SaaS

Not all MFA is equal, and treating "we have MFA" as a solved problem is where most SaaS teams stop too early.

  • SMS and voice codes: the weakest option. They are vulnerable to SIM-swap and SS7 interception, and CISA's fact sheet lists them as acceptable only as a temporary or last-resort measure.
  • TOTP authenticator apps: widely supported and stronger than SMS, but still phishable if a user is tricked into entering a code on a fake login page, per OWASP's MFA guidance.
  • Push notifications with number matching: better than a plain "approve or deny" push because the user has to enter a number shown on the login screen, which cuts down on fatigue-driven accidental approvals.
  • Hardware keys and FIDO2/WebAuthn: the strongest option. The credential is cryptographically bound to the site's origin, so a fake login page simply cannot use it, which is what makes it phishing-resistant rather than just phishing-resistant in name.
  • Biometrics: convenient as a local unlock mechanism, usually paired with a platform authenticator (Face ID, Windows Hello) that itself uses FIDO2 underneath.

Phishing resistance is not evenly distributed across these methods. OWASP notes that TOTP is stronger than SMS but still lacks the origin-binding that makes FIDO2 resistant to phishing by design.

For internal admin accounts, hardware keys or platform biometrics tied to FIDO2 are worth the onboarding friction because admins hold the keys to everything else. For external customers on a self-serve SaaS product, TOTP apps with number-matching push as an alternative give most of the practical protection without forcing everyone to buy a hardware key. Constrained environments, shared kiosks, field devices with no personal phone, are where SMS sometimes survives as a fallback, but it should never be the only option offered.

SSO and identity provider considerations for SaaS

Where you enforce MFA changes what you can audit and how much custom code you have to maintain.

  1. Delegate to the IdP when you can. Centralizing MFA at the identity provider, via OIDC or SAML federation, gives you one place to see enrollment status, failure rates, and policy changes across every connected application.
  2. Keep native MFA as a fallback for direct signups. Not every customer will federate through an IdP, so a native flow still needs to exist for accounts created directly in your product.
  3. Enforce at the tenant level for multi-tenant SaaS. Each customer organization should be able to require MFA for its own users without affecting other tenants, which means your policy engine needs tenant scoping built in from the start.
  4. Use Conditional Access patterns where available. Microsoft's documentation describes enforcement modes, off, always on, or conditional, that let you vary requirements by application, user group, or risk signal rather than applying one blanket rule.

The trade-off is real: IdP-level enforcement gives you centralized auditing and less custom code to maintain, but it also means your app-level flows need to trust and correctly validate whatever assertion the IdP hands back. A federation setup that USDA used to extend FIDO across a large application estate is a useful reference point here, centralizing through SSO made phishing-resistant MFA practical at scale rather than something each application had to implement separately, according to a CISA case study.

Adaptive and conditional MFA: policy design that balances security and UX

Requiring a second factor on every single login, every time, trains people to click through prompts without reading them. Adaptive MFA instead raises the bar when the situation looks risky and stays out of the way when it does not.

  • New device or browser: a login from a device that has never been seen on that account is a reasonable trigger for a fresh MFA challenge.
  • Unusual geolocation: a login from a new country minutes after one from another is worth a step-up check.
  • Sensitive actions: changing a password, adding a payment method, or exporting customer data should require re-authentication even mid-session.
  • Admin accounts: these should have MFA always on, with no conditional exceptions, since the blast radius of a compromised admin account is much larger than a single customer seat.

Pro Tip: Cap push notification retries and add a short lockout after repeated failures. It cuts down on "approval fatigue" attacks where someone spams a user with push prompts until they accidentally tap approve.

The policy design question is less about picking the strictest possible rule and more about matching the challenge to the actual risk. Customers logging in from the same device they always use do not need the same friction as someone trying to change billing details from a new IP address.

Implementing MFA in your SaaS product: step-by-step practical checklist

Rolling out MFA well is less about the cryptography and more about sequencing the work so nothing breaks for existing users.

  1. Design first. Pick your primary method (FIDO2 or TOTP with number-matching push), map every user journey that touches authentication, including invite flows and SSO handoffs, and write down your recovery policy before you write any code.
  2. Build the enforcement layer. Integrate with your IdP or implement native enrollment and verification, then bind the resulting MFA assurance level to the session token or JWT so every downstream API call can check it.
  3. Secure the APIs, not just the login page. A common gap is enforcing MFA in the web UI while a direct API endpoint still accepts a bare password, so audit every entry point that authenticates a user.
  4. Test adversarially. Write automated tests for MFA-bypass attempts, session hijack scenarios, and account recovery attack trees, not just the happy path where a user enters the right code.
  5. Pilot before you flip the switch for everyone. Roll out to a small internal group or a handful of high-trust tenants first, watch enrollment and failure rates, and fix the support playbook before wider release.
  6. Monitor after launch. Track enrollment rate, MFA success and failure ratios, and support ticket volume tied to lockouts or recovery requests, since a spike in any of these usually points to a UX problem, not a security one.

Pro Tip: Treat your first pilot group's support tickets as a design review. If three people get stuck on the same enrollment step, that step is broken, not the users.

A companion resource on core SaaS security controls covers where MFA fits alongside the rest of your security stack if you are building the checklist from scratch.

Developer checklist and common implementation pitfalls

Most MFA failures I see are not cryptographic, they are plumbing problems: the second factor gets checked once at login and then forgotten for the rest of the session.

  • Bind MFA assurance to the session, not just the login event. OWASP's session management guidance warns that failing to persist MFA state lets an attacker who hijacks a session skip the second factor entirely.
  • Validate MFA claims on sensitive API calls. A password change or data export endpoint should check that the current session actually carries an MFA-verified claim, not assume it because the user is logged in.
  • Check every authentication path, not just the main one. Mobile apps, API keys, and admin backdoors used for support often skip the MFA logic that the web UI enforces, and OWASP flags this inconsistency as a common bypass route.
  • Treat account recovery as a separate, high-risk flow. OWASP notes that a weak recovery process can let an attacker regain access without ever touching the MFA check, which quietly defeats the whole point.
  • Rate-limit and log recovery attempts. Out-of-band verification (a callback, a secondary email confirmed over time, a manual review for high-value accounts) and strict logging make recovery abuse visible instead of silent.

Standards and compliance cues: NIST, CISA, and OWASP takeaways

You do not need to become a standards body to get this right, but three references are worth keeping open while you design.

  • CISA marks phishing-resistant MFA as the standard to aim for and recommends number-matching for push-based apps as a practical intermediate step when FIDO2 is not yet feasible.
  • OWASP recommends testing MFA flows directly, securing session management so assurance persists, and hardening recovery flows against the exact bypass techniques attackers already use.
  • NIST's authentication assurance level framework points to AAL2, which requires multi-factor authentication, as the appropriate bar for higher-risk online services, a level most SaaS platforms handling customer data should be aiming to meet.

None of these three organizations treat MFA as a checkbox. They each frame it as a system: the method, the session, and the recovery path all have to hold up together, or the weakest one becomes the actual security level of the product.

Rollout, adoption, and support: minimizing friction while increasing coverage

Getting MFA adopted, not just built, is its own project.

  • Phase enforcement by risk. Start with admins and any high-risk tenants, then expand to the general customer base once the support playbook is proven.
  • Make onboarding forgiving. Give users backup codes at enrollment, a clear device registration step, and a recovery path they can find without opening a support ticket.
  • Track the numbers that matter. Enrollment rate, MFA success and failure ratios, support tickets tied to lockouts, and any change in account-takeover incidents after rollout tell you whether the policy is working or just annoying people.

A phased plan like the one in this 2 to 4 week security plan for PMs and security leads is a reasonable pace: fast enough to matter, slow enough that support does not drown.

What I'd prioritize if I were building this today

What I'd prioritize if I were building this today — overview diagram

I build software end to end, one person, no juniors touching the code, which means I have no patience for security features that look good in a demo and fall apart under a real support load. MFA is exactly that kind of feature if you skip the boring parts.

My rule: pick IdP-first, phase in FIDO2/WebAuthn for admins and high-value tenants before pushing it everywhere, and build account recovery before you build the happy path. Recovery is where attackers actually get in, and it's the part teams design last, under deadline pressure, which is backwards. Treat it as core scope from day one, not an afterthought bolted on before launch.

— Hanad Kubat

How I can help: fixed-price implementation and rescue for SaaS MVPs

If your login flow, payment integration, or account recovery was built fast to validate an idea and now needs to hold up under real users and a real security review, that's the exact wall I work at. The prototype is the spec: I take what exists, whether it's a Lovable, Bolt, or Cursor build that stalled around 70%, or a Figma file with no code yet, and build the real version with MFA, session handling, and recovery done properly from the start.

  • Your app, a fixed-price build from €12,000, covers a first real version or a full rescue rebuild, two to four weeks, no surprise invoices.
  • The plan, a fixed-price audit from €1,500, is a short first step if you want a clear scope before committing to a full build.
  • Every line is written by me, and you own the code from the first commit, so the next developer, or the next security review, can actually read it.

Start with Hanadkubat if you want a clear-eyed look at what your login and recovery flows need before you build further.

Sources

For deeper technical or audit work: CISA's phishing-resistant MFA guidance and its USDA FIDO case study, OWASP's Multifactor Authentication and Session Management cheat sheets, and Microsoft's Azure AD B2C MFA documentation. For architecture context around identity and multi-tenancy, see this SaaS architecture guide.

FAQ

Is 2FA being phased out?

No, two-factor authentication is not being phased out, but weaker forms of it, especially SMS-based codes, are being deprioritized in favor of phishing-resistant options like FIDO2 and WebAuthn. CISA continues to recommend SMS only as a temporary or last-resort factor, not as a method to build new systems around.

What are the three types of MFA?

MFA factors are typically grouped as something you know (a password or PIN), something you have (a phone, hardware key, or authenticator app), and something you are (a fingerprint or face scan). Most practical SaaS implementations combine a password with a possession factor like a TOTP app, a push notification, or a FIDO2 hardware key.

What are the top 10 MFA solutions?

There is no single official top-ten list, and naming specific vendors here would go beyond what any standards body has published. The stronger question to ask is whether a given solution supports phishing-resistant FIDO2/WebAuthn, integrates with your identity provider, and lets you enforce policy per tenant, since those factors matter more than a vendor's ranking.

Which is better, SSO or MFA?

SSO and MFA solve different problems and work best together rather than as alternatives: SSO centralizes who a user is across multiple applications, while MFA verifies that the person logging in actually is that user. Enforcing MFA at the identity provider, as Microsoft's Conditional Access model shows, lets a single MFA policy protect every connected application rather than requiring a separate implementation for each one.