Two-Factor Authentication
Login protection requiring two distinct categories of authentication evidence.
Two-factor authentication, or 2FA, protects an account by requiring evidence from two distinct factor categories. These are something you know, such as a password; something you have, such as a security key; or something you are, such as a biometric characteristic. Two passwords do not create two-factor authentication because both are knowledge factors.
Common methods include hardware security keys, passkeys, authenticator-app codes, push approvals, and SMS codes. FIDO2 and WebAuthn authenticators can be phishing-resistant because credentials are bound to the legitimate service domain. Time-based one-time passwords improve protection against password theft but can still be entered into a fake site and relayed by an attacker.
SMS is better than a password alone in many situations, but it relies on the telephone network and mobile account. SIM swaps, number porting, interception, and support manipulation can redirect codes. Push approval can suffer “MFA fatigue” when an attacker sends repeated prompts until the user accepts. Number matching and clear context improve push security but do not make every implementation phishing-resistant.
2FA matters for exchanges, custodians, email, cloud tools, password managers, code repositories, and administrative dashboards. It does not protect self-custodied blockchain assets when an attacker already has the private key or seed phrase. A wallet's PIN or hardware-device confirmation serves a different local security function. Users must protect both online accounts and signing keys.
Recovery can become the weakest path. Store one-time backup codes offline, register an independent backup authenticator, and keep account contact details current. Do not store the only recovery code on the phone it is meant to replace. Organizations should control enrollment, require strong authentication for factor changes, log recovery events, and promptly remove former staff devices.
Enable the strongest supported method, beginning with primary email and financial accounts. Verify login domains, reject unexpected prompts, review sessions, and revoke unused API keys. Keep a tested recovery plan and protect backup factors separately. Never approve a prompt simply because it appears during an attacker-initiated call. Two-factor authentication greatly reduces account takeover from password compromise, but phishing-resistant design, secure recovery, and careful session management determine how well it works against modern attacks.
Frequently asked questions
- For important accounts, prefer phishing-resistant FIDO2 or WebAuthn security keys and properly implemented passkeys. They bind authentication to the legitimate service domain. Authenticator-app codes are useful but can be relayed through phishing. SMS codes are weaker because of number takeover and interception. Use the strongest method each service supports and register a secure backup authenticator.
- Enable it on email, exchanges, custodial wallets, password managers, cloud accounts, domain registrars, source-code hosting, communication tools, and administrator dashboards connected to financial or production systems. Protect email first because it often controls password resets. Review active sessions, recovery methods, API keys, and authorized devices, since 2FA does not remove access already granted through another channel.
- Use a separately stored recovery code or registered backup security key through the service's official recovery flow. Contact verified support only when necessary and expect identity checks. After recovery, remove the lost authenticator, revoke active sessions, review account changes, and enroll a replacement. Never send recovery codes, passwords, seed phrases, or remote screen access to an unsolicited helper.