Passkey Revolution: Google Syncs Passkeys to Apple & Windows Devices

After an announcement in a Chromium developer channel on July 11, 2024, a major new passkey functionality has been released for Chrome / Google Password Manager. What was known inside the passkeys / WebAuthn community for quite some time now has become reality and is not anymore hidden behind a feature flag:

In the Conditional UI menu, there is now a new option where passkeys are displayed as being stored in the passkey provider “Google Password Manager”:

This is a change from the previous passkey provider “Chrome Profile” on macOS:

This change is also reflected in Windows 11. Before this release, the Conditional UI (“Passkey Autofill”) menu just displayed the connected devices (e.g. SM-S921B) and showed passkeys that were available for cross-device authentication. This meant you had to scan a QR code on Windows, make sure that Bluetooth was turned on and then use Android’s local authentication (e.g. fingerprint scan) to make use of passkeys stored on your Android (in Google Password Manager):

For many users, this might seem like a small change. However, it has tremendous impact on the whole ecosystem, how we authenticate in the future and on what this means for the “War of Password Managers”. All because Google – as the first of the 3 big tech players besides Apple & Microsoft – can now sync passkeys natively across the three major operating systems Android, macOS and Windows.

With this blog post, we dug deeper into the technical details to answer the following questions for you and analyze the impact on the password managers (Google itself has not officially announced the new feature and laid out their strategy):

1. Has Google solved the cross-platform problems with passkeys?
2. How does Google technically sync passkeys across Windows, macOS and Android?
3. What does this mean for iCloud Keychain and Windows Hello where passkeys are currently stored by default on the respective devices?

For the user, this means that if a passkey is created on Android, it will automatically sync and be available without the need for an additional password manager app—just via Chrome. You only need to be signed into your Google account on Chrome, which should be installed on all devices (as it often is by default).

The most common scenario is the following:

The user creates a passkey on their Android device and stores it in the default passkey provider Google Password Manager. The following login options now work:

The passkey was created on this device and can be used for logins from this device.

Assuming it’s the same Google account on the other Android device, the passkey is synced via Google Password Manager and can be used for logins.

If the user has Chrome installed on Windows (the most common option) and is logged into their Google profile in Chrome, then the passkey is available. User verification is done via Windows Security (see this popup) and TPM:

Initially, on a new Windows device that has not been used with Google Password Manager, two screens / pop-ups emerge and need to be checked. At first, an informational modal appears.

Then, you need to validate your Android PIN pattern in a new Chrome browser window:

If the user has Chrome installed on the macOS device and is logged in to their Google profile in Chrome, then the passkey is available for login. Protection is done via Touch ID and secure enclave.

For Chrome on iOS, we did not (yet) see the Google Password Manager syncing feature. This means you can only use synced passkeys via iCloud Keychain and other third-party password managers on iOS.

Every Android user who creates a passkey on their Android (worldwide this is still +70% of mobile users as of August 2024) can access their passkey also on macOS and Windows devices (if they are logged into their Google accounts in Chrome).

If the passkey creates a new passkey on macOS and Windows, it won’t sync (yet) to Google Password Manager (independently if the user is logged into their Google account or not). However, there is some hint in the developer note that passkey creation should be possible for Google Password Manager from macOS and Windows (maybe this feature will be rolled out on the go).

There is one note from Adam Langley (software engineer at Google) who posted a message on July 11, 2024 to the public WebAuthn channel with the title “Google Password Manager passkey syncing on desktop”.

Via the Chrome Canary flag chrome://flags/#web-authentication-enclave-authenticator one could have tried out this feature for some weeks (you would need to set it to “Enabled with GPM PIN enabled”). This feature flag allows the Google Password Manager passkey sync to Windows and macOS.

The private keys of a passkey aren’t synced directly. Instead, a Google production service is used that wraps the private keys, so it’s not possible to extract the private keys of a passkey from Windows or macOS. To access this wrapper service, a hardware-backed key on the client device (the Windows or macOS device) is required:

• Windows must have TPM (which not all Windows 10 devices have)
• macOS must have secure enclave (which all of them have)

The service temporarily stores user secrets in memory and operates under SEV-SNP (a security technology developed by AMD). It uses the Oak platform for secure execution. Although the source code and a reproducible build of the service are not yet available, they will be released in the future according to Adam Langley. Later, Chrome will be able to verify the attestation provided by AMD and compare the observed code hashes with those from the reproducible build to ensure integrity.

Currently, Google Password Manager passkeys are not supported on iOS. Therefore, Chrome on macOS will only default to creating credentials in Google Password Manager if there are indications that this would be more beneficial for the user than storing passkeys in iCloud Keychain (see our note above that we couldn’t test this feature successfully yet). Such indications include:

• Already having passkeys in Google Password Manager,
• Syncing with a non-Apple device, or
• Having previously denied Chrome permission to use iCloud Keychain.

Unlike Apple, which controls a closed ecosystem encompassing both software and hardware – allowing it to continuously grow its market share not only in mobile phones but also on desktops and laptops – Google has to operate differently (we neglect the few Pixel phones and ChromeOS devices as they have too small market share).

Google has a valuable asset: control over Chrome, which is by far the most successful browser (65% market share worldwide). Chrome’s popularity spans across all platforms, both mobile and desktop, making it a powerful lever in Google’s strategy.

Strategically, Google can now fully serve all its mobile users. Most Android users also have access to a desktop or laptop, typically running either Windows or macOS. Through Chrome, users can access their credentials seamlessly on these desktop or laptop devices, creating a unified experience across platforms via Google Password Manager.

This universal accessibility requires advanced development, which Google seems to have achieved now. Although the details are unclear in above-mentioned announcement, the concept is that by hosting the private key of a passkey outside the local device, Google ensures the key remains independent, provided the device has a TPM (Trusted Platform Module) or secure enclave to authenticate with the cloud enclave.

For Apple, the situation is different. iPhone users with macOS as their desktop or laptop OS enjoy a seamless experience, as they can access credentials via iCloud Keychain. However, on Windows, the experience is less satisfactory, as nothing is synced (though Apple’s Passwords app might change this).

Passkeys are not only pushed by Google but also by Apple and Microsoft, both of which have significant stakes in the development of passkeys as they control most of the remaining devices, browsers, and operating systems. The strategic interest of all three companies in ensuring that their users can conveniently and securely access websites and apps via their authentication systems is immense and is expected to intensify in the future (as evidenced by the current “War of Password Managers”).

Let’s briefly analyze what Apple’s and Microsoft’s next strategic moves are.

With the upcoming iOS 18 release, Apple has already shown a fist insight into their strategy by announcing the release of their standalone passwords manager (simply called Passwords).

This will not only bring more passkey-boosting features like automatic passkey upgrades (currently only works with Safari 18) but also support on non-Apple operating systems. Apple already confirmed a Windows app of Passwords and will surely also bring an Android app to Google Play Store. That way they could also reach an OS-overarching synchronization of their credentials (passwords and passkeys).

Windows is still lagging a bit behind with their rollout of passkey-related features. That’s probably due to the fact that Microsoft not only serves the consumer market (as Apple and Google do with their respective operating systems) but also need to make sure that their vast B2B units and products keep up with modern development. Therefore, Windows / Microsoft still do not offer native passkey synchronization via Microsoft accounts (currently only device-bound passkeys via Windows Hello are offered; for cross-device synchronization, you would need to use a third-party password manager with passkey synchronization support, such as Dashlane or 1Password).

However, there are rumors that with the next Windows 11 update (24H2), this feature will finally be rolled out to users. Once that happens, another major UX concern is gone and all big operating systems (iOS, macOS, Android, Windows) will probably default to synced passkeys.

How Microsoft plans to sync passkeys across devices via Microsoft accounts is yet to be defined. One possibility could involve their authenticator app, which is already available on iOS and Android.

Moreover, it’s still unclear if Microsoft will allow third-party password managers to natively use passkey required APIs on operating system level (iOS, macOS & Android support it).

If all of these scenarios (especially on Windows) become a reality, then theoretically, a user could choose their preferred passkey provider (either first-party or third-party) to sync a single passkey across all major operating systems, using:

• Apple Account, iCloud Keychain and Passwords app (soon)
• Google Account, Google Password Manager and Chrome
• Microsoft Account
• Third-Party Password Manager (e.g. KeePassXC, Dashlane, 1Password)

Returning from the “War of Password Managers" to the reality faced by developers and relying parties considering the implementation of passkeys: what does this new Google feature mean for them?

When implementing passkeys and detection login from Chrome Version 129 on Windows and onwards, if an Android Passkey stored in Google Password Manager exists, it might be assumed that login is possible via a platform authenticator. However, caution is required, as it is essential to monitor user behavior to ensure that the user's Android device is connected. If the device is not connected, true cross-device authentication (via QR code) may be necessary. Logins completed via the new Google Password Manager syncing feature can be identified by a new field in clientDataJSON called androidPackageName.

Take a look at the sample passkey in the Passkeys Debugger to see the full output.

The new cross-platform / cross-device passkey synchronization feature by Google Password Manager is the first of many more user-friendly steps that will make passkeys more accessible to more users.

We know of many companies that are currently evaluating their passkey rollout strategies or are already implementing passkeys.

Passkeys will come and will be the standard authentication method. No doubt. It’s a matter of time. The users are ready. The operating systems are ready. When will you?