You're getting questions about passkeys. Your security team wants to know if they're ready. Your developers are asking how they work. Your CISO is asking what happens to your existing MFA stack. These questions come from real migration planning, not vendor decks.
I've compiled the questions that keep showing up in IAM architecture channels and incident post-mortems. Here's what practitioners are actually asking when they evaluate passkey deployment.
The Source of These Questions
A dataset surfaced in mid-2025 containing about 16 billion stolen login credentials. These records span platforms like Google, Apple, and Meta. No sophisticated zero-day exploit or nation-state campaign was involved. It was the result of infostealer malware, phishing, and breaches targeting password-based authentication.
This dataset highlights the failure of a system built on shared secrets. Passwords failed gradually, then all at once. The questions below reflect what teams face when they decide that "better password policies" aren't enough anymore.
Q1: How Do Passkeys Stop Phishing?
Passkeys use FIDO2 and public-key cryptography bound to the origin domain. When you authenticate, your device signs a challenge with a private key that never leaves the hardware. The signature includes the domain you're authenticating to.
If an attacker clones your login page at evil-bank[.]com, the passkey won't work. The domain binding fails. There's no credential to phish because the user never possesses a transferable secret. The attacker can't replay the signature because it's tied to the legitimate domain.
This differs from One-Time Passwords or SMS codes, which users can read and enter on a phishing site. Passkeys make the authentication process itself phishing-resistant.
Q2: Do We Need to Replace Our Entire MFA Stack?
No. You'll run a hybrid authentication environment for at least the next two years.
Start with passkey enrollment as an option alongside your existing Time-Based One-Time Password or Multi-Factor Cryptographic Device flows. Let users opt in. Monitor adoption rates and support burden. Most identity platforms now support FIDO2 as an additional authentication method without removing legacy factors.
The transition looks like this: passkeys become the preferred method for new enrollments, while legacy MFA remains available for accounts that can't support FIDO2. You'll carry both for a while. That's expected.
Don't try to force a flag-day cutover. You'll break service accounts, legacy applications, and API authentication flows that can't present a biometric or Multi-Factor Cryptographic Device.
Q3: What About Service Accounts and API Keys?
Passkeys solve human authentication. They don't replace API keys, OAuth 2.0 client credentials, or machine-to-machine authentication flows.
Your service accounts still need secrets. The difference is you're now protecting human access to those secrets differently. When an engineer needs to rotate an API key or access the vault containing service credentials, that action can require passkey authentication. You're reducing the human attack surface while leaving machine authentication patterns intact.
If you're using Just-in-Time Elevation for privileged access, passkey authentication can gate the elevation request. The service account itself still uses a client certificate or hashed secret for its API calls.
Q4: Can We Enforce Passkeys for Third-Party SaaS Apps?
Only if the SaaS provider supports FIDO2 and your federation protocol passes the WebAuthn assertion.
If you federate access through SAML or OAuth 2.0, you can require passkey authentication at your Identity Provider. The SaaS app receives the assertion without knowing how the user authenticated. This works for most cloud applications.
The gap appears with applications that require direct login or don't support federation. Legacy on-premise tools, vendor portals that predate SSO, and applications with hard-coded local authentication can't be forced to adopt passkeys. Document these as exceptions and apply compensating controls like network segmentation or Just-in-Time Provisioning with short session lifetimes.
Q5: How Do We Handle Account Recovery if a Passkey is Lost?
You need a recovery flow that doesn't reintroduce vulnerabilities.
Bad recovery: fallback to SMS or email one-time codes. You've just created a phishing vector.
Better recovery: require multiple passkeys enrolled per user. Prompt for a secondary device during registration. If they lose their phone, they authenticate with their hardware security key or laptop.
Best recovery: account recovery requires identity verification through an out-of-band process. The user contacts your helpdesk, proves identity through multiple factors, and re-enrolls. It's slower but not automatable by an attacker who compromised an email account.
The FIDO Alliance doesn't mandate a specific recovery mechanism. That's your policy decision. Make it match your threat model.
Q6: What's the User Experience Like?
Initial enrollment takes about 30 seconds: user clicks "Add passkey," authenticates with their device biometric or PIN, done. Subsequent logins are faster than typing a password.
The support burden comes from users who don't understand what changed. They expect to type something. When the browser prompts for a fingerprint instead, they assume it's broken. Your communication matters more than the technical deployment.
Run a pilot with your IT team first. Let them experience the enrollment and authentication flow. Collect their questions. Build your FAQ and training materials from real user confusion.
Expect support volume to spike during the first two weeks of rollout, then drop below your current password-reset ticket volume. Users who authenticate with biometrics don't forget their biometrics.
Next Steps
If you're evaluating passkey deployment, start with the FIDO Alliance technical specifications and implementation guidance. They publish reference architectures for enterprise environments.
Test your identity platform's FIDO2 support in a non-production environment. Verify that your session management, Delegated Authorization flows, and compliance logging still work when the authentication method changes.
Accept that you're not eliminating passwords next quarter. You're starting a multi-year transition away from a system that's been leaking credentials for two decades. The 16 billion records in that dataset didn't appear overnight. Your migration won't finish overnight either.
