What is Multi-Factor Authentication (MFA)?

Back to learning

Multi-Factor Authentication (MFA) asks a user to prove access with more than one type of evidence. A password alone is one factor. MFA adds another factor, such as a one-time code, authenticator app approval, hardware security key, passkey, or biometric unlock tied to a trusted device.

MFA is one of the most useful controls in account security, but it is not proof that an account is safe. It answers a narrow question: can this user or session present the extra factor right now? It does not prove the password was private, the browser is clean, the session will remain safe, or the person approving the prompt has not been tricked.

The main factor types

The strength varies by method. SMS is better than a password alone, but it is exposed to SIM swap, number recycling, and message interception. Time-based codes are stronger, but users can still enter them into a phishing page. Push approvals are convenient, but repeated prompts can train users to approve without thinking. Hardware security keys and phishing-resistant passkeys provide stronger protection because they bind authentication to the legitimate site or device context.

Where MFA helps

MFA raises the cost of account takeover when the attacker only has a username and password. That matters because credential stuffing is common: attackers take leaked credentials from one service and test them against another, relying on password reuse. If MFA is enrolled and enforced, a valid password may no longer be enough to enter the account.

MFA also helps with compliance, privileged access, remote access, and sensitive account actions. A service may allow routine browsing after login but require a fresh factor before changing an email address, adding a payment method, exporting data, or resetting recovery options. This step-up approach keeps friction closer to the risky action instead of treating every request the same.

Why MFA is incomplete

Attackers do not need to break MFA cryptography to get around it. They can target the user, the surrounding request path, or the session after authentication.

Credential stuffing still matters because automation can test which passwords work before MFA is triggered. That creates account lockouts, support load, and useful intelligence for attackers. Residential proxies make the login traffic look closer to normal customer traffic, weakening simple IP reputation, geolocation, and rate-limit rules. If the only remaining decision is an MFA prompt, the control stack is too thin.

Social engineering is another gap. An attacker with a valid password can trigger a one-time code, then call or message the user with a story that convinces them to share it. Push-based MFA can be abused the same way through repeated prompts and urgency. The user is being asked to make a security decision while under pressure and with less context than the system has.

Session abuse sits after MFA. Malware, phishing kits, browser extensions, stolen cookies, or token leakage can give an attacker access to an authenticated session. If the application treats a completed MFA event as permanent trust, the attacker may change account details, place transactions, or export data without another check.

Making MFA work in the stack

MFA works best as one decision point inside a wider account protection model. Login attempts should still be checked for breached credentials, bot behaviour, device and browser context, proxy use, route velocity, and account history. Sensitive actions should support step-up authentication, session review, token rotation, or forced logout when the context changes.

Recovery also needs discipline. Lost devices, new phones, backup codes, help desk overrides, and MFA resets are common failure points. A strong MFA setup can be weakened by a soft recovery process.

In Zero Trust terms, MFA is useful evidence, not lasting trust. Keep it, prefer phishing-resistant methods where possible, and surround it with controls that can still detect credential stuffing, residential proxy abuse, session risk, and social engineering.