Multi-factor authentication (MFA) has been standard practice for years, but not all MFA is created equal. CISA’s own guidance on the subject puts it directly: phishing-resistant MFA is the gold standard, and every other form, SMS codes, push approvals, number matching, one-time passcodes, remains vulnerable to real-time phishing attacks. That distinction matters more today than it did even two years ago, as adversary-in-the-middle (AitM) phishing kits have moved from custom tooling used by sophisticated actors to commoditized, subscription-based services available to almost anyone. Phishing-resistant authentication solves this by cryptographically tying every login attempt to the real site and device requesting it, so anything a fake page manages to capture, a password, a code, an approval, cannot be replayed against the legitimate service.
For security teams, that raises a practical question that goes beyond whether MFA is enabled. It’s whether the specific methods in place can withstand a phishing attempt built to defeat them, and if not, what it actually takes to move to something that can.
How Attackers Defeat Legacy MFA
Legacy MFA methods share a common weak point: they all rely on a secret, a code, a push approval, a number, that can be intercepted and reused. AitM phishing kits exploit this directly. Instead of stealing a password and hoping it isn’t protected by MFA, these kits act as a reverse proxy. The victim visits what looks like a normal login page, but every request is silently relayed to the real site in real time. The kit captures the username, password, and the one-time code or push approval as they’re entered, then hijacks the resulting session token before the user notices anything unusual.
This is why traditional MFA, even layered MFA, doesn’t fully solve the problem it was built for. It verifies that a user possesses a second factor. It says nothing about whether the login request came from a legitimate source in the first place.
What Makes Phishing-Resistant MFA Different
Phishing-resistant MFA closes that gap by changing what gets verified. FIDO2/WebAuthn authentication, which includes passkeys, security keys and Windows Hello for Business, relies on public-key cryptography rather than a shared secret. When a user registers a phishing-resistant credential, their device generates a key pair: a private key that never leaves the device’s secure hardware, and a public key registered with the service.
Every login is a cryptographic challenge scoped to the legitimate site’s origin. A fake login page cannot pass that challenge, because it doesn’t hold the private key, and it can’t relay the challenge to the real site the way it can relay a typed code, because the exchange is bound to the specific origin requesting it.
NIST’s own authenticator assurance guidance (SP 800-63B) treats this as a distinct, higher tier of assurance, and CISA identifies FIDO2/WebAuthn and PKI-based authentication (smart cards, PIV/CAC) as the only two widely available options that meet the bar. Passwords, one-time codes and push approvals don’t, no matter how many of them are stacked together.
Weighing the Common Objections
Security leaders considering this shift tend to raise the same three concerns, and each one is more solvable than it first appears.
Cost. The assumption is that phishing-resistant MFA requires new licensing or hardware across the board. In practice, most organizations already own what’s needed. Windows Hello for Business is built into Windows, and passkey support is included in the Microsoft 365 and Entra ID tiers most enterprises already license. Physical security keys are a real, incremental cost, but typically only for the smaller population of high-risk users, executives, finance staff, privileged admins, who may need a hardware-bound option beyond a platform authenticator.
User friction. This is often the opposite of what leaders expect. Passkeys typically authenticate faster than typing a one-time code, and biometric unlock removes the friction of juggling a separate authenticator app. Once users move past initial enrollment, the day-to-day experience is usually simpler than what it replaces.
Implementation complexity. This is the legitimate concern, and the one that causes the most rollouts to stall. Every organization has some mix of legacy systems, service accounts, and edge cases, a printer, a SAML integration, a decade-old internal tool, that won’t support FIDO2 out of the box. The answer isn’t to wait until every exception is resolved before starting. It’s to inventory those exceptions early, using automation and AI-assisted scoping to flag them quickly, and stage enforcement so the majority of users move first while legacy cases are handled deliberately rather than blocking the whole project.
A Phased Rollout That Works
In practice, a rollout that avoids disruption tends to follow a consistent pattern.
• Start with discovery. Inventory every application, VPN and system currently in use, and identify which ones still accept SMS, push, number matching or one-time codes as a login method.
• Pilot with high-risk users first. Executives, finance staff and IT administrators are both the highest-value targets and typically the easiest group to support directly through a pilot, since issues can be resolved quickly with hands-on help.
• Use automation and AI to handle the long tail. Legacy exceptions, service accounts, printers, older SAML integrations, are what typically stall enterprise-wide rollouts. Automated, AI-assisted scoping can identify these dependencies faster than a manual audit, so they can be addressed in parallel rather than discovered one at a time during enforcement.
• Enforce in stages, not all at once. Moving one group or one application at a time, rather than flipping a single organization-wide switch, keeps the help desk from being overwhelmed and gives the security team room to catch issues before they affect the whole company.
• Monitor fallback usage. Even after rollout, some users will occasionally fall back to a legacy method. Tracking how often that happens, and why, is what turns a one-time project into an ongoing control.
None of this requires waiting for a perfect solution or an unlimited budget. The technology already exists inside most environments, and the rollout models for deploying it responsibly are well established.
A phishing-resistant MFA rollout isn’t finished the day every user has a passkey enrolled. It’s finished when the fallback options, SMS codes, one-time passcodes, help-desk resets, have actually been switched off rather than left available as a convenience. Until that happens, the new deployment and the legacy one it was meant to replace are running side by side, and an attacker only needs the weaker of the two to still work.
Â
Join our LinkedIn group Information Security Community!
