isUVPAA() on iOS / macOS / Android / Windows [2025]

As passkeys become an increasingly prevalent method for secure authentication, one of the primary concerns for developers is determining whether a specific device is equipped to handle passkeys. To address this, browsers offer a function called isUserVerifyingPlatformAuthenticatorAvailable(), often also referred to as isUVPAA().

This function can be used reliably to determine if the operating system in general has a platform authenticator (e.g. Touch ID, Face ID or Windows Hello). It will return false or not exists, in case a platform authenticator does not exist and using passkeys is impossible.

A short way to test if isUserVerifyingPlatformAuthenticatorAvailable() returns true is to visit the Passkey Debugger and look out for Platform Auth being set:

Platform Authenticator Check on www.passkeys-debugger.io

However, there's often confusion regarding what it means when this function returns true, as different operating systems have varying interpretations and implementations of this functionality to nudge users to actually activate the platform authenticator. In some cases, even when the function returns true, users may still need to perform additional steps before they can fully utilize passkeys.

This article aims to clarify these ambiguities by answering two key questions for each major operating system:

1. Return Value: Under which conditions does isUserVerifyingPlatformAuthenticatorAvailable() return true?
2. UI Documentation: If additional steps are required for users to enable passkey functionality, what do these steps look like in practice?

The information provided is based on the latest versions of the operating systems available (excluding beta versions), offering a realistic and up-to-date perspective on passkey-readiness. Excluded from our tests are combinations with third-party password managers & storage of passkeys in Chrome profiles (on macOS).

In this review of isUserVerifyingPlatformAuthenticatorAvailable(), for Apple devices, we only look into the current major version iOS 17. There have been versions and bugs in earlier iOS versions that can be found here and here. For our tests on Apple devices, we will use Safari as browser.

To use passkeys on an iOS 17, iPadOS 17 and macOS Sonoma device, the following conditions must be met:

• iCloud must be set up with an Apple ID
• iCloud Keychain must be enabled
• Device needs a passcode or password as local authentication (biometrics are optional)

When all conditions are met, a passkey can be created directly without additional configuration.

Apple always returns isUserVerifyingPlatformAuthenticatorAvailable() as true, irrespective of whether all conditions are met.

There is only one exception:

isUserVerifyingPlatformAuthenticatorAvailable() returns false in the case of a managed device that is prohibited from using iCloud in general or iCloud Keychain specifically because the user has no chance to activate them, because the enterprise company policy prevents it.

In case the device has no passcode or password set for local authentication (screen lock), this is the first message that the user would receive, when trying to create a passkey (screenshot from an iPad with Touch ID):

Usage of biometrics is optional, as passkeys can work just with a passcode. Even if the device has no passcode set up, isUserVerifyingPlatformAuthenticatorAvailable() will return true. iPhones and macOS devices behave in a similar way.

In case the device has no iCloud account connected (the user is not signed in) or iCloud Keychain is disabled, then the user will see a suggestion to turn on iCloud Keychain in the device settings:

After activating iCloud Keychain, the passkey can be created. Therefore, the user must return to the website and retry the passkey creation. Even if iCloud Keychain is disabled, isUserVerifyingPlatformAuthenticatorAvailable() will return true.

Apple encourages the adoption of passkeys by pushing users to activate iCloud Keychain. While at first glance, this might seem concerning from a UX perspective – because user might be confused by unexpected operating system modals, Apple has started to turn on iCloud Keychain by default in iOS 17, thereby enrolling many Apple users into Keychain already (we suspect this being precisely because of passkeys – which has led also to some critical comment about missing user consent). With iOS 18 on the horizon, especially in the consumer space, it is safe to say that onboarding on versions iOS 17 and higher should be smooth as the adoption of passkeys increases through iCloud Keychain.

A lot is going on around passkey development in Chromium and Android. In our tests, we will focus on the default browser Chrome on Android.

To use passkeys on a Google device, you need to:

• Be logged in to a Google Account
• Device needs to be protected with a screen lock (at least PIN; Biometrics are optional)

When those two conditions are fulfilled, a passkey can be created directly.

Google is a bit stricter than Apple: it requires at least a screen lock with PIN to be set for isUserVerifyingPlatformAuthenticatorAvailable() to return true. The same restrictions apply to managed devices. If a Google device cannot activate a Google Account, isUserVerifyingPlatformAuthenticatorAvailable() will return false.

In case the Android device has no screen lock with PIN set, the user would see the following screen.

Additional biometrics are not necessary to be set up, as a PIN is sufficient to use passkeys on an Android device. If a screen lock with at least PIN is not set isUserVerifyingPlatformAuthenticatorAvailable() will return false.

If the device does not have a Google Account enabled or logged in, the user will see a prompt to sign in to a Google Account to enable passkey functionality.

Without a Google Account, isUserVerifyingPlatformAuthenticatorAvailable() will still return true and nudge the user to sign in. Google Password Manager for passkeys cannot be turned off when using a Google Account.

Android devices are tightly integrated with Google Accounts, making it unlikely for users to encounter scenarios where they don’t have an active Google Account on their Android. This integration ensures that most Android devices meet the requirement of being logged into a Google Account, which is essential for utilizing passkeys. Additionally, screen locks, such as PINs or patterns, have become a default security feature on most Android devices. This widespread adoption means that most devices are already configured to support passkeys, further simplifying the onboarding process for users.

From a passkey perspective, one of the key advantages of the Google ecosystem is that the Google Password Manager (GPM) cannot be disabled. This ensures that passkey support is consistently available on any device logged into a Google Account with a screen lock enabled.

Windows has the strictest requirements for isUserVerifyingPlatformAuthenticatorAvailable() to return true. Our tests are carried out with Edge. The isUserVerifyingPlatformAuthenticatorAvailable() function will only return true under the following condition:

Windows Hello Must Be Set Up: The device must have Windows Hello configured with at least a PIN. This is the primary method Windows uses to verify the user's identity for passkey functionality.

Further biometric authentication methods, such as facial recognition or fingerprint, are optional but not required. Since all Windows passkeys are currently device-bound, there is no need for the user to add any online account or service for passkey functionality. As a result, users do not encounter any additional screens to activate passkeys once Windows Hello is set up.

As we have seen above there are situation where although the browser signals support of passkeys via returning isUserVerifyingPlatformAuthenticatorAvailable() = true the user might need to be onboarded to Passkeys by adding a Passcode or signing in to his Cloud account. We call this process Passkey Onboarding.

Below is a short summary table what isUserVerifyingPlatformAuthenticatorAvailable() returns under different scenarios. Usually after this call return true, navigation.credentials.create() will be used to create a passkey that might then trigger the onboarding modals we have seen above.

Orange coloring in the table indicates where additional instructions may be displayed to guide users through the passkey setup process if necessary:

Therefore, isUserVerifyingPlatformAuthenticatorAvailable() returning true as of today can be reliably used to trigger as passkey creation and in rare cases Passkey Onboarding steps will need to be taken.

With the development of the ecosystem, the adoption of passkeys across major operating systems is becoming more seamless. With iCloud Keychain and Google Password Manager increasingly set as default, most users on Apple and Android devices will find that they are already prepared to use passkeys without additional onboarding steps. These defaults simplify the user experience, making the transition to passkeys straightforward and unobtrusive.

Looking ahead, it will be interesting to observe how Microsoft adapts, particularly with the potential introduction of synchronized passkeys. For this, Microsoft would need to integrate Microsoft Accounts with the Windows Hello Authenticator and pursue a robust strategy to ensure a high percentage of users can utilize synchronized passkeys. By taking these steps, Microsoft could align with the user-friendly passkey experiences offered by Apple and Google, further advancing the adoption of passkeys and enhancing security across all major platforms.