Passwords Aren't Enough: Pick Phishing-Resistant MFA Now

Why is my password not enough anymore?

You've heard it a thousand times: passwords are dead. But the real problem isn't the concept of a secret—it's that passwords alone are too easy to phish, reuse, and brute-force. NIST, the folks who literally write the rules on digital identity, say a memorized secret should be at least 8 characters, but they also say you must check it against a list of known breached passwords and reject it if it's on there (NIST SP 800-63B). That's a low bar, and it still doesn't stop a determined attacker from tricking you into typing it into a fake login page.

Here's the blunt truth: if you're still using passwords without an extra factor, you're one phishing email away from a breach. The fix isn't just adding any second factor—it's adding a phishing-resistant one. CISA calls that the 'gold standard' of MFA and strongly urges you to implement it as part of a Zero Trust approach (CISA Phishing-Resistant MFA). So stop asking 'password or not?' and start asking 'which MFA?'

What is phishing-resistant MFA, and why should I care?

MFA means you prove who you are with at least two different factors: something you know (a password), something you have (a phone or token), or something you are (your fingerprint). That's the NIST definition (NIST SP 800-63B). But not all MFA is created equal. Traditional MFA—like a code sent via SMS or a push notification you approve—can still be intercepted or bypassed. Attackers have developed 'push bombing' (MFA fatigue) and SIM swap attacks that defeat those methods (CISA Phishing-Resistant MFA).

Phishing-resistant MFA closes that hole. It's built on public-key cryptography, so the secret never leaves your device, and it's bound to the specific website you're using. CISA identifies two forms: FIDO/WebAuthn and PKI-based MFA, like the U.S. government's PIV card (CISA Phishing-Resistant MFA). The point is this: if you're an organization handling any sensitive data, you should be moving to phishing-resistant MFA now, not later.

Passkeys vs. hardware tokens: which is better?

Passkeys are the new kid on the block, and they're essentially FIDO2 WebAuthn under the hood. A passkey is a pair of keys: a private key stored securely on your device and a public key registered with the website. When you sign in, your device signs a challenge with the private key, and the site verifies it—no password is ever sent (Microsoft Passkeys). Because each passkey is bound to the domain it was created for, a passkey for your bank won't work on a look-alike phishing site (Microsoft Passkeys).

Hardware tokens—like a YubiKey—are the same idea but in a separate physical device. They're roaming authenticators you plug in via USB or tap via NFC (CISA Phishing-Resistant MFA). Which is better? For most people, passkeys on your phone or laptop are more convenient because you don't have to carry a separate token. But if you're in a high-risk environment or need to meet AAL3 (NIST's highest assurance level), you might need a hardware-based authenticator with verifier impersonation resistance (NIST SP 800-63B).

Quick tip: If you're rolling out passkeys, enable both device-bound and synced passkeys so users don't get locked out when they get a new phone.

Is OAuth 2.0 authentication? (Spoiler: no)

You might see OAuth 2.0 tossed around as if it were an authentication method. It's not. OAuth 2.0 is an authorization framework—it lets a third-party app get limited access to a resource on your behalf without exposing your password (RFC 6749). An access token doesn't tell you who the user is; it just grants permission to do something. That's why OpenID Connect was built on top of OAuth—it adds an ID token that proves authentication (OpenID Connect). So when someone says 'we use OAuth for login,' they probably mean OIDC. Don't let the jargon fool you.

If you're implementing OAuth, make sure to use PKCE (Proof Key for Code Exchange) for public clients like mobile apps. It's a tiny extension that prevents authorization code interception attacks (RFC 7636). It's not optional anymore—it's the standard.

What about SAML and enterprise SSO?

For enterprise single sign-on (SSO), you have two main protocols: SAML 2.0 and OpenID Connect. SAML is the older, XML-based standard that exchanges assertions between an identity provider (IdP) and a service provider (SP) (SAML 2.0 OASIS). OpenID Connect is the modern, JSON-based layer on top of OAuth 2.0 (OpenID Connect). Both work for SSO, but OIDC is generally simpler for web and mobile, while SAML is still common in legacy enterprise apps.

Here's the practical advice: if you're starting fresh, pick OIDC. It's more developer-friendly and integrates with modern stacks. If you're in a Microsoft-centric environment, you'll likely use Entra ID (Azure AD) which supports both—and you should also turn on Conditional Access to enforce MFA based on signals like user risk and device state (Microsoft Conditional Access). And if you have privileged accounts, use a PIM (Privileged Identity Management) tool to grant just-in-time access with approval and MFA (Microsoft PIM).

Warning: Do not fall for the myth that 'MFA is enough.' If your MFA is SMS-based, it's still vulnerable to SIM swap attacks (CISA Phishing-Resistant MFA).

Takeaway

Stop patching passwords. Move to phishing-resistant MFA—whether that's passkeys or hardware tokens—and use OIDC for SSO with PKCE. Your users will thank you, and your auditors will too. The future of access control is passwordless, and it's here now.

Sources

• NIST SP 800-63B - https://pages.nist.gov/800-63-3/sp800-63b.html
• 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
• OpenID Connect - https://openid.net/connect/
• RFC 6749 (OAuth 2.0) - https://www.rfc-editor.org/rfc/rfc6749