Phishing-Resistant MFA Explained: Passkeys & FIDO2 2026

Why "MFA" Isn't One Thing Anymore

Security researcher Secra puts the core problem plainly: OTP and push-based MFA are not phishing-resistant, because a reverse proxy sitting between the victim and the real site can relay the code or push approval in real time and steal the resulting authenticated session cookie. The user believes they've logged in safely; the attacker has actually logged in for them.

This matters because "MFA" has become a procurement box-tick rather than a specification. A business can be fully MFA-compliant on paper — every account has a second factor — while every one of those factors is still relayable. Phishing-resistant MFA is a narrower, stricter category, and it's the one attackers can no longer bypass with a well-built fake login page.

Phishing-Resistant vs Traditional MFA: The Critical Difference

IBM defines phishing-resistant MFA as authentication using cryptographic keys bound to legitimate websites, making it resistant to interception, replay, and social engineering. Yubico frames the same idea from the attacker's side: this class of MFA is based on public-key cryptography and eliminates shared codes, reducing an attacker's ability to intercept and replay access codes in the first place.

The distinction isn't about how many factors you use — it's about whether the factor can be extracted and reused somewhere else. Secra names the methods that actually qualify as phishing-resistant: FIDO2/WebAuthn security keys and passkeys, plus PIV and smart-card certificate authentication. SMS, email OTPs, and app-generated codes sit outside that list, no matter how many of them you stack together.

• •Phishing-resistant: FIDO2/WebAuthn security keys, passkeys, PIV/smart-card certificate authentication
• •Not phishing-resistant: SMS codes, email OTPs, authenticator-app codes, push approvals

The Cryptographic Foundation: How FIDO2, WebAuthn and Passkeys Actually Work

FIDO2 isn't a single product — it's a combination of two specifications, as Security Standards Canada explains: WebAuthn, the W3C browser-side API, and CTAP, the protocol that governs communication between the browser and the physical or platform authenticator.

When you register a passkey, the authenticator generates a public-private key pair scoped to that specific site's origin. On every subsequent login, the site sends a challenge; the authenticator signs it using the private key, unlocked locally by a PIN or biometric — and that signature only proves anything to the site that issued the original challenge.

This is why a fake login page fails outright. As Security Standards Canada puts it, a convincing fake login page gets nothing usable, because the credential is bound to the real origin. IBM adds the storage detail that matters for risk assessment: the private key is a cryptographic credential stored natively on the device and never leaves it — only the signed response goes anywhere, and that response is worthless off the correct domain.

Passkeys, Security Keys and Smart Cards: Comparing the Phishing-Resistant Options

Thales describes passkeys as password replacements that provide faster, more accessible, and more secure sign-ins to websites and apps — but "passkey" itself covers more than one deployment model, and the differences matter for how a UK business should roll them out.

Security Standards Canada groups authenticators into two broad classes: platform authenticators (built into a laptop, phone or browser) and hardware security keys (a dedicated physical device). Secra adds a further, orthogonal distinction: passkeys are discoverable FIDO2 credentials that may be synced across a user's devices via a cloud account, or bound permanently to a single piece of hardware — both models count as phishing-resistant, but they carry different operational trade-offs.

• •Platform passkeys (often synced): unlocked with device biometric or PIN, follow the user across devices — practical default for the general workforce and customer-facing sign-in
• •Device-bound hardware security keys: the private key never leaves one physical token — the higher-assurance choice for administrators and privileged accounts
• •PIV/smart-card certificate authentication: certificate-based and phishing-resistant per Secra, typically seen in regulated and government-adjacent environments

Implementing Phishing-Resistant MFA: A Practical Rollout for UK Organisations

The first and most commonly missed step is procurement language. Specify FIDO2/WebAuthn, passkeys, or security keys explicitly in contracts and policy documents — not generic "MFA" — because only those terms guarantee the origin-bound property that Microsoft, FIDO, IBM and Yubico all describe. A vendor can honestly claim "MFA support" while only offering SMS and app codes underneath. This is increasingly reinforced from outside procurement too: the wider UK policy backdrop is shifting toward favouring stronger authentication for regulated environments, adding weight to the case beyond internal audit findings or cyber-insurance questionnaires alone.

Sequencing matters more than speed. Administrators, IT staff, and anyone with access to finance systems or customer data represent the highest-value phishing targets and should move to hardware security keys or device-bound passkeys first. The wider workforce can follow with platform passkeys, which lean on biometrics or a PIN they already use to unlock their own device, reducing friction during rollout.

Recovery planning is not optional. Because a device-bound key or synced passkey is tied to specific hardware or an account ecosystem, lost-device and offboarding procedures need a phishing-resistant fallback — a second registered key or platform authenticator — rather than reverting to an SMS code as a backup, which would quietly reopen the exact gap the rollout was meant to close. Organisations building this into a wider architecture should discover how phishing-resistant MFA fits into a Zero Trust strategy rather than treating it as a standalone login upgrade.

Identity Proofing and Zero Trust: The Half of the Picture Authentication Doesn't Cover

Phishing-resistant MFA proves, cryptographically, that the person signing in holds the private key registered to that account. It does not, by itself, prove that the key was registered by the right person in the first place. That's where secure enrolment and identity proofing sit — verifying who someone is before they get to create a passkey or claim a security key, and locking down the recovery path so a helpdesk reset doesn't become the new phishing target.

This is why phishing-resistant MFA is best understood as one control inside a broader identity strategy rather than a replacement for one. Readers building out that wider programme can explore Identity & Access Management solutions to see how enrolment, lifecycle management and authentication fit together, and can understand the basics of Multi-Factor Authentication before deciding where phishing-resistant methods should sit in that stack.

The Business Case: What Changes When You Remove Shared Secrets

The operational case for phishing-resistant MFA is straightforward even without needing a full cost model: passkeys and security keys remove the shared secret that attackers actually target. There is no code to phish, no OTP to relay, no push notification to social-engineer someone into approving — the credential simply doesn't work anywhere except the registered origin.

Because the delivery mechanism for most credential-theft attempts remains a phishing email or a lookalike site, the strongest practical pairing is phishing-resistant MFA at the login layer combined with robust email security at the delivery layer, and staff who can recognise the attempt in the first place — which is why organisations still running legacy MFA should also gain a deeper understanding of phishing attacks as part of the same programme, not a separate one.

Conclusion: Moving From Phishable MFA to Origin-Bound Trust

The line between "has MFA" and "is phishing-resistant" is no longer a technicality — it's the difference between a credential-relay kit failing outright and one walking straight through your login page. FIDO2, WebAuthn and passkeys close that gap by design: the cryptographic check only ever fires for the real relying party, and the private key never leaves the device to be stolen in the first place.

For UK organisations reviewing their authentication estate in 2026, the practical next step is to audit which accounts still rely on SMS, email OTPs or app codes, and to reclassify those as phishing-resistant-pending rather than secure. Teams that want help mapping that transition against a wider security posture can learn more about our cybersecurity services.

Sources

Every figure in this article traces to the sources below.

• •Microsoft Learn — Entra passkey/FIDO2 concept guide (phishing replacement, verifier impersonation resistance)
• •FIDO Alliance — passkeys as cryptographic key-pair replacement for passwords
• •Security Standards Canada — FIDO2 guide (WebAuthn, CTAP, origin-scoped key pairs)
• •Secra — phishing-resistant MFA definition and qualifying method list
• •Yubico — phishing-resistant MFA glossary (public-key cryptography, no shared codes)
• •IBM — phishing-resistant MFA and passkey storage model
• •Thales — comprehensive guide on phishing-resistant MFA, passkeys and FIDO security keys