When to use MFA (multi-factor authentication)

Topic: Security basics

Summary

Use MFA wherever a single stolen password or key could cause serious harm: admin accounts, production access, and sensitive data. Learn what counts as a second factor and how to enforce it. Use this when deciding where to require MFA.

Intent: Decision

Quick answer

  • Require MFA for all admin and elevated access, and for any login that can change security settings or access sensitive data. Optional MFA for low-risk internal tools is better than none.
  • A second factor is something you have (phone app, hardware token) or something you are (biometric). SMS is weak; prefer TOTP apps or hardware keys (FIDO2) where supported.
  • Enforce at the identity provider or at the application; do not allow bypass for convenience. Provide recovery codes or backup factors so lockout is rare but account recovery is possible.

Prerequisites

Steps

  1. Identify high-risk access

    Admin consoles, production SSH, cloud root, billing, and any login that can delete data or change permissions should require MFA. Add MFA to SSO or critical apps first.

  2. Choose factor types

    TOTP (authenticator app) or hardware keys are stronger than SMS. Prefer FIDO2/WebAuthn where supported so phishing is harder. Avoid SMS as sole second factor for high-value accounts.

  3. Enforce and document

    Turn on MFA enforcement for the identified systems; do not allow permanent bypass. Document how users enroll and how to recover (backup codes, admin reset) so support can help.

  4. Handle exceptions

    Emergency break-glass may need a controlled bypass; limit who can use it and log its use. For automation, use scoped tokens or keys instead of disabling MFA on a human account.

Summary

Require MFA for admin and sensitive access. Use TOTP or hardware keys rather than SMS; enforce at the IdP or app and provide recovery options. Use this when deciding where and how to add MFA.

Prerequisites

Steps

Step 1: Identify high-risk access

Require MFA for admin, production, billing, and any login that can change security or delete data. Start with SSO and critical apps.

Step 2: Choose factor types

Prefer TOTP or hardware keys; avoid SMS as the only second factor for high-value accounts. Use FIDO2 where supported.

Step 3: Enforce and document

Enable MFA enforcement; do not allow permanent bypass. Document enrollment and recovery (backup codes, reset process).

Step 4: Handle exceptions

Use break-glass only when necessary; log its use. For automation, use scoped credentials, not a human account with MFA disabled.

Verification

MFA is required for all admin and sensitive access; users have a second factor enrolled; recovery process is documented and tested.

Troubleshooting

Users locked out — Use documented recovery (backup codes, admin reset). Automation needs login — Use API tokens or service accounts with scoped access, not a human account.

Next steps

Continue to