Multi-Factor Authentication (MFA) is a way of confirming identity that requires at least two independent proofs (factors) from different categories. You get access only after every required factor checks out, so a stolen password alone is not enough to sign in to an account.
The factors have to come from different categories. Pairing a password with a security question is two instances of “something you know” — and does not count as true MFA, because both can be captured the same way, for example through phishing (a fake look-alike site). The whole point of MFA is to force an attacker to break several independent channels at once.
What are the three categories of authentication factors?
MFA combines factors from separate categories. There are three classic ones, sometimes joined by context-based factors:
- Something you know (knowledge) — a password, PIN, recovery phrase, or answer to a security question.
- Something you have (possession) — a phone with an authenticator app, a hardware security key (e.g. FIDO2), a cryptographic smart card, or a code-generating token.
- Something you are (inherence) — a fingerprint, face geometry, iris scan, or voice sample.
Two extra factors are common in practice: location (IP geolocation, geofencing) and behavior (typing patterns, how you use the device). On their own they rarely count as a full factor, but they are heavily used in adaptive MFA.
How is MFA different from 2FA?
Two-Factor Authentication (2FA) is a special case of MFA that requires exactly two factors. MFA is the broader term: it covers 2FA and any setup using two or more factors. Put simply: every 2FA is MFA, but not every MFA stops at two factors. The terms are often used interchangeably in everyday speech, but the distinction matters in security documentation when designing access policies.
How does multi-factor authentication work?
A typical flow has three stages:
- Enrollment — the user ties an extra factor to the account: installing a TOTP app and scanning a QR code that holds the secret, registering a hardware key, or storing biometrics on the device.
- Authentication — after the first factor (usually a password), the system asks for another: a one-time code, approval of a push notification, or confirmation with a security key.
- Access decision — access is granted only once all factors check out; a failed attempt is rejected and may be logged.
What MFA methods exist and how do they differ in security?
- SMS / email codes (OTP) — simple and widespread, but the weakest. SMS can be hijacked through SIM swapping, intercepted in the carrier network (the SS7 protocol), or phished. Better than a password alone, yet not recommended for critical accounts. OTP means one-time password.
- TOTP (Time-based One-Time Password) — time-based one-time codes generated locally in an app (e.g. per
RFC 6238) from a shared secret and the current time, usually every 30 seconds. They need no cellular network and resist SIM swapping, but can still be phished — a user can be tricked into entering the code on a fake site, and the attacker relays it. - Push notifications — you approve a sign-in with one tap in an app. Convenient, but exposed to MFA fatigue: an attacker floods the user with approval prompts, hoping they eventually tap “approve”.
- FIDO2 / WebAuthn security keys — physical keys or passkeys based on public-key cryptography. The authentication is permanently tied to the service domain, so it cannot be phished or replayed on a fake site.
- Biometrics — fingerprint or face, usually checked locally on the device (e.g. in its secure module) without sending the template to a server.
- PKI cards and certificates — certificate-based authentication (smart card, PIV/CAC), also considered phishing-resistant.
What is phishing-resistant MFA?
These are methods that cannot be defeated by luring a user to a fake site or intercepting a code. They include FIDO2/WebAuthn (hardware keys, passkeys) and PKI authentication. Their edge comes from two things. First, they use a cryptographic key pair, and the secret key never leaves the device. Second, they are origin-bound — the browser checks that the site address matches the one the key was registered for. So an adversary-in-the-middle (AiTM) relay — an attacker sitting between the user and the service — fails, because the signature is not valid for the attacker’s domain. CISA describes FIDO/WebAuthn and PKI as the only methods that meet the phishing-resistance bar.
What is adaptive (risk-based) MFA?
Adaptive MFA, also called risk-based authentication, sets the requirements on the fly, based on the session context: location and reputation of the IP address, device type and familiarity, time of sign-in, “impossible travel” (logins from two distant places within a short window), and unusual behavior. Low risk may allow a password alone; elevated risk can force an extra factor or block the attempt. These signals feed risk-scoring engines, which often use machine learning.
What are the common attacks against MFA?
MFA raises the bar a lot, but it is not impossible to bypass. The most common techniques:
- Adversary-in-the-Middle (AiTM) — a rogue server sits between the user and the real service, relays the password and MFA code in real time, then steals the session token (cookie) and keeps going without signing in again.
- MFA fatigue / push bombing — flooding the victim with push prompts until they approve one out of distraction or frustration.
- SIM swapping — hijacking the victim’s phone number at the carrier to intercept SMS codes.
- Session token theft and replay — a stolen authenticated session cookie lets the attacker act without passing MFA.
- OTP/TOTP phishing — tricking a one-time code out of a user on a spoofed page and using it right away.
Most of these techniques (AiTM, OTP phishing, push bombing, SIM swap) do not work against phishing-resistant MFA, because FIDO2 exposes no code that could be relayed and binds the signature to the domain.
Why does MFA matter for monitoring and threat detection?
From a defender’s view, MFA is not only a sign-in safeguard but also a source of data (telemetry) for SOC teams and network monitoring systems. Authentication logs, network traffic, and identity events can reveal signs of abuse:
- bursts of denied push requests to a single user (a push-bombing signal),
- logins from new locations or low-reputation IP addresses, and impossible travel,
- logins using a valid session token without a prior full authentication (a sign of cookie theft or an AiTM attack),
- a sudden change to or removal of MFA factors on an account (a frequent step in account takeover).
Matching authentication events against network telemetry helps catch attacks that got past MFA — stolen-session abuse in particular — and is an essential part of monitoring under a Zero Trust model.
Learn more
- Identity and Access Management (IAM) — IAM defines and controls user access, with MFA adding stronger login verification.
- Zero Trust Architecture — Zero Trust verifies each access request, and MFA helps confirm identity at login.
- BYOD (Bring Your Own Device) — BYOD increases device risk, so MFA helps protect accounts used on personal devices.
