MFA Alone Won't Save You: Why AAL2 Is the Real Minimum

There's a common misconception that any multi-factor authentication (MFA) is good enough. That's wrong. Most MFA deployments are still vulnerable to phishing and session hijacking. The fact is, NIST's Authenticator Assurance Level 2 (AAL2) is the real minimum for most systems, and it's not just about having two factors—it's about having the right ones.

What Exactly Is AAL2?

NIST SP 800-63B defines three authenticator assurance levels. AAL2 requires multi-factor authentication using two different factors—something you know, something you have, or something you are (NIST SP 800-63B). That sounds simple, but the nuance is that AAL2 also requires that the authentication be phishing-resistant. That means your typical SMS codes or even push notifications that don't verify the server are not enough. AAL2 is recommended for most systems handling personal, financial, or operational data (NIST SP 800-63B). If you're not aiming for AAL2, you're not serious about security.

Why Passwords Are Not Enough

Passwords are the weakest link. They're something you know, and they're easily phished, reused, and stolen. NIST SP 800-63B requires subscriber-chosen passwords to be at least 8 characters long and recommends permitting up to 64 characters (NIST SP 800-63B). But even a 64-character password can be phished if a user types it into a fake site. The real solution is to move away from passwords entirely for primary authentication, or at least pair them with a phishing-resistant second factor. The federal government recognized this when it mandated phishing-resistant MFA for agencies by the end of fiscal year 2024 (OMB M-22-09). If the government says it's necessary, it's probably time for your enterprise too.

The Problem with Most MFA

Let's be blunt: SMS codes and simple push notifications are not phishing-resistant. An attacker can intercept SMS or trick a user into approving a malicious push. AAL2 requires verifier impersonation resistance, meaning the user must be able to confirm they're authenticating to the real server, not a lookalike (NIST SP 800-63B). That's why hardware security keys, like FIDO2 tokens, are the gold standard. They provide cryptographic proof of the server's identity, so even if a user is tricked into visiting a phishing site, the key won't work. That's the level of security you need.

How to Achieve AAL2

To meet AAL2, you need to implement MFA that uses two distinct factors and is phishing-resistant. Practically, that means using a hardware authenticator (something you have) combined with a PIN or biometric (something you know/are). For example, a YubiKey with a fingerprint sensor. Or a Windows Hello for Business setup with a PIN and biometric. These meet the AAL2 bar. Avoid SMS and OTP apps that don't support server verification. NIST SP 800-63B explicitly requires verifier impersonation resistance at AAL2, so any solution that doesn't have that fails the standard (NIST SP 800-63B).

But Wait, What About AAL3?

If AAL2 is good, why not go to AAL3? AAL3 requires a hardware-based authenticator and verifier impersonation resistance, and is recommended when compromise could cause significant harm or financial loss (NIST SP 800-63B). That's a higher bar, but for most organizations, AAL2 is a reasonable starting point. For privileged accounts, you should definitely consider AAL3, but for general user access, AAL2 is the minimum you should accept. Don't let perfect be the enemy of good—get to AAL2 first, then move your most sensitive accounts to AAL3.

What I'd Actually Do

Here's my recommendation: stop rolling out weak MFA. Adopt AAL2 as your organization's baseline for all users. That means replacing SMS and OTP app tokens with phishing-resistant hardware keys or passkeys. For privileged accounts, go a step further and implement AAL3, and add just-in-time privileged access management (NIST PAM). Yes, it will cost money and cause some user friction, but the alternative—a breach—is far more expensive. I'd rather have a few users complain about carrying a key fob than have a security incident that makes headlines.

Sources

• NIST SP 800-63B - https://pages.nist.gov/800-63-3/sp800-63b.html
• OMB M-22-09 - https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management