When a user signs in with a passkey using the “use your phone” / QR-code option, the sign-in fails on networks that enforce an HTTP proxy or block direct internet access. The same passkey and phone work on home or mobile networks. The failing step is a Windows platform component - not the browser or the website - so it affects every service that uses phone/QR passkey sign-in.

This article covers the third-party relay hosts that cross-device passkeys use. For Flip’s own domains and general firewall/proxy allowlisting, see the “Allowlisting Flip App” article in this section.

Check whether you are affected

Windows logs every cross-device passkey attempt in the Event Viewer:

1. Open Event Viewer.
2. Go to Applications and Services Logs → Microsoft → Windows → WebAuthN → Operational.
3. Reproduce a failed sign-in, or review earlier attempts.
4. Look for Event ID 2336 with Action = QR and an error code, usually followed by Event ID 2103 carrying the same error.

You are affected if event 2336 shows one of these error codes:

0x80072EE7 at event 2336 is the classic signature of this problem: the client attempted direct egress on a network that only permits proxied traffic.

How cross-device passkeys communicate

When a user signs in with a passkey on their phone, the passkey never leaves the phone. To complete the sign-in on the PC, the PC and the phone exchange a short series of encrypted messages.

They do not talk directly. Both open an outbound connection to a small relay (tunnel) server on the internet and pass the messages through it. The connection is a WebSocket over HTTPS (TCP 443) and is end-to-end encrypted between the PC and the phone - a proxy cannot read or usefully inspect it. Bluetooth only confirms the phone is physically near the PC; it does not carry the sign-in data.

The relay is chosen by the phone’s operating system, not by the PC or the website:

On iPhone/iPad, cable.auth.com carries the sign-in, and the two app-site-association.* hosts are used by Apple during passkey registration. Allow all of them so both registration and sign-in work. The PC must reach these hosts on TCP 443.

Why normal proxy settings do not apply (Windows)

On Windows this connection is not opened by the browser or in the signed-in user’s context. It is opened by a Windows system service - Cryptographic Services (CryptSvc) - running as NT AUTHORITY\NETWORK SERVICE. As a result:

• It does not use the signed-in user’s proxy settings (HKCU or user Group Policy).
• It does not use the machine-wide WinHTTP proxy (netsh winhttp set proxy).
• It uses the proxy configuration of its own service account (the NETWORK SERVICE profile, HKEY_USERS\S-1-5-20).
• It connects by IP address (possibly cached), so hostname-only or hosts-file blocking is unreliable against it.

How to fix it

There are two options. Variation 1 (direct access) is recommended. Variation 2 (proxy) is a configuration we found through testing, for environments where direct access is not possible.

Variation 1 - Allow direct access to the relay hosts (recommended)

Let the client PCs reach these hosts directly, bypassing the proxy:

• cable.ua5v.com (Android)
• cable.auth.com (iPhone / iPad)
• app-site-association.cdn-apple.com and app-site-association.networking.apple (Apple, for passkey registration)

1. Allow outbound TCP 443 to these hosts. Because the client may use a cached IP address, prefer allow rules that cover the relays’ full published address ranges (Apple / Google), or an FQDN rule that tracks all their A records - a single pinned IP will drift.
2. Do not TLS/SSL-inspect these hosts. The tunnel validates the relay’s real certificate; if the proxy substitutes its own, the connection is refused. Add these hosts to the SSL-inspection bypass list.

This is the only approach Microsoft documents, and the tunnel is end-to-end encrypted, so routing it through a proxy provides no inspection benefit. Microsoft’s guidance: “Your organization needs to allow connectivity to endpoints in the following table to enable cross-device registration and authentication. Devices must be allowed to reach these URLs.” (see References).

Variation 2 - Route through the proxy (fallback)

Use this if direct access cannot be granted. This is a configuration we found through our own testing; it is not described in Microsoft’s documentation. Two settings together made it work.

A) Allow the two relay hosts through the proxy without authentication

The tunnel client connects to the proxy without authenticating - it offers an anonymous token rather than a user or domain credential. In testing, a proxy that required authentication returned 0x80190197 (HTTP 407) and the sign-in did not complete. Configure the proxy to allow CONNECT without authentication to exactly:

• cable.ua5v.com:443
• cable.auth.com:443

Scope this to these two hosts only; the rest of the proxy can keep requiring authentication. This matches the pattern Microsoft uses for other system-initiated connections - a small unauthenticated exception for specific named URLs (see KB 2778122 in References).

B) Configure the proxy in the service account’s WinINET settings (HKEY_USERS\S-1-5-20)

Because the client reads the NETWORK SERVICE account’s proxy configuration, set the proxy there - not in the user’s settings and not via netsh winhttp. Any of the usual WinINET methods work, as long as they live in this hive:

• Manual proxy - under …\Internet Settings:

  HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings
      ProxyEnable  (DWORD)  = 1
      ProxyServer  (String) = proxy.corp.example:8080

• PAC (setup script) - set AutoConfigURL under …\Internet Settings, and set the DefaultConnectionSettings binary value under …\Internet Settings\Connections with the auto-config flag enabled.
• WPAD (auto-detect) - set the DefaultConnectionSettings binary value under …\Internet Settings\Connections with the auto-detect flag enabled.

DefaultConnectionSettings is the same binary value Windows writes when you choose “Use a setup script” or “Automatically detect settings” in the proxy UI. Carry it into the S-1-5-20 hive with the flags your environment uses.

Rollout

This is a machine/service-context change, so deploy it with anything that runs as SYSTEM:

• Group Policy - a computer Startup script (runs as SYSTEM) that writes the registry values above.
• Intune / MDM - a device (system-context) PowerShell script, or a registry policy (Settings Catalog / OMA-URI).
• Configuration Manager (SCCM) - a script or configuration item deployed to devices.
• Ad-hoc / testing - run a script as SYSTEM (for example with psexec -s).

Example script (run as SYSTEM):

$key = 'Registry::HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name ProxyServer -Value 'proxy.corp.example:8080'
Set-ItemProperty -Path $key -Name ProxyEnable -Value 1 -Type DWord
# The service caches its proxy config. Restarting the host service applies it;
# a reboot is the most reliable option on managed fleets.
Restart-Service CryptSvc -Force

Notes

• The service caches its proxy configuration, so the change is not picked up instantly. In testing it applied after a settings-changed notification or a service restart; a reboot is the most reliable way to roll it out.
• Keep TLS interception off for the two hosts, same as Variation 1.

We tested this on a machine that was not domain-joined, where the client offered an anonymous token. On a domain-joined machine the client may present the machine account or a Kerberos ticket instead, so check whether the unauthenticated exception is still needed there.

Verify the fix

• Run a real phone sign-in on a client. For a quick end-to-end test, register and sign in with a passkey at https://webauthn.io using the phone (choose the cross-device / “use your phone” QR option).
• In WebAuthN/Operational, confirm event 2335 (QR setup completed) and a successful GetAssertion, with no 2336 error.
• For Variation 2, confirm the proxy access log shows an (unauthenticated) CONNECT cable.auth.com:443 or CONNECT cable.ua5v.com:443 from the device.

References

• Enable and support passkeys in Authenticator for Microsoft Entra ID - “Prerequisites for passkeys in Authenticator” (the endpoint list).
• Use authenticated proxy servers (Microsoft KB 2778122) - background on why some Windows system-context connections cannot authenticate to a proxy, and allowing specific URLs through the proxy without authentication.
• Support for passkeys in Windows.
• Apple - enterprise network guidance (ports/hosts).

The service-account and proxy behaviour above is based on our own hands-on testing of this sign-in flow.