Passkeys, Two Years In: What Your Enterprise Rollout Actually Looks Like
Two years ago, every security keynote had a slide about passkeys. The slide was clean. The roadmap was inevitable. SMS-based MFA was a relic; passkeys were the future. By 2026, passkeys ARE the future, which is great, except they're also the present, which is messier.
Here is the actual report from the enterprise rollout trenches, written by someone who has answered the ticket and lived to tell about it.
What works (and it's a lot)
For users on a single Apple device or a single Google device with iCloud / Google Password Manager turned on, the experience is genuinely seamless. Tap to authenticate. No code. No app. No "did you get the SMS?" The login bar that used to take 45 seconds takes 4.
For first-time enrollment on a corporate-issued device pre-joined to the tenant, the process is invisible — passkey created on first sign-in, synced to the platform vault, done. The helpdesk ticket volume for first-time MFA setup is down something like 70% compared to the old SMS + authenticator-app combo. This part lives up to the marketing.
What doesn't work (and what makes the helpdesk ring)
Three categories of tickets that did not exist in 2023 now show up every week:
- Cross-ecosystem grief. The user enrolled the passkey on their iPhone (iCloud Keychain). They are now trying to sign in on their corporate Windows laptop. The passkey is, technically, on the iPhone in their bag. The sign-in flow asks them to authenticate on "another device". They do not understand. You do not blame them.
- Lost device, no escrow. The phone is at the bottom of a lake. The passkey was synced to iCloud, but the user's iCloud is their personal Apple ID, which is on a recovery email they last accessed in 2019. The recovery path goes through Apple's process, which takes days. Meanwhile, they need to file expenses.
- Cross-vendor lock-in. The passkey lives in iCloud Keychain. The user is leaving Apple for an Android device (or vice versa). The passkey does not portably migrate. Officially this is "solved" by the FIDO Credential Exchange Protocol. Unofficially, the helpdesk gets to explain to the user that they need to re-enroll on every site, one at a time.
The patterns that work in production
For an enterprise serious about passkeys, three operational decisions separate a smooth rollout from a series of awkward all-hands meetings:
- Issue platform-managed passkeys, not user-managed ones. If the passkey lives in Entra ID or Okta's vault rather than the user's personal iCloud, recovery is an IT problem (with an IT-grade SLA) instead of an Apple Support problem.
- Enroll a second factor at the same time as the passkey. A FIDO2 hardware key, an authenticator app, or a backup passkey on a different device. "One passkey, no backup" is the configuration that produces the bad-day ticket.
- Write the recovery runbook before the rollout, not after. The day someone loses their only enrolled device, you do not want to be deciding on policy in a Slack thread.
The honest summary
Passkeys are a real improvement. They are also still a 2.0 product in an enterprise context, which means the helpdesk now answers a different set of questions than it did two years ago. Same volume of confused users; different vocabulary. Plan the recovery story; budget the cross-device support; and stop telling your CISO that passkeys are "set and forget" — they are, until they aren't.