Passkeys are one of those technologies that sound simple on paper.
Turn them on.Users register them.Passwords go away.Everyone is more secure.
But in the real world, passkey rollouts are not just an authentication setting. They are a product rollout, a user experience change, a support change, and an operational change all at once.
In this episode, I spoke with Vincent Delitz from Corbado, who has worked on large-scale passkey deployments in customer identity scenarios, including public-sector and consumer environments with millions of users. While the examples come from the CIAM world, many of the lessons apply directly to workforce identity and Microsoft Entra deployments as well.
Sponsored by:
Cloud RADIUS built for Entra + Intune environments
EZRADIUS was designed and built by ex-Microsoft engineers with deep Entra and Intune experience. It integrates seamlessly into the Microsoft ecosystem, making it easy to migrate from your on-prem NPS server to a modern, zero-trust network with full support for cloud-first and hybrid environments.
* Deploy in minutes: no on-prem servers, no Windows updates
* Certificate-based auth: EAP-TLS support for Microsoft Cloud PKI or any CA
* Intune compliance checks for zero-trust Wi-Fi and VPN access
* Built for teams of 10 to 10,000: no minimums, no enterprise gatekeeping
* Pay only for users that connect with usage-based pricing
Start your 30-day trial (no credit card required) or book a demo to see how “EZ” it is.
Here are five practical lessons from the conversation.
1. Know why you are rolling out passkeys
Before you start the rollout, be clear on the reason.
Most organisations adopt passkeys for one or more of these reasons:
SecurityPasskeys are phishing-resistant and remove many of the risks that come with passwords, SMS OTP, and other phishable methods.
User experienceSigning in with Face ID, Touch ID, Windows Hello, or a security key can be faster and easier than typing passwords and completing MFA prompts.
Cost reductionIn customer identity scenarios, passkeys can reduce SMS OTP costs. In workforce scenarios, they can reduce password reset and sign-in related help desk calls.
The key lesson is this: your rollout strategy should match your goal.
If your goal is security, you need to think about when and how to retire phishable methods.If your goal is adoption, you need to make passkeys the easiest path.If your goal is cost reduction, you need to measure whether users are actually moving away from the older methods.
Simply enabling passkeys is not the same as achieving the outcome.
2. Use a staged rollout, not a big bang
One of the biggest mistakes is assuming you can turn on passkeys and immediately remove passwords.
That sounds clean from a security perspective, but in reality it can create confusion, support tickets, and failed sign-ins.
A better model is a staged rollout:
Stage 1: Offer passkeys as an option
Start by making passkeys available. Let users register and begin using them without taking away existing methods immediately.
Stage 2: Nudge adoption
Do not leave passkeys buried as “just another sign-in method.” Make them visible. Make them the preferred option where possible. Help users understand why they should use them.
Stage 3: Gradually retire phishable methods
Once you can see that a user or group has been successfully using passkeys for a period of time, then you can start reducing reliance on passwords, SMS, or other weaker methods.
Stage 4: Fix recovery
This is the part many teams forget.
Once passkeys become the primary sign-in method, account recovery becomes the new weak point. If recovery still relies on phishable methods or manual help desk processes, attackers will target that path instead.
A passkey rollout is not complete until recovery is also secure.
3. Passkeys move complexity from the backend to the user’s device
With passwords, SMS OTP, or push notifications, a lot of the complexity sits in the backend.
With passkeys, much more happens on the client side.
That means success depends on things like:
The user’s device.The browser version.The operating system.The credential manager.Whether Bluetooth is enabled.Whether the passkey is synced.Whether the user is on a managed device or BYOD.Whether a password manager has changed the sign-in experience.
This is a big mindset shift.
For example, cross-device passkey sign-in often relies on Bluetooth proximity checks. That is great when it works. But what happens if Bluetooth is disabled on a kiosk, blocked by policy, or unavailable on a shared device?
In the episode, we discussed a real-world example where a rollout assumed passkeys would work for retail staff using shared kiosks, only to discover later that Bluetooth was disabled in that environment.
That is the sort of issue you want to find before go-live, not after a three-month project.
The practical takeaway: test the real environments your users will sign in from. Not just your own managed test devices.
4. Your backend logs may not tell the full story
This was one of the most important lessons from the episode.
Passkey success rates can look great in backend logs, but still miss a large part of the user experience.
Why?
Because many failures happen before the backend sees anything useful.
A user may not have the passkey on the current device.The credential manager may not appear.The browser may have a bug.The user may cancel the Face ID or Touch ID prompt.The passkey may have been deleted locally.The device may try to use the wrong credential manager.The user may think registration worked, even though the backend blocked it.
From the backend, you might only see the successful challenges. That can make your success rate look much better than the lived experience.
This is why observability matters.
For customer identity platforms, you may be able to add frontend telemetry and track where users get stuck. In workforce scenarios, you may not be able to instrument the Entra sign-in page directly, but you can still look for signals elsewhere:
Which users are passkey-capable?Which devices and browsers are being used?Which users registered passkeys but are not using them?Which support tickets map to specific OS, browser, or credential manager combinations?Which groups are still falling back to passwords or SMS?
The lesson: do not rely on a single “success rate” number. It may hide the real rollout problems.
5. Support multiple passkeys and explain the mental model
A common mistake is limiting users to one passkey.
That may sound tidy, but it does not match how people actually work.
A user may have a Windows laptop, a Mac, an iPhone, an Android phone, a password manager, and a physical security key. Some passkeys sync. Some do not. Some are device-bound. Some are stored in iCloud Keychain, Google Password Manager, Bitwarden, 1Password, Windows Hello, or on a physical key.
If users can only register one passkey, they may be locked out when they move to another device.
A better approach is to allow multiple passkeys and make it clear what each one is for.
For example:
One passkey in iCloud Keychain.One in Google Password Manager.One in an enterprise password manager.One physical security key.One backup key for critical accounts.
This also means communication matters.
Users do not always understand terms like “FIDO2,” “WebAuthn,” “AAGUID,” “attestation,” or even “passkey.” They understand things like:
Sign in with your face.Sign in with your fingerprint.Use your security key.Use the passkey saved on this device.
The more technical your language, the more likely users are to get confused.
This applies internally as well. Even project teams need a shared vocabulary. Are you talking about synced passkeys? Device-bound passkeys? Security keys? Windows Hello for Business? Platform credentials? Roaming authenticators?
If the project team is confused, the users definitely will be.
Bonus lesson: Attestation matters, but not for every user
We also discussed attestation, which is one of those topics that can get confusing quickly.
In simple terms, attestation lets an authenticator prove what type of device or security key it is. This is useful when you want to control exactly which authenticators are allowed.
For example, for privileged admins, you may want to require specific physical security keys issued by the organisation. In that case, attestation can help you enforce that only approved keys are used.
But synced passkeys are different.
If a passkey is stored in iCloud Keychain, Google Password Manager, Bitwarden, or another synced credential manager, it can move across devices. That breaks the model where you can prove it belongs to one specific physical authenticator.
So the practical model may be:
Use stricter device-bound passkeys and attestation for privileged users.Allow synced passkeys for broader user populations where usability and adoption matter more.Be clear about the trade-off.
Synced passkeys may not give you the same level of device control as a hardware key, but they are still a huge improvement over passwords and many phishable MFA methods.
Final thoughts
The big takeaway from this episode is that passkey success is not just about enabling the feature.
You need to plan for adoption, device readiness, recovery, support, telemetry, and user education.
Passkeys can absolutely improve security and user experience, but only if the rollout is treated as a real change program.
The teams that succeed will be the ones that ask the hard questions early:
Why are we rolling this out?Which users are ready?Which devices are not?What will break on day two?How will users recover access?How will we know whether adoption is actually happening?
Passkeys are the future of authentication, but the rollout still needs careful planning.
Subscribe with your favorite podcast player or watch on YouTube 👇
About Vincent Delitz
Vincent Delitz is the Co-founder and Managing Director at Corbado, the passkey intelligence platform designed specifically for enterprise CIAM teams. Based in Munich, Vincent is a software engineer turned founder who has been deeply focused on the technology since the term “passkeys” first emerged in 2022.
Through Corbado, he helps large-scale B2C enterprises understand why passkey adoption might be flat, identify what’s breaking logins, and successfully scale passkeys alongside their existing IDPs (including Entra, Okta, Auth0, Ping, ForgeRock, or in-house solutions). Corbado is trusted by major organizations like VicRoads (supporting 5 million users), as well as leaders in financial services and e-commerce. As a speaker, Vincent frequently shares his expertise on passkey adoption and the often-overlooked “Day 2” passkey problems that don’t appear in standard vendor documentation.
LinkedIn - https://www.linkedin.com/in/vincent-delitz/
🔗 Related Links
* How to enable passkeys (FIDO2) in Microsoft Entra ID - https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2
* Enterprise Passkey Deployment Challenges - https://www.corbado.com/blog/enterprise-passkey-deployment-challenges
* Corbado - https://www.corbado.com/
📗 Chapters
04:10 The Consumer vs. Workforce Scale
07:49 Uncovering the True Motivations for Passkeys
11:06 The Four Stages of Going Passwordless
12:51 Day 2 Problems and Implementation Hurdles
17:02 Real-World Device and Network Limitations
22:53 Why Passkey Success Rates Are Misleading
27:20 Best Practices for Large-Scale Deployments
32:16 Demystifying Passkey Attestation and AGUIDs
38:48 Handling Support Tickets and Adoption Strategies
Podcast Apps
🎙️ Entra.Chat - https://entra.chat
🎧 Apple Podcast → https://entra.chat/apple
📺 YouTube → https://entra.chat/youtube
📺 Spotify → https://entra.chat/spotify
🎧 Overcast → https://entra.chat/overcast
🎧 Pocketcast → https://entra.chat/pocketcast
🎧 Others → https://entra.chat/rss
Merill’s socials
📺 YouTube → youtube.com/@merillx
👔 LinkedIn → linkedin.com/in/merill
🐤 Twitter → twitter.com/merill
🕺 TikTok → tiktok.com/@merillf
🦋 Bluesky → bsky.app/profile/merill.net
🐘 Mastodon → infosec.exchange/@merill
🧵 Threads → threads.net/@merillf
🤖 GitHub → github.com/merill
Get full access to Entra.News - Your weekly dose of Microsoft Entra at entra.news/subscribe
South Africa