Ditch Passwords: Phishing-Resistant MFA Is Your Only Real Option

You've typed your password into a fake login page, haven't you? Maybe not, but someone in your organization has. And that's the problem. Passwords are the weakest link in your access control chain. The fix isn't another password policy—it's phishing-resistant MFA. This is for IT admins and security pros who are tired of band-aids and want to actually stop credential theft.

Who This Is For and Why You Should Listen

If you're responsible for authenticating users across your apps and infrastructure, this is your playbook. I'm not going to sugarcoat it: if you're still relying on SMS codes or push notifications, you're one phishing campaign away from a breach. CISA calls phishing-resistant MFA the 'gold standard' of multi-factor authentication and urges organizations to implement it as part of Zero Trust principles (CISA Phishing-Resistant MFA). That's not hyperbole—it's the standard you should hold yourself to.

Step 1: Understand Why Traditional MFA Fails

MFA was supposed to save us, but not all MFA is equal. CISA points out that some forms are vulnerable to phishing, 'push bombing' (MFA fatigue), SS7 exploits, and SIM swap attacks (CISA Phishing-Resistant MFA). That one-time code sent via SMS? Interceptable. That push notification you blindly accept? Fatigue attacks. The only widely available phishing-resistant authentication is FIDO/WebAuthn, which uses origin-bound public-key cryptography and requires local user interaction (CISA Phishing-Resistant MFA).

The other phishing-resistant option is PKI-based MFA, like the U.S. government's PIV card or the military's CAC (CISA Phishing-Resistant MFA). These are hardware-bound certificates, but they're not as easy to deploy for most organizations.

Step 2: Choose Your Phishing-Resistant Method

Your move is to go with passkeys, which are built on FIDO2/WebAuthn. A passkey is a cryptographic key pair: the private key stays on the user's device, and the public key is registered with your site. On sign-in, the device signs a challenge, and the site verifies it—no password is ever sent (Microsoft Passkeys). Passkeys are phishing-resistant because they're bound to the specific domain they were created for, so a passkey made for yourbank.com won't work on yourbank.evil.com (Microsoft Passkeys).

Even better, passkeys double as MFA because the user must have the device (something you have) and unlock it with a biometric or PIN (something you are or know) (Microsoft Passkeys). That's two distinct factors, satisfying NIST's AAL2 requirement for multi-factor authentication (NIST SP 800-63B).

Step 3: Plan for Device-Bound vs. Synced Passkeys

You need to decide between device-bound passkeys, which stay only on the device where they were created, and synced passkeys, which live in a cloud credential manager like Microsoft Password Manager (Microsoft Passkeys). For high-security environments, device-bound is safer, but it's less convenient for users who switch devices. Synced passkeys are easier for end-users, but they're stored in the cloud, which might be a concern if you're paranoid about cloud providers. I'd recommend starting with synced for general users and device-bound for admins and privileged accounts.

Step 4: Integrate with Your Identity Provider

Passkeys work with modern identity providers. If you're on Microsoft Entra ID, you can enable passkeys (FIDO2) directly. They provide verifier impersonation resistance and can serve as an MFA method when combined with device biometrics or a PIN (Microsoft FIDO2 Passkeys (Entra ID)). For a Zero Trust architecture, you want your authentication to be phishing-resistant, and this is where it happens.

Don't forget about the rest of your ecosystem. If you're using AWS, you can federate with an external IdP that supports passkeys. AWS identity federation creates a trust relationship between your IdP and AWS, so users get temporary credentials via roles (AWS IAM Roles). That's a clean way to extend phishing-resistant MFA to your cloud resources.

Step 5: Enforce Phishing-Resistant MFA for Privileged Access

Privileged accounts are the 'keys to the kingdom' (NIST PAM). You absolutely must require phishing-resistant MFA for any admin session. NIST AAL3 requires a hardware-based authenticator with verifier impersonation resistance for scenarios where compromise could cause significant harm (NIST SP 800-63B). That means your break-glass accounts should be using a hardware security key, not just a passkey on a phone. For day-to-day privileged access, consider using a PAM solution that includes credential vaulting, just-in-time access, and session monitoring (NIST PAM). But the authentication to that PAM should still be phishing-resistant.

Step 6: Communicate the Change and Monitor

Users will grumble about change. Be blunt: passwords are a liability. Passkeys are actually easier—no more password resets. But you need to communicate clearly and give them a migration path. Also, set up Conditional Access policies that require phishing-resistant MFA for all users, not just admins. Microsoft Entra Conditional Access is a policy engine that uses identity-driven signals to make decisions, like requiring MFA for specific apps (Microsoft Conditional Access). You can start with a pilot group, enforce it, and expand.

Quick tip: Before you roll out passkeys, make sure your applications support WebAuthn. If not, you'll need to use a third-party IdP that does.

What Can Go Wrong

If you don't implement phishing-resistant MFA, you're gambling on your users never falling for a phishing email. One successful phish can lead to a breach that costs millions. Don't be that organization. Start now, and remember: the goal is to eliminate passwords entirely for your most sensitive access.

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
• Microsoft FIDO2 Passkeys (Entra ID) - https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2
• NIST SP 800-63B - https://pages.nist.gov/800-63-3/sp800-63b.html
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management
• AWS IAM Roles - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html