Multi-Factor Authentication
MFA (Multi-Factor Authentication) combines something you know, have and are — password plus phone, token or biometric — so a stolen password alone isn't enough.
Strengthen Account Security
Combine MFA with advanced bot protection
What is Multi-Factor Authentication (MFA)?
Multi-factor authentication requires two or more independent kinds of evidence before granting access. The conventional grouping is something you know (a password), something you have (a phone, a hardware key) and something you are (a fingerprint, a face).
The word doing the work is independent. Two passwords are not two factors. A password plus a code sent to an email account protected by that same password is barely one and a half, because compromising the email compromises both.
SMS, apps, push and hardware keys compared
Treating all MFA as the same is the most common mistake, and the differences are large:
| Method | Resists password theft | Resists phishing | Notes |
|---|---|---|---|
| SMS one-time code | Yes | No | Vulnerable to SIM swapping and to interception; still far better than nothing |
| Authenticator app (TOTP) | Yes | No | A phished code works for 30 seconds, which is long enough for an attacker |
| Push approval | Yes | Partly | Defeated by fatigue — repeated prompts until the user taps accept |
| Hardware key (FIDO2/WebAuthn) | Yes | Yes | The challenge is bound to the origin, so a fake site cannot relay it |
Only the last row stops phishing, and it does so for a structural reason rather than a procedural one: the browser signs a challenge tied to the real domain, so a credential captured on a lookalike site is useless.
Stolen passwords versus attempt volume
MFA makes stolen passwords much less valuable, which directly undercuts credential stuffing — a correct password alone no longer gets an attacker in.
What it does not do is stop the attempts. A credential-stuffing run against an MFA-protected login still consumes your capacity, still generates the authentication load, and still tells the attacker which username and password pairs are valid, which is itself a saleable result. It also drives one of the uglier attacks in the table above: once an attacker knows a password is correct, push fatigue becomes viable.
This is why the enrolment and recovery paths matter more than the factor itself. Attackers do not break MFA; they go around it, through "I lost my phone" flows, support-desk resets and enrolment endpoints that are themselves protected by nothing but a password.
Where bot protection fits
The two layers address different halves of the problem, and both are needed:
- MFA makes a correct password insufficient
- A bot layer stops the automated attempts from arriving at all, which protects the enrolment and recovery endpoints MFA depends on and keeps the attacker from learning which credentials are live
Put human verification on the login, reset and enrolment paths, and prefer WebAuthn where you can deploy it. Together those close the route attackers actually use, which is rarely the factor and nearly always the process around it.