--- url: 'https://www.corbado.com/blog/qr-login-failure' title: 'QR Login Failure: Why QR Code Login Breaks' description: 'QR code login can fail at scan, proximity, device handoff or confirmation. Learn how to debug QR login failures with authentication observability.' lang: 'en' author: 'Vincent Delitz' date: '2026-07-01T16:00:45.244Z' lastModified: '2026-07-01T16:00:45.244Z' keywords: 'qr code login not working, sign in with qr code not working, qr login failure, passkey qr code not working, qr code authentication failure' category: 'Passkeys Strategy' --- # QR Login Failure: Why QR Code Login Breaks ## 1. Introduction [QR code login](https://www.corbado.com/blog/qr-code-login-authentication) looks simple in a demo: show a code on desktop, scan it with a phone and confirm the login. In production, it has more ways to fail than a password form. The phone might not scan the QR code, the browser might not open the right app, Bluetooth proximity might fail, the user might confirm on the wrong device or the desktop session might never receive the final result. Most teams only see the end state: no login. That makes "QR code login not working" hard to debug. The failed step happened across two devices, two browsers or apps and sometimes a credential manager. This article explains the failure modes and how authentication observability turns a vague QR login failure into a specific root cause. ## Key Facts - QR login failures can happen at scan, device handoff, proximity check, confirmation or callback - Backend logs often miss the failure because the user never completes the client-side flow - Passkey QR flows add WebAuthn and Bluetooth proximity constraints to the normal QR experience - Debugging needs session stitching, but WebAuthn CDA exposes only coarse ceremony outcomes ## 2. Two Types of QR Login There are two different flows that often get called QR login. In custom QR login, a website or app generates its own QR challenge, the phone opens a controlled mobile flow and the team can often instrument scan, handoff, confirmation and callback events directly. In WebAuthn CDA passkey QR flows, the browser and operating system guide the user through using a passkey from another device. The QR code starts the hybrid transport flow, Bluetooth is used for proximity checking and the relying party usually sees only WebAuthn ceremony boundary events such as success, error, timeout and server verification. This is why CDA debugging must separate directly observed events from inferred phases. ## 3. Why QR Login Failure happens in Production QR login usually fails in small, unglamorous moments. The code is visible but hard to scan. The phone opens the wrong app. The user confirms something on mobile, then looks back at a desktop spinner that never resolves. That is why QR login can feel reliable in a demo and brittle in production. The flow depends on screen quality, camera behavior, browser routing, device policy and user confidence across two devices at the same time. ### 3.1 Scan Failure The first failure is often physical, not cryptographic. A QR code that looked fine on a developer monitor can be too small on a kiosk, washed out on a dim laptop or difficult to scan in poor lighting. App-based QR login adds another twist: users may scan with the default camera app when the flow expected an authenticator, banking app or company app. From the user's perspective, they did the obvious thing. From the system's perspective, the login never reached the right channel. ### 3.2 Wrong Device or Wrong Account Many QR flows quietly assume that "the phone" is the right trusted device. Real users are messier than that. They may have a personal phone, a work profile, a shared tablet or an old device that is still signed in. If the wrong device or account handles the QR challenge, the failure can look like abandonment even though the user was actively trying to complete the login. ### 3.3 Proximity and Network Checks Passkey-based [cross-device authentication](https://www.corbado.com/blog/webauthn-cross-device-authentication-passkeys-mobile-first) adds a different class of failure. The QR code starts the handoff, but the browser and operating system still need to complete the hybrid transport flow, including proximity checks such as Bluetooth. If Bluetooth is unavailable, browser behavior differs by platform or a corporate environment restricts the network path, the user may only see a generic timeout. The relying party often has to infer which part of the CDA flow failed. ### 3.4 Confirmation Drop-Off A scan is not the end of the journey. The user still has to understand the phone prompt, choose the right account and complete the confirmation before the desktop can move on. This is where UX copy and timing matter. If the phone locks, the biometric prompt expires or the confirmation text feels unrelated to the desktop action, the user may stop even though the QR code itself worked. ## 4. Why normal Analytics miss QR Login Failure Product analytics usually records a click on "sign in with QR code" and maybe a final success event. The important steps are between those events. ### 4.1 Flow spans two Devices A QR login attempt starts on desktop and continues on mobile. If the events are not stitched into one authentication journey, each side looks incomplete. In custom QR flows, desktop may see a pending session while mobile sees a scan or app open. In WebAuthn CDA passkey flows, the relying party often sees only the browser ceremony outcome, not each internal phone-side step. ### 4.2 Critical Steps are Client-Side Scan quality, app handoff, Bluetooth proximity, native browser prompts and biometric confirmation all happen before a backend session exists. In WebAuthn CDA, the browser and operating system own much of that interaction, so server logs usually see only the final assertion, verification failure, cancellation or timeout. ### 4.3 Aggregate Conversion hides the Failure Mode A lower [QR login conversion rate](https://www.corbado.com/blog/qr-code-login-conversion) tells you that the method underperforms. It does not tell you whether the issue is QR rendering, camera scan, proximity, app deep linking, passkey ceremony or user confusion. ## 5. How to Debug QR Login Failure The useful debugging model is a cross-device funnel, but not every step is directly observable in every QR flow. In custom app QR login, teams can often track scan and mobile confirmation events directly. In WebAuthn CDA passkey flows, the browser and operating system own parts of the QR, Bluetooth and phone confirmation experience, so teams infer the failing phase from timing, errors and environment data. ### 5.1 Track every observable QR Login Step For custom QR login flows, capture events such as QR code shown, QR code scanned, mobile session opened, confirmation shown, confirmation completed, desktop callback received and session established. For WebAuthn CDA passkey flows, be more careful. The relying party usually cannot directly observe whether the browser QR code was scanned, whether Bluetooth proximity succeeded or whether the phone biometric prompt was shown. Track the observable boundary events instead: passkey ceremony started, challenge created, WebAuthn call completed or failed, error name, timeout, elapsed duration, server verification result and session establishment. ### 5.2 Stitch Desktop and Mobile Sessions For custom QR flows, use a correlation ID that connects the desktop QR challenge with the mobile scan flow. Without this, the team cannot reconstruct the journey from one support ticket. For WebAuthn CDA passkeys, correlate the relying-party challenge, browser ceremony result, server verification and session outcome. If no mobile-side SDK event exists, avoid claiming that the scan or proximity check was directly observed. ### 5.3 Segment by Device, Browser and Flow Type Compare passkey QR, app QR and magic-link style QR flows separately. Segment by iOS, Android, desktop browser, mobile browser and app version. QR failures are often concentrated in one environment. ### 5.4 Separate User Abandonment from Technical Failure A user walking away from a QR screen is not the same as a Bluetooth proximity failure. Both reduce conversion, but they need different fixes. ## 6. What to do once you know the Root Cause Once the failing step is visible or strongly inferred, remediation is straightforward. The action map below connects each QR login failure mode to the fix that should be tested first. ## 7. How Corbado can help [Corbado Observe](https://www.corbado.com/observe) adds authentication observability on top of an existing login stack. For QR login, that means teams can connect the desktop start of the attempt, the observable browser or app events, the server verification result and the final session outcome into one authentication journey. This is especially useful for WebAuthn CDA passkey QR flows, where the relying party usually cannot directly see every phone-side step. Corbado Observe helps separate directly observed events from inferred phases, so teams can distinguish scan or handoff problems, WebAuthn timeouts, user cancellations, callback issues and server-side verification failures. Instead of treating "QR login not working" as one generic support category, teams can segment failures by flow type, OS, browser, device and credential context. That turns vague reports into actionable statements such as: "Android Chrome users in cross-device passkey QR flows show timeouts consistent with proximity or confirmation issues, while iOS Safari users complete successfully." ## 8. Conclusion QR login is not one step. It is a cross-device authentication journey with multiple hidden failure points. If you only measure final success, every QR login failure looks the same. Authentication observability gives teams the missing middle: whether the issue sits around scan, handoff, proximity, confirmation, callback or server verification. In WebAuthn CDA passkey flows, some of these phases are inferred rather than directly observed, but that is still the difference between guessing and fixing the QR login flow. ## 9. Frequently Asked Questions ### 9.1 Why does desktop QR login show a spinner after the phone scan succeeds? After a successful scan, the user must still understand the phone prompt and confirm the login. If the biometric prompt times out, the phone locks or the confirmation copy is unclear, the desktop page never receives the final callback and displays only a spinner indefinitely. ### 9.2 How do I tell whether a QR login failure is user abandonment or a technical error? A user walking away from a QR screen and a Bluetooth proximity failure both reduce conversion but require different fixes. Custom QR flows can often instrument scan and confirmation events directly. WebAuthn CDA passkey flows usually expose only boundary events such as ceremony start, success, error, timeout and server verification, so hidden steps must be inferred from timing and environment data. ### 9.3 Why does QR code login work in a demo but fail for real users? Demo setups control screen brightness, camera quality, room lighting and network conditions that vary in production. Real users may scan with the wrong camera app, use shared or work-profile devices or encounter CDA failures caused by Bluetooth availability, browser behavior or restrictive corporate networks. ### 9.4 What events should I instrument to debug a cross-device QR login funnel? For custom QR login, capture QR code shown, QR code scanned, mobile session opened, confirmation shown, confirmation completed, desktop callback received and session established. For WebAuthn CDA passkeys, capture ceremony started, challenge created, WebAuthn success or failure, error name, timeout, elapsed duration, server verification result and session established. Treat scan, proximity and phone confirmation as inferred phases unless your own app or SDK exposes them directly.