What Is Multi-Factor Authentication?

A password by itself proves very little. It proves that someone knows a string of characters, not that the person entering it is the legitimate account holder. Passwords get phished, reused across breached sites, and guessed through automated attacks. Multi-factor authentication (MFA) addresses this by requiring more than one category of evidence before access is granted, so that a stolen password does not automatically become a stolen account.

The Three Authentication Factor Categories

Authentication factors are grouped into three categories, and MFA requires drawing from at least two of them:

Something you know is knowledge-based evidence: a password, a PIN, or answers to security questions. This is the most common factor and the most frequently compromised, because knowledge can be shared, stolen, or guessed.

Something you have is possession-based evidence: a hardware token, a mobile device receiving a one-time code, a smart card, or an authenticator app generating a time-based code. An attacker needs physical or logical access to that specific object to use this factor.

Something you are is inherence-based evidence: biometrics such as a fingerprint, facial geometry, or voice pattern. These are tied to the user's physical characteristics rather than to a credential that can be transferred.

When a system requires factors from two or more of these categories, it is practicing multi-factor authentication. Using two passwords, for example, is not MFA because both come from the same category.

NIST Special Publication 800-63B covers digital identity guidelines and defines these factor categories in detail, serving as the foundational standard for how authentication strength is evaluated.

Why One Factor Is Not Enough

The case for MFA is straightforward once you look at how credential compromise actually happens. Phishing campaigns collect passwords at scale. Data breaches expose millions of credentials at once, many of which get reused across other services. Brute-force and credential-stuffing attacks run automated attempts against login endpoints constantly.

All of these attacks target the knowledge factor, specifically the password. If a password is the only gate, then stealing or guessing it opens the door completely. Adding a second factor from a different category forces an attacker to defeat both simultaneously, which dramatically raises the cost and complexity of a successful attack.

CISA identifies MFA as one of the most effective controls an organization or individual can implement to protect accounts. This is not a coincidence. The control works because it addresses the structural weakness of single-factor systems rather than just trying to make passwords harder to guess.

Common MFA Implementations

The most widely deployed MFA methods fall into a few patterns:

SMS one-time codes send a short-lived numeric code to a registered phone number. The user enters the code alongside their password. This is better than a password alone, but SMS carries known weaknesses including SIM-swapping attacks, where an attacker convinces a carrier to transfer a victim's number to an attacker-controlled SIM.

Authenticator apps generate time-based one-time passwords (TOTP) locally on a device, without relying on carrier infrastructure. Apps such as Google Authenticator and Microsoft Authenticator are common examples. Because the code never transits a phone network, this approach is more resistant to SIM-swapping.

Hardware security keys are physical devices that plug into a USB port or communicate over NFC. They implement protocols such as FIDO2 and WebAuthn, which are phishing-resistant by design because the key cryptographically binds its response to the specific site requesting authentication, not just any site claiming to be that service.

Push notifications send an approval request to a registered mobile app. The user approves or denies the request. This is convenient but can be vulnerable to MFA fatigue attacks, where an attacker repeatedly sends push requests hoping the user will approve one to stop the interruption.

What MFA Does Not Solve

MFA raises the barrier, but it does not eliminate risk entirely. A few important limits:

Some MFA methods are phishable. A convincing proxy site can capture both a user's password and the one-time code they enter in real time, then relay them to the legitimate service before the code expires. FIDO2-based hardware keys are specifically designed to be resistant to this attack; most other methods are not.

MFA fatigue is a real attack vector. If an organization uses push-based MFA and an attacker already has the password, they can flood the user with approval requests. Security awareness and rate-limiting controls both matter here.

MFA protects the login event. It does not protect the session after authentication. Session hijacking, token theft, and post-authentication privilege escalation are separate concerns that MFA does not address.

MFA and a Sound Access Control Posture

MFA belongs within a broader access control framework, not as a standalone fix. Pairing MFA with least privilege access, regular access reviews, and strong session management produces a much more defensible posture than any single control in isolation. Authentication verifies identity; what that identity is permitted to do is a separate question answered by authorization policy.

For any system handling sensitive data or providing administrative access, MFA should be treated as a baseline requirement rather than an optional enhancement. The risk reduction it provides is well-documented, and the deployment cost for most modern systems is low relative to the exposure it reduces.