This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(208, 2%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAW%3C/text%3E%3C/svg%3E)
I am following up with the device owner's authorization and would appreciate supported Windows diagnostic guidance for cross-device passkey sign-in.
Windows displays the Google passkey QR code. The Redmi K80 system camera scans it, but the flow fails, and Windows reports a problem using the passkey. Bluetooth was enabled on both devices. The Google account already lists an Android-created passkey. The owner reports similar behavior across several already-signed-in Google accounts; no new repeat tests are being performed just to post this question.
Phone environment: Android 16 / API 36, HyperOS OS3.0.308.0.WOKCNXM, Google Play services 26.34.36. Google was explicitly selected as the preferred password/passkey credential service with the owner's authorization; a subsequent real camera scan still failed. Existing Xiaomi credential services and autofill settings were retained.
Windows was later read-only verified as Windows 11 25H2, build 26200.9168. A related QR/CTAP/SendCommand transaction on 9 October returned 0x80072efd. The actual connection target was not logged, so this is not proof that a specific relay endpoint failed or that all Google connections were direct. A local proxy is configured, but its effect on this transaction is unknown; no proxy/network changes have been made for this report. An ordinary HTTPS response alone was not treated as proof that the cross-device passkey transport worked.
What supported Windows traces or diagnostics can identify the actual failing cross-device transport, its target and proxy use, without resetting credentials or weakening protections? Which Windows component or official support route handles this class of failure? I am not claiming the root cause is established.
Clarification for the moderator: question 6031670 concerns creating a new local Google passkey on Windows, with a related MakeCredentialActiveCheck event reporting 0x800706ff. This question, 6031674, concerns signing in using a phone-scanned QR code, with a separate QR/CTAP transaction reporting 0x80072efd. These are different operations and transactions; a shared root cause has not been established. Could you please review the association and, if appropriate, undo the duplicate mark on 6031670 so both diagnostic questions remain open? Neither issue has received a substantive answer yet. Thank you.
If the goal is to have the passkey for a given website accessible from all the user's devices, the solution is to store the passkey in the user's password manager. This type of passkey is called a synced passkey because it is available on every device where the user is signed in to their password manager. To illustrate - Microsoft Edge includes a password manager:
Nevertheless, the same can be accomplished with any password manager.
Thank you for the suggestion. The reported issue is a failed QR-based cross-device sign-in using an existing Android passkey. We are seeking diagnostic guidance before changing credential storage or configuration. A related Windows QR/CTAP transaction reported 0x80072efd, but the actual connection target and whether the configured proxy affected that transaction remain unknown. Could you suggest supported, narrowly scoped Windows logs or traces that identify the failing transport, destination, and proxy use, and the Windows component or support team responsible? We have not established the root cause or confirmed that switching password managers would resolve this failure.
