The identity problem that passwords and “classic MFA” don’t solve anymore
Credential phishing and session theft have converged into a modern, repeatable intrusion path: steal a password (or a one-time code), then steal or replay the session token/cookie to bypass future prompts. Verizon’s DBIR has repeatedly underscored how quickly users can be tricked—its 2024 report notes the median time for users to fall for phishing emails is under 60 seconds.
At the same time, large-scale “infostealer” malware ecosystems and adversary-in-the-middle (AiTM) phishing kits have made it easier to capture credentials and session artifacts. The defensive takeaway: improving passwords and adding SMS/app OTPs helps, but it doesn’t reliably stop phishing-driven account takeover.
What is phishing-resistant authentication?
Phishing-resistant authentication is a login method that cannot be successfully replayed by an attacker who tricks a user into entering secrets into a fake site. In practice, widely deployed phishing-resistant authentication is built on FIDO2/WebAuthn (including passkeys and security keys), which ties authentication to the legitimate origin (the real website/app) and uses public-key cryptography instead of reusable shared secrets.
That origin-binding property is exactly what many OTP and push-approval flows lack—attackers can proxy them in real time.
Why is phishing-resistant MFA important?
Phishing-resistant MFA matters because the most common account takeover campaigns exploit human behavior and protocol gaps, not password complexity. When a user can be tricked into “approving” a login or typing a code into a convincing fake site, attackers can scale credential theft. CISA explicitly urges organizations to move toward phishing-resistant MFA (not just “any MFA”) as part of modern, Zero Trust-aligned defense.
The shift is also reflected in standards: NIST’s updated Digital Identity Guidelines (SP 800-63-4) incorporate modern authenticator realities, including syncable authenticators (e.g., synced passkeys).
What are passkeys, and why are they “new” in enterprise best practice?
Passkeys are FIDO credentials that use a device-held private key (often protected by secure hardware) and a corresponding public key registered with a service. They can be stored on-device (platform passkeys) or synced via an OS/password manager ecosystem (syncable passkeys). They are “new” as a best practice not because FIDO is brand-new, but because passkeys have reached broad consumer and enterprise platform support and are now being baked into identity programs as a default direction of travel.
Signals of maturity and adoption:
Google reported passkeys were used for 1+ billion authentications across 400+ million Google Accounts within less than a year of rollout, highlighting both usability and scale.
The FIDO Alliance reported rapid expansion in passkey-capable accounts and deployments across major platforms and services (illustrating ecosystem readiness).
Microsoft documentation positions Windows Hello for Business and FIDO/WebAuthn as phish-resistant options, aligning endpoint sign-in and web sign-in under the same model.
How does passkey authentication work?
Passkeys work by creating a unique cryptographic key pair per service: the private key stays on the user’s device (or within a synced credential store), and the public key is stored by the service. During login, the service sends a challenge that only the private key can sign; the signed response proves possession without exposing a reusable secret. Because WebAuthn binds credentials to the real site/app origin, a fake login page can’t successfully use the credential the way it can with passwords or OTPs.
Operationally, that means:
No password to phish.
No OTP to relay via AiTM proxying.
Strong resistance to credential stuffing (there’s no shared password to reuse).
The “next layer”: device-bound sessions to reduce stolen-cookie and token replay
Even with phishing-resistant login, many real-world takeovers happen after authentication—through stolen session cookies, refresh tokens, or OAuth artifacts harvested from endpoints. That’s why an “interesting new” emerging best practice pairs passkeys with device-bound sessions: cryptographically linking session material to a device so it can’t be replayed elsewhere.
You can think of this as the identity equivalent of “non-exportable keys”: the attacker may steal a cookie value, but without the device-bound key it’s useless off-device. This approach is appearing in enterprise roadmaps (for example, Google’s work on device-bound session credentials in Workspace contexts has been discussed publicly in industry reporting).
What are the risks of passkeys?
Passkeys materially reduce phishing risk, but they introduce new operational and governance considerations:
Account recovery risk: If users lose devices, recovery processes become higher-stakes and must be hardened to prevent social engineering.
Syncable passkeys governance: Synced passkeys improve usability, but you must evaluate how your OS/platform sync model affects threat scenarios and assurance expectations—an area directly acknowledged in modern guidance (e.g., NIST SP 800-63-4’s treatment of syncable authenticators).
Legacy app gaps: Older applications may not support WebAuthn, requiring phased migration and compensating controls.
Device trust requirements: Device-bound sessions assume you can establish endpoint health/attestation signals and manage keys securely.
The net effect is positive for security—but only if rollout includes policy, recovery, and endpoint readiness.
A practical comparison: common MFA methods vs phishing resistance
| Authentication method | Phishing-resistant? | Common failure mode | Where it still fits |
|---|---|---|---|
| SMS OTP | No | SIM swap, OTP relay, social engineering | Low-risk consumer use; not for high-value accounts |
| TOTP app codes | No (generally) | AiTM relay, code reuse within window | Transitional step; better than SMS |
| Push “approve/deny” | No (often) | MFA fatigue / push bombing, AiTM proxy | Use with number matching + strict policies |
| FIDO2/WebAuthn security keys | Yes | Loss/recovery processes | High assurance, admins, privileged access |
| Passkeys (platform/syncable) | Yes | Recovery & device governance | Broad workforce deployment |
| Passkeys + device-bound sessions | Strongest practical | Endpoint compromise still matters | High-value SaaS, email, finance, admin planes |
What are the best practices for deploying passkeys in an enterprise?
Start by treating this as an identity program, not a feature toggle. CISA’s phishing-resistant MFA guidance is a strong baseline for defender-focused rollout planning.
Recommended best practices (defensive, configuration-focused):
Prioritize high-impact systems first: email, VPN/ZTNA, HR/payroll, source control, cloud consoles, admin portals.
Use FIDO2/WebAuthn as the phishing-resistant standard: prefer passkeys/security keys over OTP-based MFA for privileged and high-risk users.
Define assurance tiers: e.g., “security key required” for admins; “platform passkey allowed” for general workforce; “passwordless preferred” everywhere.
Harden account recovery: require strong identity verification, limit helpdesk overrides, add cooling-off periods for sensitive changes, and log/alert on recovery events.
Make enrollment frictionless but controlled: pre-stage device readiness (OS versions, MDM baselines), publish clear UX guides, and measure adoption.
Instrument and enforce: conditional access rules, impossible travel checks, risk-based step-up, and explicit blocks for legacy protocols where feasible.
Plan for exceptions: shared service accounts should be eliminated or vaulted; where unavoidable, use PAM, just-in-time access, and tight monitoring.
How to operationalize device-bound sessions without breaking everything
Device-bound sessions are easiest when you already have:
Managed endpoints (MDM/EDR) with reliable device identity
Modern browsers and clients
Centralized IdP that can enforce token/session policies
Defensive rollout patterns:
Bind “high-value” sessions first: admin consoles, email, finance, HR. Start with short session lifetimes and step-up for risky actions.
Combine with endpoint posture: only issue durable sessions to compliant devices; degrade gracefully to shorter sessions or additional prompts elsewhere.
Monitor for token replay signals: session use from new devices, abnormal geolocation, user-agent anomalies, and sudden token refresh spikes.
Keep break-glass paths separate: emergency access accounts should use hardware-backed methods and be heavily monitored.
This doesn’t remove the need for endpoint security—if the device is compromised, the attacker may still act as the user on that device—but it significantly reduces off-device replay at scale.
Real-world implementation notes defenders overlook
Privileged access is the forcing function: If you require phishing-resistant auth for admins (cloud, IAM, CI/CD, EDR consoles), you cut off the highest-impact path first.
Email is the keystone system: Many intrusions start with mailbox access and reset flows; passkeys reduce that exposure.
Helpdesk is part of the attack surface: Social engineering targets recovery and enrollment exceptions. Treat identity ops as a security control, not just IT support.
Metrics matter: Track “% of sign-ins using phishing-resistant methods,” recovery event rates, blocked legacy auth attempts, and token replay detections.
Where standards and guidance are headed next
NIST SP 800-63-4’s modernizations (including explicit treatment of syncable authenticators) indicate identity assurance models are adapting to the passkey era rather than resisting it.
Meanwhile, government and critical-infrastructure guidance increasingly frames phishing-resistant MFA as a baseline control rather than an aspirational upgrade.
The likely near-term trajectory for enterprise best practice:
Passwordless-first for the majority of users
Hardware-backed phishing-resistant auth for privileged access
Increasing use of device-bound sessions and continuous evaluation signals
Tighter coupling between identity, device health, and application session policies
What is the simplest “next step” to adopt this best practice?
The simplest next step is to require phishing-resistant authentication (FIDO2/WebAuthn passkeys or security keys) for your highest-value user groups and systems—admins, finance, and email—then expand enrollment to the broader workforce while hardening recovery and helpdesk processes. Pair this with stricter session controls (shorter lifetimes, step-up for risky actions) and a roadmap toward device-bound sessions for critical apps.