Passkeys and FIDO2: The End of Passwords — and What Attackers Do Next

In May 2025, Microsoft made all new accounts passwordless by default. AWS added passkey support and warned root users to enable MFA or face account restrictions. The FIDO Alliance’s Passkey Index shows passkeys now available on over 15 billion devices. The password era is ending — but attackers aren’t going away.

TL;DR

Passkeys use public-key cryptography: your device signs a challenge, no shared secret is ever transmitted

They are cryptographically bound to the specific domain — a passkey for google.com cannot be used on go0gle.com

This defeats phishing, credential stuffing, and man-in-the-middle attacks by design

The main attack vector is downgrade: force the user to a fallback method (SMS OTP, email link) that is phishable

PoisonSeed and similar campaigns specifically target FIDO2 downgrade in enterprise environments

Deploy passkeys with no fallback to weak methods — the protection is only as strong as the weakest allowed factor

The Problem Passkeys Solve

Passwords have three fundamental weaknesses that no complexity policy or MFA add-on fully fixes:

They’re phishable — a user can be tricked into entering their password on a fake site
They’re reusable across sites — credential stuffing works because people reuse passwords
They’re stored as a shared secret — the server holds your password hash; breach the server, steal the hashes

Traditional MFA (TOTP codes, SMS) helps with the third problem but not the first two. An AiTM (Adversary-in-the-Middle) phishing proxy like EvilGinx sits between the user and the real site, harvesting both the password and the MFA token in real-time. The user authenticates to the attacker’s proxy; the proxy authenticates to the real site.

Passkeys are designed to make this attack class impossible — not harder, impossible.

How Passkeys Work

A passkey is a cryptographic key pair — a public key and a private key — generated by your device. Think of it like a padlock and key: the server holds the padlock (public key), and only your device has the key that opens it (private key).

Registration:

You register with a site (e.g., your bank)
Your device generates a unique key pair for that site
The public key is sent to and stored by the site
The private key never leaves your device

Authentication:

The site sends a cryptographic challenge
Your device signs the challenge with the private key (after you authenticate locally — fingerprint, face ID, or device PIN)
The signature is sent to the site
The site verifies the signature with the stored public key

No password is ever transmitted. No shared secret exists. The private key never leaves the device.

Why Passkeys Are Phishing-Resistant

The critical security property is domain binding. When your device creates a passkey, it records the exact domain it was created for — google.com, not go0gle.com, not accounts-google.com.

When an authentication request arrives, the device checks: does this request come from the domain this passkey was created for? If the domain doesn’t match exactly, the device refuses to sign the challenge. Full stop.

An attacker running a phishing site at g00gle.com cannot use a passkey registered for google.com — the device rejects the request before the user can do anything. This is categorically different from TOTP codes, which the user types manually and which phishing sites can relay in real-time.

The same property defeats AiTM proxies. Even if an EvilGinx proxy sits between the user and the real site, the challenge comes from the proxy’s domain — not Google’s — and the passkey authentication fails.

The Two Types of Passkeys

Understanding the difference matters for security decisions:

Type	Storage	Sync	Risk profile
Synced passkeys	Cloud (iCloud Keychain, Google Password Manager, etc.)	Across all your devices	Account compromise = passkey access
Device-bound passkeys	Hardware security key (YubiKey, etc.)	No sync	Physical loss = loss of access

Synced passkeys (what most consumers use) are more convenient and still dramatically more secure than passwords. The risk: if your Apple ID or Google account is compromised, attackers may access your synced passkeys. For high-security accounts (privileged admin access, financial systems), device-bound passkeys on a hardware security key are the gold standard.

The FIDO Alliance published a new specification in 2025 allowing secure passkey migration between ecosystems — addressing the historic pain point of moving from iOS to Android or vice versa.

How Attackers Respond: The Downgrade Attack

Passkeys break traditional phishing. So attackers target the weakest link in the authentication chain: the fallback method.

Most organizations deploying passkeys maintain fallback options — SMS OTP, email magic links, security questions — for users who can’t use their passkey (new device, lost phone, etc.). These fallbacks are exactly as phishable as they were before passkeys were deployed.

A downgrade attack works like this:

Attacker initiates authentication for the victim’s account
Attacker selects “Can’t use passkey? Use another method”
Attacker triggers the SMS OTP fallback
Attacker phones the victim pretending to be IT support, requests the OTP (“We detected unusual activity on your account, please read me the code you just received”)
Attacker completes authentication with the OTP

The passkey was never involved. The victim’s passkey protected their account. The fallback method betrayed it.

PoisonSeed: FIDO2 Downgrade at Enterprise Scale

The PoisonSeed campaign (2025) demonstrated this at scale against enterprise environments. The attack chain:

Compromise a CRM or email marketing tool (Mailchimp, HubSpot) via the support team’s account
Export the customer/employee email list
Send targeted phishing emails with “security alert” pretexts
Landing pages present “passkey not recognized on this device” error
Force the fallback flow: SMS or email OTP
Harvest the OTP in real-time and use it to log in

The sophistication is in the social engineering layer — the victim believes they’ve done something secure (received an OTP) when they’ve actually bypassed the phishing-resistant layer entirely.

For a detailed look at how AiTM phishing works against standard MFA before passkeys: AiTM Phishing and MFA Bypass with EvilGinx.

Enterprise Deployment: What Actually Matters

Microsoft Entra ID

Microsoft Entra passkeys entered public preview in March–April 2026, enabling hardware FIDO2 security keys and synced passkeys for Windows sign-in. Configuration:

Navigate to Entra ID → Authentication methods → Passkeys (FIDO2)
Enable and configure key restrictions (optionally allow only specific AAGUID sets for certified hardware keys)
Set Authentication Strengths policy requiring passkey for privileged roles
Enforce: Conditional Access policy → require authentication strength “Phishing-resistant MFA”

The critical policy: mark passkey as the only allowed method for privileged access. No SMS fallback for Global Admins.

No Fallback = The Actual Security

The protection passkeys provide is conditional on not having a weaker alternative. Deployment recommendations:

Privileged accounts: passkey-only, no fallback, hardware security key required
Standard employees: passkey primary, allow TOTP fallback (not SMS)
Never: SMS OTP as fallback for any production system handling sensitive data
Enrollment flow: require in-person or out-of-band verification before issuing passkeys to new employees

Legacy Systems

Many enterprise applications don’t support passkeys or FIDO2 at all. The realistic migration path:

Identify all authentication touchpoints (SSO, VPN, email, SaaS apps, internal tools)
Prioritize: most sensitive systems first
Use identity provider passthrough (Okta, Entra, Ping) to add passkey support to SAML/OIDC applications without modifying them
For truly legacy systems that can’t be updated: isolate them behind a jump host that does enforce passkey authentication

Compliance Alignment

Passkeys naturally satisfy several compliance requirements that are otherwise difficult to meet:

Standard	Requirement	Passkey alignment
NIST 800-63B	AAL2/AAL3 phishing-resistant authentication	FIDO2 is explicitly listed as meeting AAL2
PCI DSS 4.0	MFA for all access to cardholder data environments	Passkeys satisfy requirement 8.4.2
GDPR	Appropriate technical measures for data protection	Eliminates password database breach risk
SOC 2	Strong access controls	Passes CC6.1 access control criteria

What You Can Do Today

If you’re deploying passkeys:

Enable passkeys in Entra ID / Okta / your IdP — most are production-ready now
Require phishing-resistant MFA via Conditional Access for all privileged roles immediately
Audit fallback methods — eliminate SMS OTP wherever possible, replace with TOTP or no fallback
For crown-jewel accounts (global admin, billing, production deploy): hardware security key, no exceptions
Test your fallback flows — are they phishable? If yes, that’s your real attack surface

If you’re red-teaming passkey deployments:

Enumerate fallback authentication methods
Target the support/help desk account reset workflow — it often bypasses passkey requirements
Check for “remember this device” tokens — sometimes long-lived cookies survive passkey requirements
Test for downgrade prompts in the authentication UI

AiTM Phishing and MFA Bypass with EvilGinx — how attackers bypass traditional MFA that passkeys are designed to replace
Entra ID Attacks: Device Code Phishing, PRT Theft, and Conditional Access Bypass — device code flow and PRT attacks that passkeys partially mitigate
Identity-First Attacks in Cloud — the broader identity threat landscape passkeys fit into
Zero Trust vs. Real Attacks — passkeys are a core zero-trust authentication control