These questions come from authentication working groups, fraud team Slack channels, and implementation calls I've been part of over the past six months. The conversation usually starts with "our CISO wants passkeys" and quickly turns into "but how does this actually work with our existing flows?"
The pressure is real. Nearly half of consumers would close a longstanding bank account because of fraud, and your competitors are shipping passkey support. But the gap between "we should do this" and "we've done this" is filled with practical questions about device trust, fallback flows, and what happens when someone loses their phone.
Here's what teams are actually asking.
Do We Need to Support Both Hardware-Bound and Sync Passkeys?
You'll need both, but for different risk contexts.
Hardware-bound passkeys are generated and stored on a secure piece of hardware, like the user's device or a payment card. These don't sync across devices. They're your control for medium- to high-risk transactions: wire transfers, account detail changes, adding external accounts.
Sync passkeys live in the cloud (iCloud Keychain, Google Password Manager). They're convenient because they follow the user across devices, but they're exposed to infostealer malware that captures browsing data and active sessions. Use these for low- to medium-risk actions like checking balances or viewing statements.
The risk model should drive the requirement. If you're authenticating a $50,000 wire, you want proof the user holds a specific trusted device. If they're checking their balance on a new laptop, a sync passkey gets them in without friction.
Don't make the mistake of treating all passkeys as equally secure. The cryptographic primitive is the same; the attack surface isn't.
What's Our Fallback When Someone Doesn't Have a Passkey-Capable Device?
You'll run a mixed authentication environment for at least two years. Not everyone upgrades to the latest iPhone or Pixel on launch day, and some users will actively resist change.
Your fallback options:
- SMS OTP (weakest, but universally supported)
- TOTP authenticator apps (better, requires setup)
- Push notification to a registered device (good middle ground)
Make passkey enrollment the path of least resistance during the next natural interaction. When a user logs in with a password + OTP and they're on a passkey-capable device, show them a one-tap enrollment flow. Don't hide it in account settings.
Track your passkey adoption rate by cohort. You'll see faster uptake among mobile-first users and slower movement among desktop-heavy segments. Adjust your messaging and nudges accordingly.
How Do We Handle Device Provisioning When Someone Gets a New Phone?
This is where hardware-bound passkeys on payment cards solve a real problem. A user taps their card on the new device, and the card provisions a new local passkey. It's fast, secure, and doesn't require the user to remember anything or contact support.
Without that physical anchor, you're back to account recovery flows: email verification, SMS codes, knowledge-based authentication questions. These work, but they reintroduce the friction you were trying to eliminate.
The alternative is sync passkeys, which automatically appear on the new device if the user is signed into their cloud account. This is seamless but comes with the infostealer risk mentioned earlier. For high-value accounts, you want device-specific proof of possession.
What Happens If Someone's Passkey Gets Compromised?
The threat model is different from passwords. You can't phish a passkey because the user never sees the cryptographic material. The private key never leaves the device.
The real risks are device theft and malware. If someone steals an unlocked phone, they have access to whatever that passkey unlocks until you detect the anomaly and force re-authentication.
Your defenses:
- Device fingerprinting to detect logins from new hardware
- Velocity checks (multiple high-risk actions in short succession)
- Behavioral analytics (login location, time of day, typical transaction patterns)
- Step-up authentication for sensitive actions even after passkey login
Treat passkey authentication as the first gate, not the only gate. For wire transfers or account changes, you can still require a second factor or a time-delayed confirmation.
How Do We Explain This to Users Without Making It Sound Complicated?
Don't lead with cryptography. Lead with the outcome: faster login, no passwords to remember, better protection against fraud.
Your messaging should be:
- "Log in with your face or fingerprint" (not "authenticate with a FIDO2-compliant passkey")
- "We'll recognize this device next time" (not "we're storing a public key on our server")
- "This keeps your account safer than a password" (not "passkeys are resistant to phishing and credential stuffing")
Run the enrollment flow inline, not as a separate setup task. When a user logs in with a password, show them: "Want to skip this step next time? Set up quick login." One tap, done.
The users who want to understand the technical details will find your security documentation. Everyone else just wants to get into their account.
What's the Implementation Lift? Are We Talking Months or Quarters?
It depends on your existing authentication architecture. If you're already using WebAuthn for security keys or if you've built a modern identity provider integration, you're looking at weeks to add passkey support.
If you're running a legacy authentication system with hard-coded password flows, you're looking at a larger refactor. You'll need to:
- Add WebAuthn server-side support (libraries exist for most stacks)
- Update your mobile apps to call the platform authenticator APIs
- Build enrollment, management, and recovery flows
- Update your risk engine to handle passkey authentication events
- Train your support team on the new flows
The technical work isn't the long pole. The coordination across product, fraud, compliance, and support is. Start with a limited rollout to a low-risk segment (maybe just balance checks) and expand based on what you learn.
Where to Go for More
The FIDO Alliance publishes implementation guides and UX patterns. NIST SP 800-63B covers authentication assurance levels if you need to map passkey strength to your risk framework. For mobile implementation details, Apple's and Google's developer documentation is surprisingly clear.
If you're in a regulated environment, talk to your QSA or examiner early. Passkeys strengthen your authentication posture, but you'll want to document how they fit into your Multi-Factor Authentication controls and how you're handling account recovery.
The shift is happening whether you're ready or not. The question isn't whether to support passkeys, it's how fast you can ship them before your users start asking why your competitor's login is so much faster than yours.
