Stop Auditing for MFA — Audit for Phishing Resistance Instead

I'm going to say something that will annoy a lot of auditors: your MFA checkbox is worthless. It has been for years. If your access control compliance program still counts a push notification or an SMS code as a passing control, you are auditing theater, not security. The standard you should be measuring against is phishing-resistant MFA, and the gap between "has MFA" and "has phishing-resistant MFA" is where real breaches live.

The uncomfortable truth about "MFA enabled"

CISA doesn't mince words here. It calls phishing-resistant MFA the "gold standard" and notes that not all MFA is equal — some forms are vulnerable to push bombing, SS7 exploitation, and SIM swaps (CISA Phishing-Resistant MFA). I've watched compliance reports proudly declare 100% MFA coverage while the entire workforce was authenticating with one-tap push. That's not a control. That's a speed bump an attacker can drive over with a few late-night prompts.

So here's my thesis, and I'll defend it: any access control audit that doesn't specifically test for phishing resistance is documenting a vulnerability, not a mitigation. If your evidence pack says "MFA enforced" without saying "FIDO2/WebAuthn or PKI-based," you have failed your own audit.

What the standards actually demand

The federal government already figured this out. OMB Memorandum M-22-09 directed U.S. federal agencies to adopt zero trust principles and required them to hit specific goals, including phishing-resistant MFA, by the end of fiscal year 2024 (OMB M-22-09). That's not a suggestion. That's a deadline with teeth, and it exists because the people writing it understood that legacy MFA wasn't cutting it.

NIST's Digital Identity Guidelines reinforce the point from a different angle. At Authenticator Assurance Level 3 (AAL3), you need a hardware-based authenticator plus verifier impersonation resistance — in plain terms, phishing resistance — for use when compromise could cause significant harm or financial loss (NIST SP 800-63B). Most enterprise systems handling financial or operational data sit at AAL2, which only requires two different factors. That's a floor, not a ceiling. If your auditors stop at the floor, they're not protecting anything that matters.

Why passkeys change the audit conversation

Passkeys are the practical answer most organizations should be moving toward. A passkey is bound to the specific domain it was created for, so it won't be presented to a look-alike phishing site — that's structural, not behavioral (Microsoft Passkeys). And because passkeys require the device (something you have) plus a biometric or PIN unlock (something you are or know), they qualify as multi-factor authentication by themselves.

CISA is blunt that FIDO/WebAuthn is the only widely available phishing-resistant authentication method, with authenticators being either roaming devices or platform authenticators built into laptops and phones (CISA Phishing-Resistant MFA). That's your audit target. Not "MFA," but FIDO2.

The counterargument — and why it doesn't hold

The strongest pushback I get is practical: "We can't roll out hardware keys to 10,000 employees overnight, and synced passkeys aren't universally supported." Fair. Rollout takes time. But that's an argument about sequencing, not about what you audit for. You can phase deployment while still changing the control definition in your compliance program today. An audit finding that says "MFA is present but not phishing-resistant" is a useful finding. A finding that says "MFA present, pass" is a lie you're telling your board.

The other objection is cost. But compare the cost of a single credential-phishing incident to the cost of a YubiKey. The math isn't close. And if you're in a regulated environment, you're already paying for the audit — make it count.

What a real access control audit looks like

Auditing for phishing resistance means changing what you collect as evidence. It's not enough to pull a report showing MFA enrollment percentages. You need to know which methods are actually in use, and you need to treat the weak ones as exceptions with compensating controls.

• Inventory authentication methods by user population, not just MFA on/off.
• Flag push and SMS as exceptions requiring justification and a migration date.
• Verify that privileged accounts use hardware-backed or phishing-resistant methods, consistent with PAM guidance on multi-factor authentication for privileged sessions (NIST PAM).

That last point matters more than most teams admit. Privileged accounts are the "keys to the kingdom," and their compromise plays a role in many major breaches (NIST PAM). If your domain admins are still on push MFA, your audit has a hole you could drive a truck through.

None of this requires inventing new frameworks. It requires being honest about what your existing controls actually stop. NIST SP 800-207 is clear that zero trust grants no implicit trust based on network location and evaluates access per session using dynamic policy. Phishing-resistant MFA is the identity half of that equation. If you're claiming zero trust alignment while running SMS codes, you're not aligned.

What I'd actually do

If I were running compliance for an organization of any size, I'd rewrite the access control control statement this quarter. Replace "multi-factor authentication is enforced" with "phishing-resistant multi-factor authentication (FIDO2/WebAuthn or PKI-based) is enforced for all users, with documented exceptions and remediation timelines." Then I'd run an exception report and hand it to leadership with a deadline. Start with privileged accounts and executives — the highest-value targets — and work outward. Synced passkeys make this more feasible than it was two years ago, and the standards have been pointing this direction since at least 2022. The auditors who adapt will be the ones whose findings actually prevent breaches. The rest will keep checking boxes while the boxes burn.

Sources

• CISA Phishing-Resistant MFA - https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• 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
• Microsoft Passkeys - https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final