Choosing an Authentication Method: What Actually Works

The ping came at 2:47 AM. One of our sales reps had her account popped, and the attacker used that stolen password to crawl through our CRM for an hour before we caught it. I sat there resetting credentials and wondering why we'd treated MFA like a compliance checkbox instead of an actual security decision. If you're the person who has to make authentication work without losing your mind—or your data—this is for you.

Passwords alone are done. If that's your only gate, you're already behind. But that doesn't mean you should splurge on the priciest hardware tokens and call it a day. The right method depends on your threat model, your users, and what you can actually afford. There's no universal answer. Here's how to cut through the noise and pick something that works in practice, not just on a slide.

Step 1: Know What You're Protecting

Before you look at any method, ask yourself: what would genuinely hurt if it got compromised? Customer financial data, personal health info, production servers—each deserves a different level of protection. NIST has a useful baseline: Authenticator Assurance Levels (AALs) in SP 800-63B. For most systems handling personal or financial data, they recommend at least AAL2, which means multi-factor using two different factors. That's your floor.

But not all data is equal. A public marketing site? Maybe a password is fine. Your infrastructure admin panel? You need to think about AAL3, which calls for hardware-based, phishing-resistant authenticators. Don't over-engineer the low-risk stuff, but don't under-protect the crown jewels either. Start by classifying your resources and assigning a risk level. Write it down. Then move on.

Step 2: Understand Your Factor Options

Authentication boils down to three things: something you know (like a password), something you have (like a phone or token), and something you are (like your fingerprint). Multi-factor means you use at least two of these. Sounds straightforward, but here's the catch: not all factors are created equal. SMS codes? They're better than nothing, but they're vulnerable to SIM swapping and SS7 attacks. Push notifications? Sure, convenient, but they're susceptible to "push bombing"—where attackers spam requests until you give in and approve one just to make it stop.

CISA's guidance is clear: the gold standard is phishing-resistant MFA, which includes FIDO/WebAuthn (the technology behind passkeys) and PKI-based methods like PIV cards. Passkeys, for instance, are bound to a specific domain. So a passkey created for yoursite.com won't work on a look-alike phishing site. That's a real security win, but it's not always practical for every user or every situation. You have to weigh the pros and cons.

Here's a quick rundown of your options:

See the trade-off? Security and friction are always in tension. Acknowledge that and move on.

Step 3: Match the Method to Your Users

Now, think about who your users are. For most employees, single sign-on (SSO) is a huge win. It lets them authenticate once and access multiple apps with one set of credentials, cutting down on password fatigue and reuse. SSO also centralizes authentication, making it easier to enforce MFA and monitor risk. If you're not using SSO yet, that's your starting point.

But SSO alone isn't enough. You need to layer on conditional access. For example, Microsoft Entra Conditional Access lets you create policies like "if a user wants to access Microsoft 365, they must perform MFA." You can base decisions on signals like user group, location, device compliance, and sign-in risk. That's how you move from static rules to dynamic, context-aware control.

For your privileged users—the ones with the keys to the kingdom—you need more. Privileged Access Management (PAM) is essential. PAM controls and monitors privileged accounts, with common controls like credential vaulting, just-in-time access, session recording, and MFA for privileged sessions. Tools like Microsoft Entra Privileged Identity Management (PIM) give you time-based and approval-based role activation. This means an admin doesn't have standing access; they request it, and it expires after a set period. That's a game-changer for limiting the blast radius of a compromise.

Step 4: Choose Your Protocols and Tokens

Under the hood, your authentication methods rely on protocols. For modern federated auth, OpenID Connect (OIDC) is the way to go. It's built on OAuth 2.0 and adds a signed ID token that proves authentication. If you're dealing with legacy enterprise apps, SAML 2.0 might be necessary—it's XML-based and exchanges assertions between an identity provider and service provider.

When you use OAuth 2.0, be careful: OAuth is for authorization, not authentication. An access token doesn't tell you who the user is. And if you're using bearer tokens, remember that anyone who possesses the token can use it. So, protect your tokens, use HTTPS, and implement PKCE to prevent authorization code interception.

For tokens themselves, JSON Web Tokens (JWT) are compact and self-contained. They're great for APIs, but they need proper validation—check the signature, expiration, and issuer. Don't just trust any token that comes your way.

Step 5: Watch Out for the Gotchas

Here's what can go wrong: you roll out a shiny new MFA method, and your users revolt. They can't log in, they get locked out, and they start using workarounds. The most common failure is ignoring usability. For example, requiring a hardware token for every single login will drive your people insane. Instead, use adaptive policies—require MFA only for risky sign-ins or sensitive apps.

Another trap: thinking that more factors automatically mean more security. If you use two factors that are both vulnerable to the same attack, you haven't gained much. For instance, SMS + push notification both rely on the phone, so a SIM swap could compromise both. That's why phishing-resistant methods like passkeys are superior—they combine something you have (device) with something you are/know (biometric or PIN) and are bound to the domain.

Finally, don't forget the human element. Even with MFA, users can be socially engineered. Train them to recognize phishing attempts and not approve unexpected push prompts. And enforce session timeouts—NIST recommends re-authentication after 12 hours of extended use or 30 minutes of inactivity at AAL2.

The One Thing to Remember

Authentication isn't a one-size-fits-all decision. It's a risk-based choice that changes as your users, data, and threats evolve. So, stop treating it like a box to tick. Start with SSO and phishing-resistant MFA as your baseline, layer on conditional access for context, and reserve PAM for your privileged accounts. Your future self—and your users—will thank you.

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
• CISA SSO - https://www.cisa.gov/sites/default/files/2024-06/Barriers-to-SSO-Adoption-for-SMB-508c.pdf
• Microsoft Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• RFC 7636 (PKCE) - https://www.rfc-editor.org/rfc/rfc7636