Your Authentication Stack

A password alone is a screen door in a hurricane. You know this. The question isn’t whether to deploy MFA — it’s how to deploy it properly, which factors to choose, how to handle the edge cases that trip everyone up, and how to deal with the service accounts and legacy systems that resist modern authentication. This is the practical playbook. Not theory — settings, tools, and the specific decisions you need to make to get your authentication stack from “we have MFA on some things” to “every authentication path is covered.”

DO / DON’T

DO:

• Enable MFA on every account that supports it — personal and professional
• Prefer FIDO2 hardware keys (YubiKey, Titan) or passkeys over TOTP apps
• Use TOTP apps (Aegis, Ente Auth, Microsoft Authenticator) over SMS
• Register backup authentication methods for every account
• Audit all service accounts for authentication strength
• Use a password manager for unique, random passwords on every account
• Enable phishing-resistant MFA for high-value accounts (email, banking, cloud admin)

DON’T:

• Use SMS-based 2FA as your primary factor if any alternative exists
• Store TOTP seeds in the same password manager as your passwords (that collapses two factors into one)
• Skip MFA on “low-value” accounts — attackers use them as stepping stones
• Share MFA devices or backup codes with others
• Leave recovery codes in an unencrypted file on your desktop
• Assume MFA makes you immune to phishing — only FIDO2/passkeys are phishing-resistant
• Blindly approve push notifications — always verify the context before tapping “Approve”

Choosing Your MFA Factors

Not all second factors are created equal. Here’s the hierarchy, from strongest to weakest.

FIDO2 Hardware Keys (Best)

What: A physical device (YubiKey 5 Series, Google Titan, Feitian) that uses public key cryptography bound to the site’s origin. The private key never leaves the device.

Why it’s best: Phishing-proof by design. The key cryptographically verifies the site’s domain — if you’re on a phishing site, the key refuses to authenticate. Google deployed YubiKeys to 85,000+ employees and reported zero successful phishing attacks afterward.

Setup:

• Buy at least two hardware keys. One primary, one backup. Store the backup securely (safe, safety deposit box).
• Register both keys on every account that supports FIDO2/WebAuthn: Google, Microsoft, GitHub, AWS, Cloudflare, Facebook, Twitter/X, 1Password, Bitwarden.
• On accounts that support it, set the hardware key as the only allowed factor (disable fallback to SMS or TOTP).

Cost: $25-$55 per key. For the security they provide, this is the best money you’ll spend.

Passkeys (Excellent)

What: FIDO2 credentials stored in your device’s secure enclave (TPM, Secure Enclave) and optionally synced across devices via iCloud Keychain, Google Password Manager, or third-party managers.

Why they’re excellent: Same phishing resistance as hardware keys, with better usability. Authentication uses biometrics (Face ID, fingerprint) or device PIN. No code to type. Nothing to carry.

Setup:

• Enable passkey support on accounts that offer it: Google, Apple, Microsoft, Amazon, GitHub, PayPal, and a growing list.
• Use your device’s native passkey provider (iCloud Keychain on Apple devices, Google Password Manager on Android/Chrome) or a third-party password manager that supports passkeys (1Password, Bitwarden, Dashlane).
• Always register a backup method — a second device or a hardware key — in case your primary device is lost.

TOTP Apps (Good)

What: Time-based one-time passwords generated by an authenticator app. A new 6-digit code every 30 seconds.

Why they’re good: They work offline, can’t be SIM-swapped, and don’t traverse the phone network. Available for virtually every service that supports MFA.

Setup:

• Install a dedicated authenticator app: Aegis (Android, open source), Ente Auth (iOS/Android, open source, end-to-end encrypted), or Microsoft Authenticator. Google Authenticator works but lacks encrypted backup.
• When enabling TOTP, save the QR code / seed phrase in a secure, offline backup. If you lose your phone and don’t have the seed, you’re locked out.
• Consider keeping your TOTP seeds in a separate system from your passwords. If your password manager stores both your password and your TOTP seed, a compromise of the password manager compromises both factors.

Push Notification Fatigue (MFA Bombing)

What: An attacker who already has your password triggers MFA push notifications repeatedly — dozens of them, often at 2 AM — hoping you’ll tap “Approve” just to make it stop. This is called MFA bombing or push fatigue.

Real-world example: In the 2022 Uber breach, an attacker spammed an employee with MFA push requests for over an hour, then contacted them on WhatsApp posing as IT support, saying “just approve the prompt and it’ll stop.” The employee approved. The attacker had full access.

How to defend against it:

• Enable number matching (also called “verified push”) on your MFA provider. Instead of just tapping “Approve,” you’re shown a two-digit number on your login screen and must enter it in the push notification. An attacker can’t give you that number because they don’t control your screen.
• Never approve a push you didn’t initiate. If you get an unexpected MFA prompt, someone has your password. Don’t approve — go change your password immediately.
• Report repeated prompts. If you’re getting MFA-bombed, report it to your security team (work) or the service provider (personal). This is an active attack.
• Prefer FIDO2/passkeys over push-based MFA. Hardware keys and passkeys are immune to this attack entirely — there’s nothing to “approve.”

Microsoft Authenticator, Duo, and Okta all support number matching. If your organization uses push-based MFA, verify that number matching is enabled — it should be the default, not an opt-in.

SMS (Better Than Nothing, But Barely)

What: A verification code sent to your phone number via text message.

Why it’s weak: Vulnerable to SIM swapping (an attacker social-engineers your carrier to transfer your number), SS7 network interception, and phishing (you’ll type the code into a fake site just as easily as a real one). NIST SP 800-63B classified SMS as a “restricted” authenticator back in 2017.

What to do: If SMS is the only MFA option a service offers, use it — it’s still better than no MFA. But actively push to migrate to TOTP or FIDO2. Call your carrier and add a PIN/passphrase to your account to make SIM swapping harder.

Locking Down Critical Accounts

Some accounts deserve more attention than others. Prioritize these.

Email

Your email account is the skeleton key. Password resets for almost every service go through email. If an attacker controls your email, they control your ability to recover every other account.

• Enable the strongest MFA available (hardware key or passkey).
• Review connected apps and revoke anything unnecessary.
• Enable suspicious activity alerts.
• For Google: enroll in Advanced Protection Program if you’re a high-risk target.

Cloud Infrastructure (AWS, Azure, GCP)

• Root/owner accounts: Hardware key MFA. No exceptions. These accounts can delete your entire infrastructure.
• IAM admin accounts: FIDO2 or TOTP minimum.
• Enforce MFA via policy. AWS IAM policies can require MFA for sensitive operations. Azure Conditional Access can require MFA based on risk level. GCP supports MFA enforcement via organization policy.

Password Manager

Your password manager vault contains every credential you own. Protect it accordingly.

• Use a strong, unique master password (20+ characters, randomly generated passphrase).
• Enable MFA on the password manager account itself — FIDO2 preferred.
• Enable biometric unlock for convenience, but understand that biometrics unlock the local vault, not the account. Your master password is still the root of trust.

Auditing Service Accounts

Service accounts are the blind spot. They’re often excluded from MFA policies, use static passwords, and have elevated permissions. This is where you find the gaps attackers exploit.

• Inventory every service account. Document what each one does, what it has access to, and how it authenticates.
• Migrate to certificate-based or OAuth2 client credentials authentication where the service supports it. Eliminate password-based service account auth wherever possible.
• For service accounts that must use passwords: vault the credentials (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), rotate automatically, and monitor for usage anomalies.
• Disable interactive login on service accounts. They shouldn’t be logging in through a browser or console.

CISA’s MFA guidance and NIST SP 800-63B are the authoritative references for authentication strength requirements.

If It Already Happened

If you suspect an authentication compromise — unauthorized logins, MFA prompts you didn’t initiate, or password reset emails you didn’t request:

1. Change the password immediately from a trusted device. Use a new, unique password from your password manager.
2. Revoke all active sessions. Most services have a “sign out of all devices” option. Use it.
3. Review and re-register MFA factors. Remove any MFA devices or phone numbers you don’t recognize. Re-register your legitimate factors.
4. Check recovery options. Verify that recovery email addresses and phone numbers are yours.
5. Review account activity logs. Look for unauthorized access, forwarding rules (email), connected apps (OAuth), or API key creation.
6. Check for downstream compromise. If your email was compromised, check every account that uses that email for password resets. If a cloud admin account was compromised, audit the entire environment for persistence mechanisms — new accounts, modified policies, deployed backdoors.
7. Report it. If this is a work account, notify your security team immediately. If it’s a personal account, file an IC3 report for financial accounts.

The single best thing you can do right now: open your password manager, sort by accounts without MFA, and start enabling it. Work down the list. Every account you protect is one less credential an attacker can stuff, spray, or phish.