MFA: what it protects and what it does not
Use MFA as a strong extra barrier while understanding phishing, approval-fatigue, and session risks.
Start with the situation
MFA makes account takeover harder when a password is stolen, but methods differ and an authenticated session can still be abused.
The decision to make
Enable MFA wherever available, prefer phishing-resistant options for important accounts, and treat every unexpected prompt as a warning.
A practical sequence
- Start with email, password managers, finance, cloud administration, and accounts with elevated privileges.
- Prefer passkeys or FIDO security keys where supported; authenticator codes generally provide a stronger barrier than SMS.
- Check the service, location, and action shown in every prompt. Deny and report a request you did not initiate.
- Store recovery codes securely and review backup methods so they do not become an easier route into the account.
Real-world examples
- A leaked password alone may be insufficient when MFA is required.
- A relayed phishing page may capture a manually entered one-time code.
- Stolen session data may allow access without repeating the login flow.
Common mistakes
- Approving a prompt just to make repeated notifications stop.
- Believing MFA makes suspicious links or devices safe.
- Leaving old phone numbers and unused recovery methods attached to an account.
What to do next
If you approved an unexpected request, review sessions and secure credentials through the official service, then report it.
MFA reduces risk; phishing-resistant MFA reduces more risk, but neither replaces alert handling and session security.
Trusted official references
- NIST
Multi-Factor Authentication
Background guidance on MFA methods and their role in protecting accounts.
View official source - CISA
Require Multifactor Authentication
Practical advice on prioritizing MFA and choosing stronger, phishing-resistant methods.
View official source