What it means
Multifactor authentication combines different kinds of evidence, commonly something you know, something you possess, or something you are. A password and another password do not provide different factors. Some authenticators combine factors within one device, such as a cryptographic key that requires local activation with a PIN or biometric check.
Methods differ in what they resist. A one-time code can be relayed through a convincing fake sign-in page, and an unexpected approval prompt can pressure someone into accepting. Phishing-resistant cryptographic methods bind authentication to the legitimate verifier. MFA improves sign-in assurance but does not repair excessive access or automatically protect an already stolen session.
See the idea / Identity
How a password and security key sign you in.
Two different factors. Follow one login from password to signed-in page.
Your key is already enrolled. The website has its public key; the private key stays in the hardware.
01 / 06
Submit
Your browser sends your username and password to the website over HTTPS.
Your password passed. Try the second factor.
More about this step
You enter your username and password. The browser sends them over HTTPS to the website’s login service. This example assumes your security key is already enrolled.
Step through at your own pace.
Keep in mindThis example uses a password and a USB security key. Touch confirms presence, not a biometric or a third factor. Other MFA methods have different flows.
Read the visual, step by step
- Submit. Your browser sends your username and password to the website over HTTPS. You enter your username and password. The browser sends them over HTTPS to the website’s login service. This example assumes your security key is already enrolled.
- Password. The website checks your password. One factor has passed; you still need the key. The login service verifies the password for this account. It records that result for this login attempt, but the required security-key check is still pending. You are not signed in yet.
- Challenge. The website creates a fresh challenge for this login. Your browser asks the enrolled key to respond. The service creates a fresh challenge tied to this login attempt. The browser requests a response from the enrolled security key for this website. The password is not sent to the key. A7 is an illustrative label for this login, not an actual challenge value.
- Respond. Touch the key. It signs proof for this login and website; your browser returns that proof. You touch the key to confirm your presence. It signs a response bound to the challenge and website, proving possession of its private key. The private key stays inside the hardware; the browser sends the signed response to the service.
- Verify. The website checks the login, website identity, signature, and required authenticator flags before accepting the proof. The service checks the response against the account’s enrolled public key, expected challenge, website origin and relying-party identity, and required authenticator flags. Only a valid response completes the second-factor check for this login attempt.
- Session. Both factors passed. The website returns a session cookie, then your browser shows the signed-in page. After both required checks succeed, the service establishes an authenticated session and returns its session cookie over HTTPS. The browser shows the signed-in page. The application still checks permission for each protected action.
Password only
- Submit. Your browser sends your username and password to the website over HTTPS.
- Password. The website checks your password. One factor has passed; you still need the key.
- Challenge. The website creates a fresh challenge for this login. Your browser asks the enrolled key to respond.
- Incomplete. The password passed, but the key never responded. Sign-in remains incomplete; no authenticated session is issued. Without a valid response from the enrolled key, this login cannot complete. Recovery is a separate protected process, not an automatic bypass.
This example uses a password and a USB security key. Touch confirms presence, not a biometric or a third factor. Other MFA methods have different flows.
Flow references: W3C WebAuthn: verifying an authentication assertion · NIST: authentication and authenticators
AN ILLUSTRATIVE SCENARIO
A retailer administrator account
A retailer requires stronger authentication for staff who manage its online store. It tests a security-key-based method, enrolls a protected backup authenticator, and documents recovery for a lost key. The rollout includes supplier accounts and alternate administration pages rather than only the main sign-in screen. Staff are taught to report unexpected prompts. The team then checks whether existing sessions and recovery channels could bypass the intended protection.
Put it to work
- Identify the factors and phishing resistance of the actual method, rather than relying on the label “MFA” in a product setting.
- Prioritize high-impact accounts, cover every relevant sign-in path, and plan secure enrollment, replacement, recovery, and emergency access.
- Test rejection when a required factor is missing, verify recovery controls, and monitor enrollment changes and suspicious authentication activity.
How to check your work
With a test account, confirm that possession of the password alone is insufficient and that alternate paths enforce the intended assurance. Document exceptions and demonstrate how a lost authenticator is revoked.
Connect the ideas
- Authentication
The act of verifying a claimed identity with authenticators such as passwords, passkeys, or certificates.
- Phishing
Social engineering that tricks a person into revealing authenticators or approving a transaction they did not intend.
- Account recovery
The process for restoring account access when required authenticators are unavailable, using an approved recovery method.
- Session
State linking multiple requests; an authenticated session associates later requests with a previously authenticated identity until it expires or is revoked.