A leaked password does not have to become a lost account. Multifactor authentication, or MFA, adds a check beyond the password and reduces the value of a stolen credential. It is an important layer, but works best as part of an identity protection routine — and not every MFA method offers the same protection.
This article explains what distinguishes one method from another, how to choose from available options, and what to do when something seems wrong.
What the factors verify
Generally, factors combine something you know, something you have, or something you are. A password is knowledge; an authenticator app or security key can represent possession; a biometric feature can support verification on a device.
The important part is not memorizing the classification. It is knowing that two factors reduce the chance that a single compromised piece of information will be enough to enter an account.
But one distinction matters more than the factor count: whether the method resists phishing. NIST defines phishing resistance as the protocol’s ability to prevent authentication secrets from being handed to an impostor verifier — without depending on the person’s attention. The definition is deliberately demanding: it does not accept “the user will notice the fake site” as a control.
The practical consequence is direct. NIST states that authenticators involving manually entering a code — including app OTPs and out-of-band codes — cannot be considered phishing-resistant. If you type a number into a screen, you can type it into the wrong screen.
How the methods compare
Ordered from strongest to weakest:
| Method | Phishing-resistant? | Main limitation |
|---|---|---|
| FIDO2 security key / passkey | Yes | Requires service support; physical device cost |
| Push with number matching | No | Reduces approval fatigue, but the code can still be entered |
| Authenticator app code (TOTP) | No | Can be entered into a fake website |
| Simple “approve/deny” push | No | Vulnerable to notification bombing |
| SMS code | No | Subject to SIM swapping and carrier protocol weaknesses |
Security keys and passkeys resist phishing because they bind the credential to the site’s actual address. If you are on banco-seguro-login.com instead of the legitimate domain, the key simply does not respond — there is no code to steal, and protection does not depend on you noticing the difference in the address.
SMS deserves a separate note. NIST classifies use of the telephone network for out-of-band authentication as a restricted authenticator: services accepting it must offer an alternative and warn about the risks. The reason is that the code can be diverted through SIM swapping — when someone persuades the carrier to transfer your number to another SIM — or through weaknesses in signaling protocols between carriers.
This does not mean disabling SMS when it is the only option. SMS MFA protects far more than having no MFA. It means preferring another method when the service offers one, and avoiding SMS on the account that recovers all the others.
Choose the most resistant method available
Assess what the service offers, store recovery codes somewhere safe, and register more than one recovery method when allowed. Registering two methods prevents a lost device from becoming a lost account.
Never approve an MFA request you did not initiate. Repeated notifications are a known technique: CISA calls it push bombing, an attack in which someone is bombarded with notifications until they approve one by mistake or out of irritation at the endless stream. The attacker already has the password — only your confirmation is missing.
The defense is a simple rule with no exception: a notification you did not initiate always means “deny”. If notifications continue, that confirms your password has leaked; change it through the service’s official address, not through a notification link.
For organizations that cannot yet adopt phishing-resistant methods, CISA recommends number matching as an interim measure: instead of an “approve” button, the service shows a number on the login screen that you must enter in the app. This does not prevent phishing, but eliminates accidental approval — you cannot reflexively approve a request whose number you cannot see.
Protect account recovery
The recovery process is as important as login. Strong MFA protects nothing if resetting the password only requires answering which city you were born in.
Your primary email needs a unique password and MFA because it often receives password resets for other services. Predictable security questions and public information weaken this path — when forced to use them, treat the answer as another password and store it in your manager rather than answering truthfully.
Use a password manager to create different credentials for each service. This limits a leak’s effect: a password used on one website does not automatically open the others. The failure mode a manager eliminates is the most common of all — the same password reused across twelve services, exposed when one is breached.
Store recovery codes outside the manager that depends on the account they recover. Printed on paper or kept in a second vault, they resolve the circular dependency of keeping the key behind the door it opens.
Respond calmly to a login notice
When you receive an unfamiliar login notification, do not click its link directly — fake “suspicious access” notices are common bait precisely because they create urgency.
A sequence that works:
- Open the service through its official address or app, typing the address yourself.
- Check active sessions and end any you do not recognize.
- Change the password if there is any sign of compromise.
- Check registered MFA and recovery methods — an attacker with access often adds their own. An unfamiliar method is a stronger signal than the original notification.
- Review forwarding rules if it is an email account.
- For a corporate account, notify the responsible team through the organization’s defined channel, even if it seems like a false alarm.
The order matters: changing the password before removing improper access may simply notify the attacker that they have been noticed.
Checklist for an important account
- a unique, long password stored in a manager;
- MFA enabled with the strongest method the service offers;
- recovery codes stored outside the manager;
- at least two registered authentication methods;
- a recovery email also protected by MFA;
- sessions, devices, and forwarding rules reviewed periodically;
- login alerts enabled when the service offers them;
- no verification code shared by message or phone — no legitimate service asks for this.
Account protection is an ongoing practice. The best time to configure recovery and MFA is before you need them.
Prioritize the account that recovers the others
Do not give every account the same effort. Start with primary email and services managing payments, domains, work, or files: they allow access resets for other systems.
A practical way to prioritize is to ask: if someone enters this account, how many others can they open from it? Primary email usually gives the most alarming answer — and is where a security key first pays off.
For these accounts, the extra effort is worthwhile: a phishing-resistant method, two registered authenticators, recovery codes on paper, and periodic session reviews.
Next step
Choose one account — probably your primary email — and do this today: check the strongest MFA method it offers, register a second method, and review the list of active sessions and registered factors. Ten minutes can change the outcome of a future leak.
Then agree on a procedure with yourself: if an alert looks strange, pause, open the service through a known address, and check sessions. Account security is not about responding faster to a notification; it is about having a reliable way to verify before approving any action.
