Passkeys are no longer a distant authentication idea.
Users are seeing them in mobile apps, browsers, password managers, enterprise tools, and consumer platforms. Identity providers are improving the settings that make passkey behavior more predictable across devices and ecosystems.
That does not mean every SaaS product should remove passwords immediately.
The better decision is more practical:
Where should passkeys sit in the sign-in flow, and what fallback should remain when they do not work for a user?
That is the useful signal from Keycloak 26.7.0.
What changed
Keycloak 26.7.0 added better passkey compatibility through new WebAuthn policy options.
The important change is the new Discoverable credential setting.
Instead of the older yes-or-no style option, Keycloak now supports values that match the current WebAuthn specification:
- required
- preferred
- discouraged
This matters because passkeys depend on the server telling the browser whether it wants a discoverable credential, which is often stored on the user’s device or password manager.
Keycloak says this improves compatibility with passkey providers such as iCloud Keychain, Google Password Manager, and 1Password.
The older Require Discoverable Credential option is now deprecated and planned for removal in a future release.
This is a technical change, but the product consequence is bigger:
Passkey rollout is becoming less about whether the technology exists and more about how carefully the product handles the transition.
Why this matters for SaaS teams
Authentication is not only a security layer.
It is part of the product experience.
If sign-in is too weak, the product carries security risk.
If sign-in is too difficult, users abandon the workflow, contact support, or create account recovery problems.
Passkeys can improve phishing resistance and reduce password friction. But they also introduce product questions that teams should answer before making them the default.
A user may be on a shared device.
A customer may use an enterprise password manager.
A team member may lose access to a device.
A browser may not support the same flow.
An admin may need to recover access for a user.
A legacy customer may still rely on password plus MFA.
So the decision is not simply:
Should we support passkeys?
The better question is:
How do we introduce passkeys without breaking access, trust, or support workflows?
The 6-check passkey rollout decision
1. User fit
Start with who uses the product.
A passkey rollout for a consumer mobile app is different from a rollout for an enterprise SaaS product, internal admin portal, developer tool, or healthcare platform.
Ask:
- Are users mostly on personal devices?
- Do they use managed corporate devices?
- Do they switch devices often?
- Do admins need centralized recovery?
- Are users technical or nontechnical?
- Are accounts shared by teams?
Passkeys work best when the product understands the user context.
2. Compatibility path
Passkey behavior depends on the browser, device, identity provider, password manager, and WebAuthn settings.
A product team should test common environments before rollout:
- iOS and macOS
- Android
- Windows
- Chrome
- Safari
- Edge
- Google Password Manager
- iCloud Keychain
- 1Password or enterprise password managers
The point is not to test every possible setup.
The point is to avoid treating one successful flow as proof that the rollout is ready for all users.
3. Fallback and recovery
This is the most important product question.
What happens when passkey sign-in fails?
A safe rollout should define:
- backup authentication method,
- account recovery flow,
- admin-assisted recovery,
- lost-device handling,
- new-device setup,
- support escalation,
- and identity verification steps.
A passkey feature is incomplete without recovery.
Users do not only judge authentication when it works. They judge it when they are locked out.
4. Rollout sequence
Passkeys do not need to replace passwords in one step.
A staged rollout can reduce risk:
- Offer passkeys as an optional sign-in method.
- Encourage enrollment after successful login.
- Make passkeys the preferred method for lower-risk accounts.
- Require passkeys for admins or high-risk roles.
- Phase down passwords only after recovery and support data are strong.
The rollout should match risk and user readiness.
5. Security policy
Passkeys can reduce phishing risk, but they still need policy decisions.
Teams should decide:
- which roles require passkeys,
- whether passkeys replace or complement MFA,
- what happens for shared accounts,
- how admin accounts are protected,
- whether device-bound or synced passkeys are allowed,
- and how suspicious sign-in attempts are handled.
The security policy should be clear enough for product, support, and customer success teams to explain.
6. Measurement
Teams should measure passkey rollout like a product change, not only a security setting.
Useful metrics include:
- passkey enrollment rate,
- successful passkey sign-ins,
- failed sign-in attempts,
- account recovery requests,
- password reset volume,
- support tickets,
- user drop-off during sign-in,
- admin adoption,
- and risky login patterns.
If passkeys reduce security risk but increase lockouts, the rollout needs adjustment.
When to move now
A SaaS product should consider moving now when:
- users already use modern devices and browsers,
- account security matters,
- phishing risk is meaningful,
- support can handle recovery,
- the identity provider supports proper WebAuthn settings,
- and the product can roll out gradually.
This is especially relevant for admin portals, financial workflows, developer tools, internal systems, customer dashboards, and high-value accounts.
When to move more carefully
Teams should slow down when:
- many users share accounts,
- recovery is weak,
- mobile and desktop flows differ too much,
- support teams are not prepared,
- enterprise customers require specific identity policies,
- or legacy authentication is deeply tied into the product.
Moving carefully does not mean ignoring passkeys.
It means introducing them with the right fallback and support model.
A simple rollout plan
A practical rollout can start like this:
Phase 1: Optional enrollment
Let users add a passkey after a successful password login.
Use this phase to test compatibility and support load.
Phase 2: Preferred sign-in
Promote passkeys on the login screen and reduce password reliance for users who enroll.
Measure completion rate and recovery friction.
Phase 3: Required for sensitive roles
Require passkeys for admins, finance roles, security roles, or high-risk workflows.
Keep a strong recovery path.
Phase 4: Password reduction
Only reduce password-first sign-in after the team has enough data on adoption, recovery, support, and customer readiness.
Founder takeaway
Passkeys are becoming more practical.
But the product decision is not only “turn them on.”
The decision is:
- who should use them first,
- which devices and providers must work,
- what fallback remains,
- who owns recovery,
- and what data proves the rollout is working.
A stronger sign-in method should not create a weaker access experience.
The right passkey rollout improves security and keeps users able to complete the product workflow.
SOCIAL SHARE CARD GENERATOR