Stop Choosing Passwords: Build a Phishing-Resistant MFA Stack

You think your MFA is good enough because you use an authenticator app? Wrong. If that app generates a six-digit code you type into a login form, you're still one convincing phishing page away from a breach. The gold standard, according to CISA, is phishing-resistant MFA — and you should be moving toward it now (CISA Phishing-Resistant MFA).

This is for you if you're an IT admin, security engineer, or small-business owner who's responsible for access control but isn't a full-time identity architect. I'll walk you through five steps to harden your authentication stack, from inventorying what you have to enforcing a zero-trust posture. It's not a theory lecture — it's a practical to-do list. You'll come out with a clear path, and I'll warn you where it can blow up.

Step 1: Inventory Your Current Authentication Methods

Before you can fix anything, you need to know what you're dealing with. List every application and system that requires login. For each, note the authentication factors: something you know (password), something you have (phone or token), or something you are (biometrics). NIST recognizes these three factor categories (NIST SP 800-63B). If any system uses only a password, that's your first red flag.

Also check whether you're using single sign-on (SSO). If not, you're forcing users to juggle multiple credentials, which drives password reuse and fatigue — CISA explicitly recommends SSO to reduce that (CISA SSO). If you have SSO, great, but remember that SSO is only as strong as the authentication at the identity provider. A weak password plus SSO is still weak.

What can go wrong: You'll find a legacy app that doesn't support modern protocols. Don't panic — you can put it behind a gateway that enforces MFA before it even reaches the app.

Step 2: Choose Your Phishing-Resistant MFA Methods

Now it's time to pick your weapons. CISA identifies two types of phishing-resistant MFA: FIDO/WebAuthn and PKI-based (like PIV/CAC cards). FIDO/WebAuthn is the only widely available phishing-resistant option, and it's built into modern laptops and phones as platform authenticators (CISA Phishing-Resistant MFA). Passkeys are a prime example — they're FIDO2-based, use origin-bound public-key cryptography, and require local user interaction, making them nearly impossible to phish (Microsoft FIDO2 Passkeys (Entra ID)).

Here's how passkeys work: your device stores a private key, and the site has your public key. On sign-in, the device signs a challenge with the private key, and the site verifies the signature. No password is ever sent (Microsoft Passkeys). Each passkey is bound to the specific domain it was created for, so a passkey for your bank won't work on a look-alike phishing site (Microsoft Passkeys). That's the phishing resistance.

Passkeys also count as MFA because they require something you have (the device) plus something you are (biometric) or something you know (PIN) (Microsoft Passkeys). So you can satisfy AAL2 — which requires two distinct factors — with a single passkey. NIST recommends AAL2 for most systems handling personal, financial, or operational data (NIST SP 800-63B). That's your target.

Step 3: Enforce MFA and Conditional Access

You can't just offer MFA; you have to require it. Use a policy engine like Microsoft Entra Conditional Access or similar. Conditional Access is an if-then engine: if a user wants to access Microsoft 365, then they must perform MFA (Microsoft Conditional Access). You can base decisions on signals like user group, location, device state, and sign-in risk, then block or grant access with requirements (Microsoft Conditional Access).

Start with a baseline policy that requires phishing-resistant MFA for all users. Then add risk-based policies: for example, require re-authentication after 30 minutes of inactivity, as NIST suggests for AAL2 (NIST SP 800-63B). Also, implement rate limiting on login attempts to prevent brute force — NIST requires verifiers to limit failed attempts (NIST SP 800-63B).

If you're in the federal space, you're already under an executive mandate: OMB M-22-09 required agencies to adopt phishing-resistant MFA by the end of fiscal year 2024 (OMB M-22-09). Even if you're not federal, that's a good deadline to copy.

Step 4: Apply Least Privilege and Privileged Access Management

Authentication is only half the battle. After someone proves who they are, you must limit what they can do. The principle of least privilege says grant only the minimum access needed for the job (Tenable). Use RBAC as your baseline — assign permissions to roles, not individuals (Tenable). The ANSI INCITS 359 RBAC standard defines Core RBAC as the mandatory minimum (NIST RBAC (INCITS 359)).

For privileged accounts — those with elevated access, the 'keys to the kingdom' — implement Privileged Access Management (PAM). PAM includes credential vaulting, just-in-time access, session monitoring, and MFA for privileged sessions (NIST PAM). Tools like Microsoft Entra PIM give you time-based and approval-based role activation, so users only get elevated access when they need it, and only for a specific window (Microsoft PIM).

In cloud environments like AWS, remember that access is denied by default; you explicitly grant permissions via IAM policies (AWS IAM). And for cross-account access, use roles with trust policies — don't share long-term credentials (AWS IAM Roles).

Step 5: Move Toward Zero Trust, One Step at a Time

Zero trust isn't a product; it's a mindset. NIST defines it as moving defenses from static network perimeters to focus on users, assets, and resources (NIST SP 800-207). The core idea: no implicit trust based on network location. Access is granted per-session, based on dynamic policy that considers the user, device, and environment (NIST SP 800-207).

You don't have to rebuild everything overnight. Start by treating every access request as if it comes from an untrusted network. Use conditional access to require MFA every time, not just from external IPs. Segment your network so that even if one machine is compromised, the blast radius is limited. And most importantly, stop relying on passwords — move to passkeys or other phishing-resistant methods.

Here's a comparison to help you choose your direction (Cisco Duo):

Most organizations use RBAC as a baseline and layer ABAC for context-aware decisions (Cisco Duo). That's a pragmatic path.

Sources

• CISA Phishing-Resistant MFA - https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• Microsoft Passkeys - https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter
• NIST SP 800-63B - https://pages.nist.gov/800-63-3/sp800-63b.html
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• Microsoft Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• Cisco Duo Access Control Models - https://duo.com/learn/access-control-models