What MFA security measures do (and what they don’t)

Multi-factor authentication (MFA) adds extra proof before an account login is accepted. Instead of relying on a single secret (like a password), MFA asks for two or more independent “factors,” typically drawn from:

  • Something you know (a password or PIN)
  • Something you have (a phone, hardware security key, authenticator app)
  • Something you are (biometrics such as fingerprint or face)

The security goal is to make it harder for an attacker to successfully log in even if one factor is compromised.

A key limitation: MFA is not automatically “phishing-proof.” If an attacker can trick a user into approving a login (for example, via push notifications) or relay authentication in real time, the attacker may still succeed. MFA also won’t fix weak account recovery flows (for example, recovery processes that allow an attacker to reset factors).

How MFA typically works in practice

While implementations differ, MFA generally follows this pattern:

  1. The service receives login credentials.
  2. After the first factor succeeds (or sometimes even if it fails, depending on risk), the service requests a second factor.
  3. The second factor is verified using one of several mechanisms:
    • Time-based one-time codes (TOTP) from an authenticator app
    • Push approvals sent to a device
    • One-time codes delivered via SMS or email
    • Cryptographic challenge/response from a hardware security key
    • Biometric verification that unlocks a local credential

A practical way to think about it: MFA can strengthen authentication, but the overall protection depends on which factor types the system supports and how the service handles sessions, recovery, and suspicious login detection.

Best practices: safer factor choices and safer configuration

Prefer phishing-resistant factors where available

When choosing MFA methods, prioritize those designed to resist real-time phishing and interception. In many setups, hardware security keys and other phishing-resistant approaches provide stronger protection than “code only” or “approval only” flows.

If your only options are weaker methods, you can still improve security by:

  • Avoiding SMS where possible
  • Using authenticator apps for TOTP instead of relying solely on messages
  • Ensuring push approvals require explicit, intentional user action

Many account takeovers happen during recovery, not during the initial login. Treat recovery as part of MFA security:

  • Ensure recovery channels require the same (or stronger) verification as the login itself.
  • Use recovery codes only when securely stored offline or in a controlled place.
  • Avoid linking recovery to easily hijacked channels (like an inbox that lacks its own strong protections).

Protect the MFA device and its notifications

If you use a phone or authenticator app, MFA security depends on that device:

  • Keep the device secured with a strong lock screen.
  • Update operating system and authenticator app regularly.
  • Reduce the chance that someone can approve prompts without your awareness (for example, by reviewing notification behavior).

Don’t accept “remembered devices” blindly

Many services offer “trusted devices” or “remember this browser.” This can lower friction, but it also creates a window where compromise is easier:

  • Review which devices are trusted.
  • Remove old or unknown trusted devices.
  • Understand how long trust lasts and what changes trigger re-verification.

Differences and limits you should explicitly account for

Phishing-relay and approval fatigue

MFA can fail in scenarios where an attacker can interact with the authentication flow in real time. Examples include:

  • Trick the user into approving a push authentication
  • Relay authentication attempts so that the second factor is accepted by the service

This is why factor type matters. Even with MFA enabled, “approval fatigue” and real-time relays can reduce practical protection.

SMS/email vs authenticator apps vs security keys

Not all second factors have equal security properties:

  • SMS can be vulnerable when phone numbers or messaging channels are compromised.
  • Email-based codes inherit the security of the email account.
  • Authenticator apps (TOTP) remove dependence on carrier messaging but can still be affected if the phone is compromised.
  • Security keys are designed around cryptographic authentication, typically offering stronger resistance to certain phishing patterns.

The exact strength depends on your provider’s implementation, so you should verify what methods are supported and how they behave during suspicious logins.

Session security still matters

Even perfect MFA can be weakened after login if sessions are too permissive:

  • Long session lifetimes without re-checking factors
  • Weak controls around location, device, or unusual activity
  • Lack of rate limiting on repeated attempts

Think of MFA as one layer. Good security requires complementary protections.

Practical use: checks you can perform without assumptions

Use these concrete checks to validate MFA effectiveness in your environment:

  • Check your MFA methods: ensure you are using the strongest available factor types for your account.
  • Review recovery options: confirm recovery requires strong verification and that recovery codes are stored securely.
  • Audit trusted devices: remove unknown entries and check how long trust persists.
  • Test real behavior: try a controlled login attempt to confirm that the second factor is actually required in the scenarios you expect.
  • Monitor alerts: verify that the service notifies you of important events like new device sign-ins or MFA changes.
  • Watch for bypass conditions: if you notice that MFA is not requested after certain changes (e.g., password resets or device changes), treat that as a security question to understand.

Red flags to watch for

If MFA is enabled, be alert to signs of misconfiguration or risky defaults, such as:

  • Recovery that does not require verification matching the login strength
  • MFA that relies only on easily compromised channels
  • Frequent “trusted device” approvals without clear controls

What to do if MFA is already enabled

If you already turned on MFA, improvement is often about tightening the configuration rather than switching labels. Start with the areas most tied to real-world takeover:

  1. Verify the factor types you rely on.
  2. Harden and audit recovery.
  3. Review trusted devices and session behavior.
  4. Confirm monitoring and alerts.

Because services vary, treat your account settings as the source of truth and re-check them whenever you change phones, switch email providers, or update security preferences.