Stop Treating MFA as a Silver Bullet: Pair It With Phishing-Resistance

You've heard it a hundred times: turn on multi-factor authentication and you're safe. That's the conventional wisdom, and it's dangerously incomplete. Yes, MFA blocks a whole class of attacks, but if your 'second factor' is a text message or a software token that can be phished, you've just added a speed bump, not a roadblock. The real move is to demand phishing-resistant authentication, and to pair it with a ruthless least-privilege policy that assumes every credential will eventually be compromised.

This is a practical walkthrough for anyone who owns identity and access decisions — whether you're a security engineer, an IT admin, or a CISO at a mid-sized company. You don't need a massive budget or a federal mandate to do this right. You need to understand what your authenticators actually guarantee, and then layer the controls that matter. Let's get blunt.

1. Know What Your Authentication Factors Actually Prove

Authentication is the 'who are you?' step, and NIST SP 800-63B breaks factors into three categories: something you know (password), something you have (a one-time password device or hardware key), and something you are (biometrics). That's the theory. The practice is messier. A password can be phished. A software OTP can be relayed in real time. Even a hardware key that doesn't require a user to verify the transaction can be tricked. So before you roll out MFA, ask: which factors am I using, and are they resistant to phishing?

NIST SP 800-63B defines Authenticator Assurance Levels. AAL2 requires two different factors and is the recommended baseline for most systems handling personal, financial, or operational data. AAL3 goes further: it requires a hardware-based authenticator and verifier impersonation (phishing) resistance. That's the level you want for anything that could cause significant harm or financial loss. If you're not there yet, you're leaving the door open for an attacker who can simply stand in the middle of your authentication flow and capture both factors.

So step one: audit your current authenticators. If you're using SMS or a simple TOTP app, you're at AAL1 at best. Move to FIDO2 security keys or smartcards that enforce origin binding. That's the difference between a factor that can be phished and one that cannot.

2. Stop Relying on Passwords as Your Primary Factor

Passwords are the weakest link, and NIST SP 800-63B sets the bar low: subscriber-chosen passwords need to be at least 8 characters, and you should permit at least 64. That's not a recommendation to make users type a 64-character passphrase every time; it's a warning that even strong passwords are phishable and guessable. The real fix is to reduce password reliance altogether.

That's where single sign-on (SSO) comes in. CISA highlights that SSO reduces password fatigue and reduces password reuse across applications. When users only have to remember one password (or better, no password at all), they're less likely to reuse weak ones. And from an admin perspective, SSO centralizes your authentication policy so you can enforce MFA in one place.

But SSO is not a security silver bullet. If your SSO provider is phishable, you've just concentrated the target. So pair SSO with phishing-resistant MFA, and you've actually raised the bar. And for privileged accounts — the ones that NIST PAM calls the 'keys to the kingdom' — never let a password alone stand. Enforce MFA on every privileged session, and consider passwordless options.

3. Treat Zero Trust as a Mindset, Not a Buzzword

Zero trust architecture, as defined in NIST SP 800-207, grants no implicit trust to assets or user accounts based on their physical or network location. That means you stop assuming that being on the corporate VPN or in the office makes someone trustworthy. Instead, access is granted on a per-session basis, with dynamic policy that considers the state of the user, device, and environment.

For authentication, this means you can't just check a password once and let someone roam. You need to re-verify when risk changes — if an employee logs in from a new device, at 3 a.m., or from a foreign IP, you should challenge them again. That's not paranoia; that's zero trust. The OMB M-22-09 memo pushed federal agencies to adopt phishing-resistant MFA by fiscal year 2024, but you don't need a federal mandate to adopt the principle. Apply it to your most sensitive data today.

Practically, this means your identity provider should support step-up authentication, and your access decisions should be dynamic. If a user's session context changes, force re-auth. And for privileged access, use just-in-time (JIT) provisioning — grant admin rights only when needed, for a limited window, and then revoke them. That's a core PAM control (NIST PAM).

4. Enforce Least Privilege and Separation of Duties

Least privilege is simple: users get only the minimum access needed to do their job (Tenable). But it's shocking how many orgs ignore it. AWS IAM's default is to deny everything, and an explicit Deny overrides an Allow — that's the model you should emulate. Start by reviewing every user's permissions and stripping away anything they don't use. That includes admin rights, which should be rare and tightly controlled.

Separation of duties (SoD) is a related principle from NIST SP 800-53: divide critical functions so no single individual can commit fraud or cause catastrophic damage. For example, the person who approves a vendor payment shouldn't be the same person who can set up a new vendor in the system. In access control terms, this means you need to enforce that a user can't have conflicting roles — the ANSI INCITS 359 RBAC standard calls this 'static separation of duty' (NIST RBAC).

Concretely, if you use RBAC, define roles that are mutually exclusive and enforce the constraint in your system. If you use ABAC (attribute-based access control), you can add a policy that denies a request when the user's attributes imply a conflict of interest. Either way, SoD is a critical control that many breaches would have been stopped by.

5. Choose the Right Protocol for Your Federation

If you're building SSO or federating identities, you need to pick a protocol that matches your needs. SAML 2.0 is an XML-based standard from OASIS (2005) that's still widely used in enterprise. OpenID Connect (OIDC) is the modern choice — it's an identity layer on top of OAuth 2.0 and is now the de facto standard for web and mobile (OpenID Connect). OAuth 2.0 itself is an authorization framework, not an authentication protocol (RFC 6749). That's a crucial distinction: an access token in OAuth does not prove who you are; it just grants access to a resource.

So when you're designing your authentication, use OIDC for the 'who are you' part, and it will give you an ID token (a JWT) that proves authentication (OpenID Connect). For SAML, the identity provider issues assertions that contain authentication and attribute statements (SAML 2.0). Both work, but OIDC is simpler for modern APIs and mobile apps.

Underneath all this, you might have LDAP directories (RFC 4511) or Kerberos (RFC 4120). Kerberos uses a ticket-based system with a Key Distribution Center, which gives you the benefit of not re-entering credentials for each service. But these are internal mechanics; your federation protocol is what your apps see.

My recommendation: use OIDC for user-facing apps, and reserve SAML for legacy or government integrations that require it. And never use OAuth 2.0 alone for authentication — you'll be missing the identity proof.

6. Layer ABAC on Top of RBAC for Fine-Grained Decisions

RBAC is great for scalability — you assign permissions to roles, and users inherit them (Tenable). But RBAC is coarse: it can't say 'allow this user to see this record only during business hours from a corporate device.' That's where ABAC comes in, evaluating attributes of the subject, object, action, and environment (Cisco Duo).

In practice, most orgs use RBAC as the baseline and add ABAC for context-aware decisions (Cisco Duo). For example, you might have an 'accounts payable' role that can approve invoices, but an ABAC policy that only allows that action if the user's location is the office, the time is 9-5, and the device is compliant. That's a powerful control that stops lateral movement and insider threats.

But don't go overboard. ABAC can get complex and hard to manage. Start with RBAC, then add ABAC for the few high-risk actions where context matters. And always remember: authentication is not authorization. Even if a user passes MFA, they should only get the minimal access their role and attributes allow.

What Can Go Wrong

Here's the trap: you implement phishing-resistant MFA, you set up SSO, you add ABAC policies, and you think you're done. Then an attacker compromises a privileged account that has over-broad permissions, or they phish a helpdesk agent who can reset passwords. The lesson is that authentication is only one layer. If you don't enforce least privilege, if you don't monitor privileged sessions, if you don't have a PAM strategy, you're still exposed.

Another pitfall: locking users out. If you enforce strict MFA and ABAC without a fallback, you'll have a support ticket storm. Plan for exceptions, but make them rare and logged. And never let a single factor be 'something you know' alone — that's just a password, which is phishable.

Bottom Line

The single best move you can make today is to deploy phishing-resistant MFA (hardware keys or smartcards) for all privileged accounts, and pair it with a least-privilege policy that strips unnecessary access. Do that, and you'll stop the most common breach paths. Everything else — SSO, ABAC, zero trust — is layered on top, but without that foundation, you're just polishing a leaky boat.

Sources

• 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
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management
• Cisco Duo - https://duo.com/learn/access-control-models
• OpenID Connect - https://openid.net/connect/