What Is MFA? The Factors, the Methods, and Which Ones Actually Stop an Attack

The attackWhat multi factor authentication is actually protecting

It helps to be concrete about the attack, because the design of every authentication method below is a response to it.

Attackers rarely break encryption. They log in. Credentials leak in their millions from breached services, get sold in bulk, and get replayed against every other service in the hope that someone reused a password, which is called credential stuffing. Other credentials are phished directly, or lifted by malware from a browser password store.

In each case the attacker ends up holding a valid username and password for a real user, and a system that asks for nothing else opens the door with no alarm anywhere, because from the system's point of view this is a normal login.

What that buys them is access, and access is the whole game. A single mailbox gives an attacker the password reset link for every other service the user owns, plus enough internal correspondence to make the next phishing message convincing.

A remote access account gives them a foothold inside the network, which is how a large share of ransomware incidents begin. An administrator account gives them the ability to grant themselves whatever they still lack. The data at risk is whatever those accounts could reach, which in most organizations is far more than the account holder realizes.

Multi factor authentication attacks the economics. Credential stuffing runs at the scale of millions of attempts because each attempt is nearly free.

Requiring a second factor makes every one of those attempts fail, and forces an attacker who wants a specific account to run a targeted operation against a specific person. That is a different activity with a different cost, and most attackers do not bother.

FundamentalsThe three categories, and why the categories matter

Authentication asks a single question: is the user at this login the person the account belongs to. One piece of evidence answers it badly, because any single piece can be stolen. Multi factor authentication answers it with evidence of different kinds, on the theory that one theft rarely captures both.

Something you know is a memorized secret. A password, a PIN, the answer to a security question. It can be guessed, reused, phished, or read out of a breach dump.

Something you have is a physical thing under your control. A phone running an authenticator app, a hardware security key, a smart card, a number that only rings on one handset. It has to be stolen, borrowed, or tricked into producing its output.

Something you are is a biometric. A fingerprint, a face, a voice. In practice this almost never travels to the server. The fingerprint unlocks the key stored on the device, and the device does the authenticating, which is a distinction worth holding on to.

The reason the categories are drawn this way is that attacks tend to work on one category at a time. A credential stuffing attack works entirely inside what you know.

Someone reading a breach dump has millions of memorized secrets and no phones at all. Adding a second item from the same category, a password plus your mother's maiden name, adds nothing against that attacker, because both live in the same place and are stolen by the same means.

So if you are asking what is MFA in one sentence, it is the practice of forcing an attacker to succeed at two unrelated kinds of theft in the same session.

Biometrics are not secrets, and that changes how they are used

A fingerprint or a face scan feels like the strongest factor and is the one most often misunderstood. Three properties decide how it can safely be used.

A biometric is not a secret. You leave fingerprints on everything you touch and your face is public. Anything that treats a fingerprint as a password, something to be presented and compared centrally, is building on a secret that everybody already has a copy of.

A biometric cannot be revoked. A password that leaks is changed in a minute. A fingerprint template that leaks is yours for life, which is why storing biometric data centrally is a liability that grows rather than a risk that passes.

A biometric measures a probability, not an equality. Every reader has a false accept rate and a false reject rate, and tuning one moves the other. There is no setting where both are zero.

This is why sensible designs never send the biometric anywhere. The fingerprint or face unlocks a private key held in secure hardware on the device, and the key does the authentication. The measurement stays on the phone or the laptop, the server never receives it, and a stolen server database contains no biometric data to lose.

When a passkey asks for your face, the face is opening a lock on the device, and the authentication itself is a signature that has nothing to do with your face at all.

The methodsThe methods, ranked by what they actually resist

Every authentication method below is MFA. They are not close to equivalent, and the difference decides how much security you actually bought.

The column that matters is the third one. CISA puts it plainly on its own MFA page: the only widely available phishing resistant authentication is FIDO and WebAuthn, and it urges organizations to plan a move to it. Everything above that line in the table can be handed to an attacker by a user who believes they are logging in.

Phishing resistanceWhy a one time code cannot survive a phishing proxy

The attack that decides this is adversary in the middle, and it is not exotic. Ready made kits automate it.

A user clicks a link and lands on a site that looks like the real login page. It is a proxy. Whatever the user types is forwarded to the genuine service in real time, and whatever the genuine service asks for is shown back to the user.

The user enters a password and it is relayed. The service asks for a one time code and the proxy shows that prompt. The user reads the code from the authenticator app and types it, and the proxy relays it within its thirty second window.

The service is satisfied, issues a session cookie, and the proxy keeps the cookie. The user sees whatever page the attacker chooses to show. The account is now open on the attacker's machine, and no further authentication is needed because the session is already established.

Nothing about that attack cares whether the code came from a text message, an email or an authenticator app. A code is a secret the user can be tricked into repeating, and every method that transmits a repeatable secret fails the same way.

FIDO2 breaks the attack at the cryptography rather than at the user. When a key is registered, it is bound to the origin, meaning the exact domain of the real service.

At login the browser hands the authenticator a challenge along with the origin it is actually talking to, and the authenticator signs the challenge only for the origin it was registered against.

A proxy sitting on a lookalike domain presents a different origin, the signature it needs is never produced, and there is no code for the user to read out and no secret to relay. The user cannot make this mistake, which is the point. Security that depends on a person recognizing a domain name under time pressure is not security.

Push fatigueMFA fatigue, and the fix that costs nothing

Push approval created a second problem. An attacker holding a valid password can request a login repeatedly, and the victim's phone fills with approval prompts.

Some people approve one to stop the noise, some approve one at two in the morning without reading it, and some assume it is a system glitch. Several large breaches began exactly this way, and the pattern is worth reading in full.

Number matching removes the guess. The login screen displays a two digit number and the phone asks the user to type it rather than tap approve. An attacker who is not looking at the victim's screen has nothing to tell them.

If you run push based MFA and have not turned this on, it is the highest value change available today, and it is a settings toggle rather than a project.

The standardWhat the standard actually requires

NIST Special Publication 800-63B defines three authenticator assurance levels, and they are worth knowing because auditors quote them.

Two details in that document surprise people. The first is that the use of the public telephone network for out of band verification is classed as restricted, which is the standard's way of saying it is permitted but discouraged and must be justified.

Codes by text message are the method most organizations start with and the one the reference standard is least comfortable with. The second is that verifier impersonation resistance, which is the formal name for surviving the proxy attack above, appears only at the top level.

The standard agrees with the table: phishing resistance is a property of a few methods, not of MFA in general.

EnforcementWhere authentication is enforced, and why that is one place

Nobody configures multi factor authentication application by application any more, and the reason is arithmetic. An organization with sixty applications and per application settings has sixty places to get the policy right, sixty enrollment experiences for its users, and sixty places for one of them to be missed.

It also has no way to answer the only question that matters during an incident, which is where a given identity has access.

The modern arrangement puts one identity provider in front of everything. Users authenticate once to that provider, it applies the policy, and applications trust the assertion it issues.

This is what people mean by single sign on, and it changes multi factor authentication from a per application feature into a property of the identity itself. Policy is written once, in terms of users, groups, applications and risk, and it takes effect everywhere at the same time.

Two consequences follow, and only one is comfortable. The comfortable one is that raising the standard for a group of users is now a change to one rule rather than a project across sixty systems. The uncomfortable one is that the identity provider becomes the single most valuable target in the estate.

Its own administrators should be on phishing resistant authentication before anybody else, its sign in logs should be monitored rather than merely retained, and the accounts that can change its policy should be few enough to name from memory.

ComplianceWhat forces the decision, in practice

Most organizations do not adopt multi factor authentication because they modeled the threat. They adopt it because someone required it.

Payment card rules. The Payment Card Industry Data Security Standard version 4.0 extended requirement 8.4.2 from administrators to everyone: multi factor authentication for all access into the cardholder data environment, whether the user is remote or sitting on the same network.

That requirement has been in force since March 2025, and it is the single most common reason a small merchant deploys MFA at all.

Cyber insurance. Insurers now ask directly, on the application form, whether MFA covers remote access, administrative accounts and email. Answering no raises the premium or ends the conversation. Answering yes when the coverage has gaps is worse, because the gap tends to be discovered during a claim.

Federal and defense contracting. Frameworks used by contractors carry an explicit multifactor requirement for privileged and network access, and evidence of it is part of the assessment rather than a policy statement.

Health and financial regulators. These generally require access controls proportionate to the sensitivity of the data rather than naming a technology. In practice an auditor reads that as MFA on anything reaching patient or account data, and asks how you decided otherwise if you did.

The useful move here is to treat the requirement as a floor rather than a target. Every one of these regimes is satisfied by the weakest method in the table above, and none of them will stop the phishing proxy.

Meeting the requirement and stopping the attack are two separate pieces of work that happen to start in the same place.

AdaptiveRisk based authentication, and asking only when it is worth asking

Prompting every user on every login is a tax on the whole organization and, worse, it trains people to approve prompts without reading them. Risk based or adaptive authentication is the answer most large deployments settle on: the system scores each attempt and asks for a second factor only when the score warrants it.

The signals are ordinary. Is this device known and compliant. Is the address one the user has used before. Is the location plausible given where they logged in an hour ago. Is the application a low risk internal wiki or the payroll system.

Is the identity one with administrative rights. A login from a managed laptop on the office network to read a document is treated differently from the same user reaching finance data from an unrecognized machine.

Two rules keep this honest. Risk scoring may raise the requirement and should never lower it below a floor, so administrators and sensitive systems always get strong authentication regardless of how routine the attempt looks.

And step up authentication belongs on the action as well as the login: reauthenticate before changing bank details or granting access, because the session that reaches that page may not still belong to the person who started it.

The trade off is real. Every signal that lets the system stay quiet is also a signal an attacker can imitate, and a policy nobody can explain is a policy nobody can audit. Keep the rules few enough to write on one page.

RolloutTurning it on without breaking the business

Rolling multi factor authentication out across a real estate of systems and users fails in the same places every time.

Find the doors that do not ask. Authentication applied at the web login means nothing if older protocols still grant access on a password alone.

Legacy mail protocols are the classic example, and so are virtual private network concentrators, remote desktop gateways, and any application that authenticates against the directory directly. An attacker looks for the one door with no lock, and finding it is not hard.

Decide what happens to service accounts. Accounts that no human uses cannot approve a prompt. They need a different control: certificate authentication, an allowed address range, a managed identity, or a vaulted secret that rotates. Leaving them exempt and forgetting them is how a rollout that reads as complete leaves the crown jewels on one password.

Plan recovery before enrollment. Users will eventually lose the phone or the key. If the recovery path is a help desk call that resets the factor on request, then the help desk is now the weakest link in the whole authentication process, and attackers know it.

Recovery should require identity proofing at least as strong as enrollment, and registering multiple authenticators per user removes most of the problem before it starts.

Keep two break glass accounts. Cloud identity outages and misconfigured policies both lock administrators out of their own tenant. Two accounts excluded from conditional access, with long random passwords in a safe, monitored for any use, are what get you back in. One is not enough, because one can be the one that is broken.

Expect the session, not just the login. MFA authenticates a login and issues a session. Malware on a laptop can steal that session cookie and replay it without ever touching authentication. Shorter session lifetimes for sensitive applications, reauthentication before high risk actions, and device compliance checks are what close it.

PitfallsWhere people go wrong

The most common error is treating multi factor authentication as a binary that is either on or off. It is a range, and the distance between a text message and a security key is larger than the distance between a password and a text message.

Reporting to a board that authentication coverage reached one hundred percent, while every user account relies on text messages, describes a security achievement that a phishing kit undoes in an afternoon.

The second is enrolling only the people who are easy to enroll. Attackers do not target the average user, they target whoever can move money or change access permissions. Administrators, finance staff and executives should be on hardware backed, phishing resistant authentication first, even if the rest of the users take a year.

The third is trusting the reset path less than the login. An account with a security key and a help desk that will disable it on a convincing phone call is protected by the phone call, not by the key.

ComparisonMFA, 2FA, single sign on and passwordless are four different things

These four terms are used interchangeably in procurement documents and mean different things.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Remote access What Is an IPsec VPN? Remote access is where authentication and encryption meet, and IPsec is the encryption half. Open this next11 min

• Addressing · 15 min What Is a Subnet? Putting sensitive systems in their own subnet is what makes an access rule enforceable.
• Containers · 14 min What Is Docker? The Docker daemon is one of the services worth putting behind strong authentication first.
• Remote access · 13 min VPN vs Proxy Neither a proxy nor a VPN stops a password that already leaked.
• Managed IT · 10 min What Is an MSP, and What Are You Actually Buying What the baseline should start with.
• Network security · 14 min What Is a Firewall? Network rules decide who can reach a system. Authentication decides who they are.
• Directory and identity · 15 min Active Directory Explained A directory account is what most authentication is protecting in the first place.
• Identity and access · 13 min Zero Trust Explained Strong authentication is the foundation of the model that replaces the flat network.
• Network security · 12 min IDS vs IPS What watches the network once an account has been taken over anyway.
• Cryptography · 11 min Hash Functions, and Why the Right One Depends on the Job The control that sits alongside password hashing.
• Directory and identity · 13 min Group Policy Explained What enforces the sign in rules on a domain joined estate.
• Cryptography · 12 min Diffie-Hellman Key Exchange The channel your authentication travels over, and how it was secured.
• Managed IT · 11 min What an MSSP Sells, and What Round the Clock Really Costs What the prevention baseline should start with.
• Directory and identity · 13 min LDAP Explained What the second factor is protecting: the directory account underneath.
• Endpoint management · 13 min MDM Explained The other half of the sign in decision, which is the state of the device it comes from.
• Backup · 13 min The 3-2-1 Backup Rule, and What Ransomware Did to It The control that keeps the credentials writing to your backups out of an attacker’s hands.
• Network security · 9 min Cyber Security vs Network Security, and What the Firewall Does Not Cover Why a second factor is the first purchase.
• Remote access · 11 min SSL VPN Explained, and the Reason It Needs Patching First The authentication that makes a stolen VPN password insufficient.
• Network security · 8 min Business Antivirus, and the Two Things It Has to Do Now Why the endpoint cannot answer the credential question.
• Ports · 10 min Port 22, and Why Changing It Is Not the Fix People Think What sits behind the key, once passwords are off.
• Identity and access · 8 min Conditional Access, and the Policy That Locks Out the Person Who Wrote It The engine that decides when to require it.
• Ports · 9 min The RDP Port, and Why It Should Not Be the One Facing the Internet The service that most often needs it, because credentials for it are bought and sprayed.
• Identity and access · 10 min IAM vs PAM, and What PAM Looks Like Without a PAM Suite What identity and access management covers, and the stricter controls admin accounts need on top of it.
• Identity and access · 12 min CyberArk vs HashiCorp Vault Where the privileged accounts that MFA protects go next: vaulted, rotated and recorded.