An introduction to the feature, aimed at unfamiliar audiences: During cross-device (hybrid transport) WebAuthn authentication—where a user scans a QR code or connects to a mobile device (authenticator) from a desktop client—the mobile device may not have a matching passkey for the Relying Party (RP). Today, this leads to a dead-end experience on the mobile device, forcing the user to abandon the mobile flow and return to the desktop to try another sign-in method. The crossDeviceFallbackUrl extension allows the RP to specify a same-site HTTPS fallback URL in navigator.credentials.get() options so the remote authenticator device can offer to transition the user directly into an alternative authentication or onboarding flow on that device.
A description of the problems that end-users were facing before this proposal: Users scanning a hybrid transport QR code with a phone that lacks the expected passkey hit a dead end on their mobile device with no guided way to recover or sign in on that device.
Alternatives considered: Relying solely on client-side timeout/cancellation on the desktop page; or allowing custom URI schemes vs. restricting to HTTPS URLs that are same-site with the RP ID (restricted to same-site HTTPS URLs and checked against CSP to prevent abuse).
Examples of how to use the proposal to solve the end-users' problems: Passing extensions: { crossDeviceFallbackUrl: "..." } inside publicKey options to navigator.credentials.get().
What do the end-users experience with this proposal: When a user initiates hybrid authentication and their mobile device does not have a matching passkey for the RP, the mobile OS/authenticator UI can offer an option to open the RP-provided fallback URL in the mobile browser (and inform the client that the fallback URL was processed via WebAuthnOperationException).
User research you did to validate the problem and/or design, if any: N/A
<details><summary>Security and Privacy Self-Review Questionnaire</summary>
Security and Privacy Self-Review Questionnaire
2.1. What information does this feature expose, and for what purposes?
This feature allows a Relying Party (RP) to pass a fallback URL (crossDeviceFallbackUrl) from the client to a remote authenticator over a hybrid transport connection during navigator.credentials.get(). If no matching passkey is available on the remote authenticator and the user explicitly chooses to follow the fallback flow on that device, the authenticator informs the client that the fallback URL was invoked by rejecting the navigator.credentials.get() promise with a WebAuthnOperationException. This benefits the user by preventing a dead-end experience on their mobile device and allowing the desktop client UI to update appropriately once the user transitions to the mobile fallback URL.
What information does your spec expose to the first party that the first party cannot currently easily determine?
Only two pieces of information:
Via PublicKeyCredential.getClientCapabilities(), whether the client supports the extension:crossDeviceFallbackUrl extension.
Via WebAuthnOperationException, that the user explicitly interacted with the remote hybrid authenticator and opted to open the RP-provided fallback URL instead of completing a WebAuthn assertion. (Note: if the RP includes a session identifier in the fallback URL, the RP would already learn this as soon as the mobile browser loads the fallback URL).
What information does your spec expose to third parties that third parties cannot currently easily determine?
None. Cross-origin iframes cannot invoke navigator.credentials.get() unless explicitly delegated via the publickey-credentials-get Permissions Policy, and the crossDeviceFallbackUrl must be same-site with the effective rpId.
What potentially identifying information does your spec expose to the first party that the first party can already access?
None.
What potentially identifying information does your spec expose to third parties that third parties can already access?
None.
2.2. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes. The extension only sends a single validated HTTPS URL over the hybrid tunnel and only returns a signal (WebAuthnOperationException) when the user actively chooses to invoke the fallback URL on the remote authenticator. It does not expose why no passkey matched, what credentials exist on the remote device, or any hardware/OS details of the remote device.
2.3. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No. No personal information or PII is exposed by this extension.
2.4. How do the features in your specification deal with sensitive information?
The extension itself does not expose sensitive user information. Because an RP might include session context or authentication tokens in the query parameters of crossDeviceFallbackUrl, the URL is only transmitted over an end-to-end encrypted, proximity-verified CTAP hybrid transport tunnel after explicit user action (such as scanning a QR code), and the client enforces Content Security Policy (CSP) checks on the URL to prevent XSS exfiltration.
2.5. Does data exposed by your specification carry related but distinct information that may not be obvious to users?
No.
2.6. Do the features in your specification introduce state that persists across browsing sessions?
No. The extension is stateless and scoped to a single navigator.credentials.get() authentication ceremony.
2.7. Do the features in your specification expose information about the underlying platform to origins?
Only a boolean capability entry (extension:crossDeviceFallbackUrl) in PublicKeyCredential.getClientCapabilities(), which is uniform across all users of a supporting browser version and adds no user-specific fingerprinting entropy.
2.8. Does this specification allow an origin to send data to the underlying platform?
Yes. It allows an origin to pass a URL string (crossDeviceFallbackUrl) to the WebAuthn client, which forwards it over hybrid transport to the remote authenticator to potentially open in the remote device's browser.
To mitigate risks of arbitrary URI scheme abuse (such as javascript:, file:, data:, blob:, or custom app schemes), open redirects, or XSS data exfiltration:
The client parses and validates the URL and requires the scheme to be https:.
The URL's origin must be same-site with the effective rpId of the request.
The client runs Content Security Policy (CSP) checks against the URL so an XSS attacker cannot use crossDeviceFallbackUrl to bypass CSP restrictions.
The URL is only forwarded to authenticators over hybrid transport.
2.9. Do features in this specification enable access to device sensors?
No.
2.10. Do features in this specification enable new script execution/loading mechanisms?
No.
2.11. Do features in this specification allow an origin to access other devices?
WebAuthn already supports communicating with a user's remote authenticator via CTAP2.2 hybrid transport with explicit user mediation (scanning a QR code or confirming a notification on a linked device). This extension does not introduce any new device discovery or connection mechanisms; it only piggybacks a validated same-site HTTPS URL onto an existing user-mediated hybrid request.
2.12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
On the remote authenticator device, if no matching passkey is found, the platform authenticator UI may present an option for the user to open the RP-provided fallback URL in their mobile browser. The native UI remains fully under the control of the platform/authenticator, requires explicit user confirmation before navigating to the URL, and clearly attributes the destination.
2.13. What temporary identifiers do the features in this specification create or expose to the web?
None are created or exposed by the user agent or authenticator. (RPs may include their own short-lived session identifier in the fallback URL query string to correlate the fallback flow).
2.14. How does this specification distinguish between behavior in first-party and third-party contexts?
It inherits WebAuthn's existing third-party restrictions: navigator.credentials.get() in cross-origin iframes is blocked by default unless explicitly enabled via the publickey-credentials-get Permissions Policy, and crossDeviceFallbackUrl must be same-site with the effective rpId.
2.15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
It behaves identically in Private Browsing / Incognito mode as in normal mode, persists no state on the client, and does not allow correlating a user's activity across normal and private browsing sessions.
2.16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes. PR #2380 adds dedicated Security and Privacy Considerations for the crossDeviceFallbackUrl extension to the WebAuthn specification, detailing URL validation, CSP enforcement, and cross-device phishing/social engineering considerations.
2.17. Do features in your specification enable origins to downgrade default security protections?
No.
2.18. What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
Standard WebAuthn lifetime rules apply: if a document ceases to be fully active (including entering BFCache), any in-flight navigator.credentials.get() request is aborted.
2.19. What happens when a document that uses your feature gets disconnected?
If the document becomes disconnected (no longer fully active), any pending WebAuthn operation is immediately aborted.
2.20. Does your spec define when and how new kinds of errors should be raised?
Yes:
Client-side validation errors: If crossDeviceFallbackUrl is not a valid URL, does not use the https: scheme, is not same-site with the effective rpId, or violates the document's CSP, the client rejects the request before contacting any authenticator. Because validation depends only on inputs provided by the page itself, this does not leak any system or user state.
Operation exception (WebAuthnOperationException): When the remote authenticator processes the fallback URL in response to explicit user action on the remote device, the client rejects the promise with WebAuthnOperationException. Because this only occurs after explicit user mediation on the remote device, it cannot be used for silent probing.
2.21. Does your feature allow sites to learn about the user’s use of assistive technology?
Organization/project driving the specification: Google / W3C Web Authentication Working Group
This work is being funded by: Google
Primary standards group developing this feature: W3C Web Authentication Working Group (in coordination with FIDO Alliance CTAP / Hybrid Working Group)
Incubation and standards groups that have discussed the design:
W3C Web Authentication WG (w3c/webauthn#2341, w3c/webauthn#2380)
FIDO Alliance FIDO2 / CTAP Technical Working Group (fido-alliance/fido-2-specs#1755, fido-alliance/fido-2-specs#1761)
Feedback so far
Multi-stakeholder feedback:
Chromium comments: Positive; prototyped behind flag (commit 55da8e2).
Mozilla comments: Discussed in WebAuthn WG calls and reviewed in PR #2380.
WebKit comments: Reviewed in PR #2380 by Apple WebAuthn WG members (@pascoej).
Major unresolved issues with or opposition to this specification: None blocking this extension. Future enhancements to bind the fallback URL session to the hybrid tunnel are tracked separately in https://github.com/w3c/webauthn/issues/2478.
The wire protocol and remote authenticator behavior for carrying and handling the fallback URL over hybrid transport are specified in the FIDO CTAP specification (crossDeviceFallbackUrl), while WebAuthn PR #2380 defines the client/authenticator extension inputs, URL validation (HTTPS, same-site with rpId, CSP compliance), and exception handling (WebAuthnOperationException).
<!-- Content below this is maintained by @w3c-tag-bot -->
OpenedOct 23, 2026
Specification
https://github.com/w3c/webauthn/pull/2380
Explainer
https://github.com/w3c/webauthn/blob/main/explainers/cross-device-fallback-url.md
Links
crossDeviceFallbackUrlextension allows the RP to specify a same-site HTTPS fallback URL innavigator.credentials.get()options so the remote authenticator device can offer to transition the user directly into an alternative authentication or onboarding flow on that device.extensions: { crossDeviceFallbackUrl: "..." }insidepublicKeyoptions tonavigator.credentials.get().WebAuthnOperationException).The specification
- Follows the Web Platform Design Principles.
- Includes Security and Privacy Considerations sections based on answers to the Security/Privacy Questionnaire.
<details><summary>Security and Privacy Self-Review Questionnaire</summary>Security and Privacy Self-Review Questionnaire
2.1. What information does this feature expose, and for what purposes?
This feature allows a Relying Party (RP) to pass a fallback URL (
crossDeviceFallbackUrl) from the client to a remote authenticator over a hybrid transport connection duringnavigator.credentials.get(). If no matching passkey is available on the remote authenticator and the user explicitly chooses to follow the fallback flow on that device, the authenticator informs the client that the fallback URL was invoked by rejecting thenavigator.credentials.get()promise with aWebAuthnOperationException. This benefits the user by preventing a dead-end experience on their mobile device and allowing the desktop client UI to update appropriately once the user transitions to the mobile fallback URL.PublicKeyCredential.getClientCapabilities(), whether the client supports theextension:crossDeviceFallbackUrlextension.WebAuthnOperationException, that the user explicitly interacted with the remote hybrid authenticator and opted to open the RP-provided fallback URL instead of completing a WebAuthn assertion. (Note: if the RP includes a session identifier in the fallback URL, the RP would already learn this as soon as the mobile browser loads the fallback URL).navigator.credentials.get()unless explicitly delegated via thepublickey-credentials-getPermissions Policy, and thecrossDeviceFallbackUrlmust be same-site with the effectiverpId.2.2. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes. The extension only sends a single validated HTTPS URL over the hybrid tunnel and only returns a signal (
WebAuthnOperationException) when the user actively chooses to invoke the fallback URL on the remote authenticator. It does not expose why no passkey matched, what credentials exist on the remote device, or any hardware/OS details of the remote device.2.3. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No. No personal information or PII is exposed by this extension.
2.4. How do the features in your specification deal with sensitive information?
The extension itself does not expose sensitive user information. Because an RP might include session context or authentication tokens in the query parameters of
crossDeviceFallbackUrl, the URL is only transmitted over an end-to-end encrypted, proximity-verified CTAP hybrid transport tunnel after explicit user action (such as scanning a QR code), and the client enforces Content Security Policy (CSP) checks on the URL to prevent XSS exfiltration.2.5. Does data exposed by your specification carry related but distinct information that may not be obvious to users?
No.
2.6. Do the features in your specification introduce state that persists across browsing sessions?
No. The extension is stateless and scoped to a single
navigator.credentials.get()authentication ceremony.2.7. Do the features in your specification expose information about the underlying platform to origins?
Only a boolean capability entry (
extension:crossDeviceFallbackUrl) inPublicKeyCredential.getClientCapabilities(), which is uniform across all users of a supporting browser version and adds no user-specific fingerprinting entropy.2.8. Does this specification allow an origin to send data to the underlying platform?
Yes. It allows an origin to pass a URL string (
crossDeviceFallbackUrl) to the WebAuthn client, which forwards it over hybrid transport to the remote authenticator to potentially open in the remote device's browser. To mitigate risks of arbitrary URI scheme abuse (such asjavascript:,file:,data:,blob:, or custom app schemes), open redirects, or XSS data exfiltration:https:.rpIdof the request.crossDeviceFallbackUrlto bypass CSP restrictions.hybridtransport.2.9. Do features in this specification enable access to device sensors?
No.
2.10. Do features in this specification enable new script execution/loading mechanisms?
No.
2.11. Do features in this specification allow an origin to access other devices?
WebAuthn already supports communicating with a user's remote authenticator via CTAP2.2 hybrid transport with explicit user mediation (scanning a QR code or confirming a notification on a linked device). This extension does not introduce any new device discovery or connection mechanisms; it only piggybacks a validated same-site HTTPS URL onto an existing user-mediated hybrid request.
2.12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
On the remote authenticator device, if no matching passkey is found, the platform authenticator UI may present an option for the user to open the RP-provided fallback URL in their mobile browser. The native UI remains fully under the control of the platform/authenticator, requires explicit user confirmation before navigating to the URL, and clearly attributes the destination.
2.13. What temporary identifiers do the features in this specification create or expose to the web?
None are created or exposed by the user agent or authenticator. (RPs may include their own short-lived session identifier in the fallback URL query string to correlate the fallback flow).
2.14. How does this specification distinguish between behavior in first-party and third-party contexts?
It inherits WebAuthn's existing third-party restrictions:
navigator.credentials.get()in cross-origin iframes is blocked by default unless explicitly enabled via thepublickey-credentials-getPermissions Policy, andcrossDeviceFallbackUrlmust be same-site with the effectiverpId.2.15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
It behaves identically in Private Browsing / Incognito mode as in normal mode, persists no state on the client, and does not allow correlating a user's activity across normal and private browsing sessions.
2.16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes. PR #2380 adds dedicated Security and Privacy Considerations for the
crossDeviceFallbackUrlextension to the WebAuthn specification, detailing URL validation, CSP enforcement, and cross-device phishing/social engineering considerations.2.17. Do features in your specification enable origins to downgrade default security protections?
No.
2.18. What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
Standard WebAuthn lifetime rules apply: if a document ceases to be fully active (including entering BFCache), any in-flight
navigator.credentials.get()request is aborted.2.19. What happens when a document that uses your feature gets disconnected?
If the document becomes disconnected (no longer fully active), any pending WebAuthn operation is immediately aborted.
2.20. Does your spec define when and how new kinds of errors should be raised?
Yes:
crossDeviceFallbackUrlis not a valid URL, does not use thehttps:scheme, is not same-site with the effectiverpId, or violates the document's CSP, the client rejects the request before contacting any authenticator. Because validation depends only on inputs provided by the page itself, this does not leak any system or user state.WebAuthnOperationException): When the remote authenticator processes the fallback URL in response to explicit user action on the remote device, the client rejects the promise withWebAuthnOperationException. Because this only occurs after explicit user mediation on the remote device, it cannot be used for silent probing.2.21. Does your feature allow sites to learn about the user’s use of assistive technology?
No.
2.22. What should this questionnaire have asked?
N/A
</details>Where and by whom is the work is being done?
Feedback so far
You should also know that...
The wire protocol and remote authenticator behavior for carrying and handling the fallback URL over hybrid transport are specified in the FIDO CTAP specification (
<!-- Content below this is maintained by @w3c-tag-bot -->crossDeviceFallbackUrl), while WebAuthn PR #2380 defines the client/authenticator extension inputs, URL validation (HTTPS, same-site withrpId, CSP compliance), and exception handling (WebAuthnOperationException).Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1293