Passkey Day 2 Problems: 5 Risks after Launch

1. Introduction: Passkey Risks after Launch#

Don't implement passkeys.

At least not at all costs and not if you don't have the resources to do it properly.

Yes, passkeys are the best thing that happened to consumer authentication in a decade. Yes, they kill phishing. Yes, they can massively improve UX. But passkeys done wrong can cause a lot of harm as well.

Implementing a WebAuthn server is not too complex. The actual challenge is everything around it. Operating passkeys efficiently at scale needs planning ahead. You need to think about all the "Day 2" problems - the operational realities that only surface after you've started the passkey rollout.

This article covers five Day 2 problems that consistently kill passkey projects. If you can't solve all of them, you're not ready to ship passkeys. If you can, you'll build authentication that's both more secure and more usable than anything passwords could ever offer.

2. What are Passkey Day 2 Problems?#

In engineering, "Day 1" is when you build and ship. "Day 2" is when you operate, maintain and scale what you've shipped. For passkeys, Day 1 can be straightforward:

• integrate a WebAuthn server
• add the frontend flows and launch.

Most teams can get a basic passkey implementation running in a few days or weeks.

Day 2 is where projects fail. It's the moment real users on real devices with real edge cases interact with your passkey system. It's when you discover that the shiny demo that worked perfectly on your MacBook breaks on a Windows laptop running Chrome behind a corporate proxy. It's when your support team gets flooded with "I can't log in anymore" tickets.

The gap between a working passkey demo and a production-grade passkey deployment is enormous. We've covered the technical implementation pitfalls and the strategic reasons why passkey projects fail before. This article focuses specifically on what happens after you go live from an operations perspective.

Here are the five Day 2 problems we'll cover:

• Issue 1: Recovery and Fallback are hard to secure
• Issue 2: Cross-Device and Cross-Ecosystem Edge Cases break Passkey Flows
• Issue 3: Native Apps multiply Passkey Complexity
• Issue 4: Adoption is a Product Problem, not a Tech Problem
• Issue 5: Platform Changes break Passkeys silently

3. Issue 1: Recovery and Fallback are hard to secure#

If you don't design recovery and fallback properly, you either lock users out at scale or you quietly re-introduce the same phishing-prone flows you wanted to eliminate.

3.1 Account Lockout Risk at Scale#

Consider a user who registers a passkey on their iPhone, then loses that iPhone. Usually, a big chunk of these recovery cases is now being handled by the credential manager (most likely iCloud Keychain on iPhones). As long as the user has access to their Apple account, they have synced passkeys available to log in on a new device. But what if they don't have access to that cloud account anymore? This is when your regular recovery path comes into play.

Let's say you assume that the private key is still available on the device the user tries to log in from, so you start the WebAuthn login ceremony. This will result in an OS / browser modal asking the user to "log in with your passkey on another device". Basically, the user is now locked out of their account. Theree's no other device where the passkey is stored. The user is massively confused. Multiply this by thousands of users and you have a support crisis.

The common reaction is to add email-based account resets as a fallback. But this defeats the purpose of passkeys: you've just re-introduced a phishable recovery channel. An attacker who can compromise a user's email can now bypass your phishing-resistant passkey implementation entirely.

3.2 Designing Fallback without reintroducing Phishing#

In our opinion, the right approach is layered recovery:

1. Synced passkeys as the primary strategy: ensure users create synced passkeys (via iCloud Keychain, Google Password Manager or a third-party passkey provider) so that device loss doesn't mean credential loss
2. Cross-device authentication as a second layer: allow users to authenticate from another device where another passkey is available by scanning a QR code
3. Identity verification (IDV) as the third layer: offer automated IDV with liveness checks instead of falling back to passwords/OTPs.
4. Digital verifiable credentials as the fourth layer: it is the most secure, privacy-preserving and UX-friendly version of account recovery. This allows the user to use their digital verifiable credentials (e.g. digital national ID or mDL) to verify their identity by using standard APIs (e.g. Digital Credentials API). This technology is fairly new and adoption is not high but it will play a major role in the next months and years.

In general, you need to decide which layers of account recovery can be justified from a cost / friction perspective. For instance, in retail / e-commerce, you might just offer the first two layers and accept the phishing risk due to financial reasons. In other industries, where security is more important, you go to layer 3 and 4.

Each layer adds complexity. You need to decide which layers your use case requires, build them, test them across all device combinations and monitor their usage. This is significantly more work than the initial WebAuthn integration.

3.3 What most Teams get wrong#

Most teams either over-simplify recovery (falling back to passwords or SMS OTP) or over-complicate it (e.g. requiring hardware security keys for every recovery). The right balance depends on your threat model, user base and regulatory requirements. Getting it wrong means either undermining your security posture or creating so much friction that users abandon the flow.

4. Issue 2: Cross-Device and Cross-Ecosystem Edge Cases break Passkey Flows#

Your users don't live in a clean Apple-only world. They switch devices, mix Windows with iOS, use different browsers and work on corporate-managed setups. That's where passkey flows breaks if you haven't planned for it.

4.1 Ecosystem Fragmentation is real#

The passkey ecosystem spans three major platforms (Apple, Google and Microsoft), multiple browsers (Chrome, Safari, Firefox and Edge), dozens of passkey providers / credential managers (e.g. 1Password, Bitwarden, Dashlane and others) and countless OS/browser/device combinations. Each combination can behave slightly differently, e.g.:

• Apple syncs passkeys per default via iCloud Keychain across iOS, iPadOS and macOS but not to Windows or Android
• Google syncs via Google Password Manager across Android and Chrome but the experience on iOS is different (you need to manually set it up)
• Windows has its own passkey behavior that differs significantly from other platforms
• Password managers each handle passkey creation and selection differently, sometimes conflicting with platform-native prompts

4.2 Cross-Device Authentication Flows#

When a user creates a passkey on their iPhone but wants to log in on a Windows laptop, they can use cross-device authentication (typically via QR code and Bluetooth). This flow works but is fragile:

• It requires Bluetooth to be enabled on both devices
• Corporate firewalls and MDM policies can interfere as there is a tunnel set up in the background
• The UX varies dramatically between browsers
• Users often don't understand what's happening or why they're scanning a QR code

We've seen these edge cases firsthand across thousands of device combinations. If you're building passkeys in-house, you need to test and handle every one of them. If you can't, your users will hit errors that your support team can't explain.

4.3 Browser and OS Inconsistencies#

Even on the same device, different browsers behave differently. Chrome on macOS shows different passkey modals than Safari on macOS. Firefox has its own behavior. Client hints and user agent detection become critical for delivering the right flows to the right user but parsing them correctly across all combinations is a maintenance burden that never ends.

5. Issue 3: Native Apps multiply Passkey Complexity#

Passkey testing and QA is already a challenge for web apps (we cover that in detail in Issue 5: Platform Changes). But if your product also has native iOS and Android apps, the complexity multiplies because of architectural decisions and platform-specific behavior that web-only teams never face.

5.1 Native vs. WebView Decisions#

The first decision is whether to implement passkeys natively or via a WebView. Each approach has trade-offs:

On iOS alone, you can choose between WKWebView, SFSafariViewController, SFAuthenticationSession and ASWebAuthenticationSession - each with different passkey support characteristics. On Android, Chrome Custom Tabs behave differently from standard WebViews. These are decisions web-only teams never have to make and each choice creates its own maintenance surface.

5.2 Platform-Specific Behavior in Native Apps#

Beyond the architectural decision, iOS and Android handle passkeys differently at the OS level:

• iOS integrates passkeys deeply into the system credential manager, with specific autofill behaviors that can change with each iOS version
• Android routes passkey requests through the Credential Manager API, which interacts with multiple passkey providers simultaneously
• Error states, timeout behaviors and user prompts differ between platforms
• App store review cycles add delays when you need to ship urgent fixes for passkey regressions

5.3 Tripled QA Surface#

If you operate both a web app and native apps, you're not just doubling the QA effort but you're tripling it. Web, iOS and Android each behave as separate passkey environments that need independent end-to-end testing and monitoring. And unlike web, where you can deploy a fix instantly, native app fixes are gated by app store review cycles.

6. Issue 4: Adoption is a Product Problem, not a Tech Problem#

"Passkeys supported" does not mean "passkeys used." If you don't have a rollout strategy and measurement, your adoption will disappoint and the project will be labeled a failure internally.

6.1 Why low Adoption kills your Project#

We've covered this extensively in our article on why passkey implementations fail: if users don't switch to passkeys, the project has already failed. Passwords remain dominant, SMS OTP costs stay high, phishing risks persist and your organization sees no return on a significant engineering investment.

The business case for passkey adoption is strong but only if adoption actually happens. We've seen enterprises launch passkeys with great technical implementations that achieved less than 5% adoption because nobody thought about the rollout and adoption strategy.

6.2 Adoption requires deliberate Product Work#

Driving passkey adoption is a product challenge that requires:

• Progressive enrollment: nudging users to create passkeys at the right moments (e.g. after a successful login, during account security reviews)
• Clear user communication: explaining what passkeys are and why they're better, in language that non-technical users understand
• Device-aware prompting: only offering passkey creation when the user's device actually supports it well, avoiding frustrating experiences on unsupported configurations
• Measurement infrastructure: tracking passkey creation rates, login success rates, fallback rates and abandonment rates to identify and fix bottlenecks

6.3 What "good" Adoption looks like#

Based on our experience with large-scale passkey deployments, here's what enterprises should aim for:

If your adoption numbers look like the "weak" column after three months, the project is in trouble. Without analytics to measure this, you won't even know.

7. Issue 5: Platform Changes break Passkeys silently#

OS and browser updates change prompts, autofill behavior and fallback flows. If you don't have ongoing monitoring, you will get regressions and support tickets without warning.

We just published a comprehensive overview of WebAuthn errors that occurred in production.

7.1 Why Passkeys are uniquely affected by Platform Changes#

Unlike passwords (which are just strings your server validates), passkeys depend on deep integration with the operating system, browser and credential manager. When Apple ships a new iOS version, the passkey creation prompts might look different. When Chrome updates its autofill logic, your login flow might break. When a password manager releases a new version, it might start intercepting passkey requests in ways you didn't anticipate.

One recent example is the iOS 26.2 bug where isUserVerifyingPlatformAuthenticatorAvailable() returns false on all non-Safari browsers (Chrome, Edge, Firefox), requiring platform-aware detection logic using getClientCapabilities() as a workaround.

7.2 Monitoring is not optional#

To make sure you become aware of all potential bugs and track the adoption, you need to set up your authentication observability stack. We recommend to have at least the following in place:

• Real-time authentication analytics: track success and failure rates by OS, browser and passkey provider combination
• Version-aware monitoring: detect when a new OS or browser version causes a spike in errors or fallbacks
• Alerting: get notified before your users start filing support tickets
• Rapid response capability: the ability to push fixes or disable passkeys for affected device combinations quickly

This is the kind of authentication analytics infrastructure that most teams don't build until they've already had an incident. By then, the damage to user trust and internal project credibility is done.

7.3 Ongoing Maintenance Cost#

The true cost of passkey implementation is not the initial build. It's the ongoing maintenance:

• Monitoring platform changes across iOS, Android, Windows, macOS and all major browsers
• Testing each update for regressions
• Updating your frontend SDK when browser APIs change
• Maintaining compatibility with a growing ecosystem of passkey providers
• Documenting and communicating changes to your support team

8. When you should (not) ship Passkeys#

Given these Day 2 problems, here's an honest assessment of when you should and shouldn't ship passkeys.

8.1 Don't ship Passkeys if#

• You don't have a clear fallback and recovery strategy
• You haven't tested across the device combinations your users actually use
• You have native apps but no plan for ongoing platform-specific QA
• You don't have analytics infrastructure to measure adoption
• You can't commit engineering resources to ongoing maintenance
• You're implementing passkeys purely for a compliance checkbox without proper planning

Going all-in for regulatory reasons without proper planning can drive up costs significantly. A poorly implemented passkey system is worse than no passkey system: it erodes user trust, generates support overhead and gives internal stakeholders a reason to kill the project.

8.2 Ship Passkeys if#

• You've planned for all five Day 2 problems described above
• You have the product, engineering, security and analytics capabilities to support an ongoing rollout
• You've budgeted for continuous maintenance, not just the initial build
• You have a phased rollout strategy with clear adoption targets
• You're working with a partner like Corbado that handles the operational complexity for you

8.3 Build vs. Buy Decision#

The Day 2 problems described in this article are exactly why many enterprises choose to buy rather than build their passkey infrastructure. Building a WebAuthn server is the easy part. Operating a production-grade passkey system across thousands of device combinations, with proper recovery, monitoring and adoption analytics, is what separates a demo from a real deployment.

9. How Corbado solves Passkey Day 2 Problems#

Corbado exists specifically because Day 2 problems are hard. Our platform handles the operational complexity so you don't have to build and maintain it yourself.

9.1 Recovery and Fallback#

Corbado provides out-of-the-box recovery flows with adaptive security levels. From synced passkey strategies to cross-device authentication to automated identity verification. The recovery logic is built in and continuously updated.

9.2 Cross-Device Compatibility#

Our frontend SDKs are pre-tested across thousands of OS, browser and passkey provider combinations. Device detection, conditional UI handling and fallback routing happen automatically. When a new browser version breaks something, we fix it in our SDK before your users notice.

9.3 Native App Support#

Corbado supports both native and WebView passkey implementations with SDKs that abstract platform differences. You focus on your app's UX while we handle the passkey plumbing across iOS and Android.

9.4 Adoption Analytics#

Our analytics dashboard tracks every metric that matters: passkey creation rates, login success rates, fallback rates and device-level breakdowns. You get actionable insights to drive adoption, not just raw data.

9.5 Platform Change Monitoring#

Corbado continuously monitors OS and browser changes that affect passkeys. Our SDKs are updated proactively. Your passkey deployment stays stable even as the platform landscape shifts underneath it.

10. Conclusion#

Passkeys are the gold standard of authentication. That's not in question. But the path from "passkeys supported" to "passkeys working reliably at scale" is paved with Day 2 problems that most teams underestimate.

The five problems we've covered (recovery, cross-device edge cases, native app complexity, adoption and platform changes) are not rare. They're the core operational challenges of any production passkey deployment. Ignoring them doesn't make them go away. It just means your users discover them first.

My honest recommendation: if you don't have the know-how and resources to do passkeys properly, don't ship them. Either invest in the capability (product, engineering, security and analytics) or work with a partner who has already solved these problems. The worst outcome is a half-baked passkey deployment that gets rolled back because nobody planned for Day 2.