MFA adoption in SaaS: flaws and how to test them in 2026

Flaw #1: no MFA at all

Without a second factor, account security rests entirely on the password. Attackers do not need to guess it: they replay credential lists from other breaches (credential stuffing) or harvest passwords and cookies from machines infected by infostealers.

The defects that almost always come with missing MFA make it worse:

• no rate limiting on the login endpoint, so thousands of combinations can be tried;
• different responses depending on whether the email exists, which lets attackers sort valid accounts first (see user enumeration);
• very long sessions with no way to revoke them;
• no alert on a login from a new country or device.

The most exposed account is the customer admin: it sees every employee in the company.

Flaw #2: MFA that is present but bypassable

Adding an "enter your code" screen is not enough. The bypasses we see most often in testing:

1. MFA checked only in the UI. The server issues a full session token as soon as the password is validated; the code screen is just a front-end step. Calling the API directly with that token skips the second factor.
2. No attempt limit on the code. A six-digit TOTP code with no attempt limit can be brute-forced in a few hours.
3. Recovery flow without MFA. Password reset opens a full session without asking for the second factor again. We cover these traps in 7 password reset mistakes.
4. Disabling or re-enrolling without re-verification. From a stolen session, the attacker disables MFA or adds their own device without entering a code.
5. API tokens and personal keys outside MFA. An API key created from the account grants permanent access that never goes through the second factor.
6. Poorly integrated SSO. MFA is required on local login but not on a second path (magic link, legacy endpoint, mobile app).

How to test it

Use a test account with MFA enabled, an intercepting proxy (Burp, Caido or the browser dev tools) and a staging environment:

1. Token before code. Log in with the password and stop at the code screen. Grab the token or cookie received at that point and call a protected endpoint (GET /api/me, employee list). If it answers, the MFA is decorative.
2. Assurance level. On Supabase, decode the JWT and check the aal claim: aal1 after the password, aal2 after the code. Then check that your RLS policies or API require aal2 for sensitive data.
3. Code brute force. Send 20 wrong codes in a row. The server must block or clearly slow down.
4. Recovery. Reset the password and see whether the resulting session skips the code.
5. Factor management. From an active session, try to disable MFA or add a device without re-entering a code.
6. Secondary paths. List every way to obtain a session: magic link, mobile app, SSO, API key, old API version. MFA must apply to each one.
7. Login. Try 50 wrong passwords on one account: lockout, delay or captcha must kick in, and the response must be identical for a non-existent email.

How to fix it

• Verify the second factor server-side. A token issued before the code must be limited to the verification step. On Supabase, require aal2 in the policies of sensitive tables.
• Make MFA mandatory for admins and for any account that sees other users' data. Offer it to everyone.
• Prefer passkeys (WebAuthn), which resist phishing, over TOTP, and TOTP over SMS.
• Limit attempts on both the password and the code.
• Ask for the factor again for sensitive actions: email change, disabling MFA, creating an API key, bulk export.
• Revoke sessions on password change and shorten their lifetime (see JWT expiration).

What changes when an AI agent acts with the account

An AI agent built into the product, or connected by a user, acts with a token or an API key. That token was obtained once, then reused without a second factor for every action. If the agent can export data, change bank details or invite a user, those sensitive actions sit outside the MFA you put on the interface.

The concrete risk: a prompt injection hidden in a document or email the agent reads triggers an action the user would never have approved, and no factor is requested. The defence is the same as for a human: an explicit confirmation, outside the model, for high-impact actions, and agent tokens limited to what is strictly needed.

Checking that an agent cannot sidestep your authentication controls is part of the Agent Red Team Express, in five days and with evidence.