Multifactor authentication

More evidence, with different strengths

Multifactor authentication, usually called MFA, uses more than one category of authentication evidence. Common categories are something you know, something you have, and something you are. A password plus another password is still knowledge; it does not become two factors because there are two screens.

The categories are only the beginning of an evaluation. The mechanism matters: an approval prompt, a one-time code, and a public-key authenticator can resist different attacks. Authentication explains the surrounding identity and session process; MFA strengthens part of that process rather than replacing every other control.

A stolen password meets a second requirement

Imagine a fictional employee, Dev, accidentally reuses a password from another service. An attacker learns it and attempts to sign in to Dev's work account. If the work service requires an additional authenticator, possession of the password alone may be insufficient.

Now suppose the service sends Dev repeated approval prompts. Dev is not signing in, but the prompts become distracting. Approving one to make them stop could authorize the attacker's attempt. The extra step helps only when its behavior and the user's decision support the intended security boundary.

Dev should use the established reporting channel for unexpected prompts. The organization needs a process that investigates them rather than treating all denied prompts as harmless noise.

Why phishing resistance is a separate question

A fake login page can ask someone to type both a password and a current one-time code. Some attacks relay those values to the genuine service while they remain valid. Multiple factors are present, yet the person has supplied them through the wrong interaction.

Phishing-resistant authentication binds the authentication to the legitimate service in a way that a lookalike page cannot simply reuse. Passkeys and WebAuthn explains the WebAuthn approach. This does not mean every security key is configured the same way or that a compromised endpoint cannot cause harm.

Evaluate enrollment and replacement

Imagine Dev loses the device used for authentication. The recovery process now becomes an alternate route into the account. If a caller can replace the authenticator using publicly available biographical details, the ordinary MFA requirement can be undermined.

For a product review, map how a new method is added, how changes are notified, which methods are allowed as fallback, and who can approve an exceptional reset. Secure account recovery develops this part of the lifecycle. Plan legitimate recovery before users are locked out.

A useful comparison exercise

Create a table for three fictional methods: password plus texted code, password plus approval prompt, and a correctly implemented passkey requiring user verification. Compare what happens after password disclosure, a misleading request, and loss of the authenticator. State any assumptions instead of declaring one method universally unbreakable.

Finally, ask what happens after successful sign-in. A stolen active session may avoid the original authentication challenge. Sessions and cookies covers those credentials. The practical aim is a coherent account lifecycle: stronger sign-in, protected replacement, understandable user prompts, and a response route when evidence suggests misuse.