Phishing-resistant MFA: why your fallbacks just bypassed it

You deployed phishing-resistant MFA. FIDO2 security keys, passkeys, the works. Pat yourself on the back, then check your tenant settings, because if you left the fallbacks on, you have not actually deployed phishing-resistant MFA. You have deployed strong MFA with a weaker option still wired in.

Two attacks disclosed in 2025 made this distinction expensive. Neither broke FIDO2 itself. Both worked by forcing users out of the strong authentication path and into a weaker one that was still available. The first was contained by an obscure protocol feature. The second is operational today and waiting to be picked up at scale.

If you run a Microsoft 365 tenant for an Australian business, this is the most important thirty minutes of audit work you will do this quarter.

What phishing-resistant MFA actually means

Phishing-resistant MFA is not a marketing label. The Australian Signals Directorate, NIST, CISA, and Microsoft all use a specific technical definition. The authentication method must use cryptographic domain binding so that credentials cannot be intercepted, replayed, or relayed by an adversary-in-the-middle proxy sitting between the user and the legitimate service.

In practice, that narrows the field to three methods. FIDO2 security keys, like the YubiKey range and other hardware tokens. Windows Hello for Business, which uses the same cryptographic foundations on a trusted device. And certificate-based authentication delivered through Microsoft Entra ID or equivalent enterprise platforms.

Everything else fails the phishing-resistance bar. SMS one-time codes can be intercepted via SIM swapping or harvested via fake login pages. Authenticator app push notifications can be defeated by MFA fatigue or accepted by mistake. Time-based one-time passwords can be relayed in real time through proxy phishing kits like Evilginx and Tycoon 2FA. Email one-time codes carry all the weaknesses of email itself.

Australian Signals Directorate has been pushing phishing-resistant MFA hard since the 2023 update to the Essential Eight, and the November 2023 maturity model revision made it a Maturity Level 2 requirement for privileged users. The 2026 ACSC guidance is pushing for phishing-resistant methods at every level, not just for admins. The technical answer is well understood. The deployment reality is where it falls apart.

PoisonSeed: the QR code trick that almost worked

In July 2025, researchers at Expel disclosed a phishing campaign they named PoisonSeed. The attack abused FIDO2’s cross-device authentication flow, also called hybrid transport, which lets a user sign in on a desktop by scanning a QR code with a mobile device that holds their passkey.

The attack chain worked like this. A user clicked a phishing link and landed on a fake login page that perfectly mimicked the real one. The fake page initiated a real cross-device authentication request to the legitimate service in the background. The legitimate service responded with a QR code, which the fake page displayed to the user. The user, believing they were on the real site, scanned the QR code with their phone and approved the authentication. The session token went to the attacker.

The attack looked devastating because it bypassed the cryptographic domain binding that makes FIDO2 phishing-resistant. The user’s device proved possession of the private key, just to the wrong session.

The reason PoisonSeed did not scale is one of the underrated features of the FIDO2 specification. Cross-device authentication requires Bluetooth proximity verification between the desktop and the phone. Without that proximity check, the spoofed QR code does not authenticate against the real session. Later analysis confirmed that in real-world conditions, the proximity check breaks the attack chain reliably.

PoisonSeed taught us two things. First, FIDO2’s cryptographic protections only work when the implementation enforces all the safeguards, not just some of them. Second, attackers will keep finding edge cases in the specification. The next attack will be different.

The Proofpoint downgrade attack: this one works

In August 2025, Proofpoint researcher Yaniv Miron disclosed a downgrade attack against FIDO authentication in Microsoft Entra ID. Unlike PoisonSeed, this one is operational today. It has not been observed in the wild yet according to public reporting, but the technical capability is fully developed.

The attack exploits a compatibility gap rather than a protocol flaw. Microsoft Entra ID does not support FIDO2 passkey authentication on every combination of operating system and browser. The specific combination the researchers used was Safari on Windows, which Entra ID does not list as a supported FIDO2 client.

The attack chain uses the Evilginx adversary-in-the-middle framework with a custom phishlet. When a victim clicks a phishing link, Evilginx proxies the real Microsoft login flow in real time, but it spoofs the user agent string to make Entra ID think the user is on Safari on Windows. Entra ID, seeing an unsupported FIDO client, prompts the user to choose a different authentication method. The user, frustrated that their passkey is not working, falls back to SMS or app-based MFA. That fallback authentication is harvested by Evilginx in the usual way. The session cookie goes to the attacker.

The user did everything right. They had a registered passkey. They tried to use it. The system itself told them to use a weaker method. By the time they realised something was off, the attacker had a valid session.

This is what makes the Proofpoint attack important. It does not require a vulnerability in FIDO2, in Entra ID, or in the user’s device. It requires the existence of a weaker fallback method on the account. If the fallback is not there, the attack collapses at the downgrade prompt. The user sees a “your passkey is not working” message, contacts IT, and the phishing chain dies in the help desk queue.

The root cause is the fallback, not the protocol

The deeper lesson from both attacks is that phishing resistance is a property of the entire authentication chain, not a property of the strongest method in the chain. If FIDO2 is registered but SMS recovery is still on, the account is functionally as strong as SMS, not as strong as FIDO2.

Apple made this point publicly at the 2025 FIDO Authenticate conference. Adding passkeys as an option does not make a system phishing-resistant if SMS recovery, password reset flows, or other weaker methods remain in the authentication chain. Phishing resistance is a property of what you keep enabled, not what you add.

Google has been operating this way internally for years. After the 2017 Account Takeover Working Group report identified phishing as the primary attack vector against employees, Google deployed FIDO security keys across 85,000 staff and removed every alternative method. Zero successful phishing attacks since. Cloudflare deployed FIDO keys and disabled all other MFA after the Twilio breach, and survived a sophisticated phishing campaign that compromised other companies the same week. Snap reported zero account takeovers for more than two years after the same migration.

The pattern is consistent. Deploying FIDO is necessary but not sufficient. Removing the fallbacks is what closes the attack surface.

The Microsoft Entra ID compatibility gap is the operational problem

The reason most Australian businesses cannot simply turn off all the fallbacks is the Entra ID compatibility gap that the Proofpoint researchers exploited. Microsoft has steadily expanded FIDO2 support across operating systems and browsers, but coverage is not yet universal. Safari on Windows is the most notorious gap. Older Android versions, Firefox on certain mobile platforms, and embedded browsers in third-party applications all have edge cases where FIDO2 does not work.

For most businesses, those edge cases account for a single-digit percentage of authentication events, but the percentage is not zero. Turning off all fallback methods means accepting that the people hitting those edge cases will be locked out and need to call the help desk. That is a real operational cost.

The honest answer is that operational cost is much smaller than the security cost of leaving the fallbacks on. A locked-out user is a help desk call. A compromised user is an incident response engagement, a notifiable data breach assessment, and a six-figure cyber insurance excess.

The path forward for Australian businesses is structural. Set FIDO2 and Windows Hello for Business as the only acceptable methods for privileged accounts, with no fallback. Set FIDO2 as the strongly preferred method for standard accounts, with a tightly governed temporary access pass process for the edge cases. Disable SMS, voice call, email OTP, and security questions across the entire tenant. Keep authenticator app push as a transitional method for standard users with a clear deprecation timeline.

Seven things to audit in your tenant today

Where the Essential Eight fits

The Australian Signals Directorate has been clear since the November 2023 Essential Eight maturity model update. Phishing-resistant MFA is required at Maturity Level 2 for privileged users and increasingly expected across the board at Maturity Level 3. The 2026 ACSC guidance is pushing harder, not softer.

The implication is direct. If your Essential Eight assessment marks you as Maturity Level 2 on multi-factor authentication, and the underlying configuration leaves SMS or other weaker methods available alongside FIDO2, the assessment is wrong. The control is not fully implemented, and an attacker exploiting a downgrade attack will demonstrate that to your incident response team eventually.

This is the gap we see most often when we run uplift assessments on businesses that previously self-assessed as Essential Eight compliant. The boxes were ticked. The fallbacks were never removed. The Proofpoint attack works precisely because of that gap. For more on the practical reality of Essential Eight in 2026, including the November 2023 model and the 2026 IRAP changes, see our Essential 8 Compliance Guide.

What good looks like

The mature operating model for Australian businesses on phishing-resistant MFA in 2026 looks like this.

Privileged accounts authenticate only with FIDO2 security keys or Windows Hello for Business. No fallback. Break-glass accounts use the same. Conditional Access enforces this through an authentication strength policy that explicitly blocks weaker methods.

Standard accounts authenticate with FIDO2 by default. Authenticator app push is permitted only during a defined transition window, with a board-approved end date. SMS, voice call, and email OTP are disabled tenant-wide. Self-service password reset uses the same authentication strength as login.

Temporary access pass handles edge cases. Time-limited, single-use, logged, and reviewed weekly by the security team. Anyone using TAP twice in a quarter triggers a root cause investigation, because that is the operational signal that something in the deployment is broken.

The phishing simulation program tests downgrade attacks, not just credential harvesting. The metric is not the click rate. It is the fallback approval rate. If users approve a fallback when their passkey fails, the system has been bypassed by design.

This is achievable for most Australian mid-market businesses inside a quarter. The technical work is not large. The change management is where it lives or dies. Communicating to staff why their familiar authenticator app push is being deprecated, why the SMS fallback they used twice last year is now gone, and why their newly issued security key is the only path forward, is the actual project. Get that right and the technical configuration follows in a week.

Frequently asked questions