What is multi-factor authentication (MFA)?

What does MFA stop that a password alone cannot?

Your users reuse passwords, and some of those passwords are already in leaked lists. MFA is what stops a reused password from becoming a breached account. For your own team, it matters even more: an admin account or a database dashboard without MFA is the easiest way into everything.

Which MFA methods are strongest, and which are weakest?

Not all second factors are equal. NIST's current guidance, SP 800-63B-4, classes codes sent by SMS or voice call as restricted, and says manually typed codes, including authenticator app codes, are not phishing-resistant. Passkeys and security keys that use cryptographic authentication bound to the real site are the strongest option it describes.

Which accounts should require MFA first?

Start with the accounts that could do the most damage. First every account your team uses to run the product, such as hosting, database, code repository, email and payments; then admin roles inside your own app; then customer accounts holding money, health or other sensitive data, with MFA optional for everyone else.

1. Every account your team uses to run the product: hosting, database, code repository, email, payments.
2. Admin roles inside your own app.
3. Customer accounts that hold money, health or other sensitive data, then everyone else as an option.

Auth providers such as Clerk offer MFA as a setting, so for your users it is mostly a product decision. For your team's accounts it is a checklist, and security reviews will ask to see it done.

How do you require MFA in a Supabase or Lovable app?

Supabase Auth supports authenticator app codes and phone codes. After a normal sign-in a session is at assurance level aal1; once the user passes a second factor it becomes aal2, and that level is written into the session token's aal claim. You can then make the database itself refuse sensitive rows to aal1 sessions.

• Turn on the MFA methods you want in the Supabase dashboard and build the enrol and verify screens.
• Add a restrictive policy that checks (select auth.jwt()->>'aal') = 'aal2' on sensitive tables. Supabase notes a token without the claim counts as aal1.
• Choose who must use it: everyone, new users after a date, or users who have already enrolled a factor.

Hiding a screen until MFA is done is not enough on its own; the check has to sit where the data is, the same rule as in authentication vs authorization. If you use Clerk, its reverification feature asks a signed-in user to verify again before sensitive actions such as changing a password or removing MFA. Our Lovable security checklist lists the other sign-in checks, and the production readiness check gives a quick read on your app.