---
url: 'https://www.corbado.com/blog/isUserVerifyingPlatformAuthenticatorAvailable'
title: 'isUVPAA() on iOS / macOS / Android / Windows [2026]'
description: 'Learn about isUserVerifyingPlatformAuthenticatorAvailable() return values & what they mean across iOS 17, Android 14, and Windows 11 for passkey onboarding.'
lang: 'en'
author: 'Vincent Delitz'
date: '2024-09-04T19:00:34.026Z'
lastModified: '2026-03-25T10:00:40.299Z'
keywords: 'isUVPAA(), isUserVerifyingPlatformAuthenticatorAvailable(), passkey bootstrapping'
category: 'Passkeys Strategy'
---

# isUVPAA() on iOS / macOS / Android / Windows [2026]

> ⚠️ **iOS 26.2 Breaking Change:** As of December 2025, `isUVPAA()` returns `false` on all
> [WKWebView](https://www.corbado.com/blog/native-app-passkeys)-based [iOS](https://www.corbado.com/blog/webauthn-errors) browsers
> (Chrome, Edge, Firefox) due to a WebKit bug. See our article on fixing passkey detection
> with [getClientCapabilities](https://www.corbado.com/blog/webauthn-client-capabilities)() for the recommended
> workaround.

## Key Facts

- **Apple's managed device exception**: isUVPAA() returns `true` on all Apple devices
  unless enterprise policy specifically prohibits iCloud or iCloud Keychain use.
- **Android screen lock requirement**: isUVPAA() returns `false` without a screen lock
  PIN. Without a Google Account, it returns `true` but prompts the user to sign in.
- **Windows Hello** must be configured with at least a PIN for isUVPAA() to return `true`.
  Windows has the strictest platform authenticator requirements of the three platforms.
- **iOS 26.2 breaking change**: As of December 2025, isUVPAA() returns `false` on all
  WKWebView-based iOS browsers including Chrome, Edge and Firefox due to a WebKit bug.
- **iCloud Keychain** is enabled by default in iOS 17, meaning most Apple users are
  already passkey-ready without additional onboarding steps.

## 1. Introduction

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](https://www.passkeys-debugger.io/) and look out for
Platform Auth being set:

![platform auth passkeys debugger](https://www.corbado.com/website-assets/platform_auth_passkeys_debugger_a7b1d28dc6.png)

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](https://www.corbado.com/glossary/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](https://state-of-passkeys.io). Excluded from our tests are
combinations with third-party password managers &
[storage of passkeys](https://www.corbado.com/faq/when-are-passkeys-stored) in Chrome profiles (on macOS).

## 2. What Does isUVPAA() Return on iOS 17, iPadOS 17 & macOS Sonoma?

In this review of `isUserVerifyingPlatformAuthenticatorAvailable()`, for Apple devices, we
only look into the current major version [iOS 17](https://www.corbado.com/blog/apple-passkeys-integration). There
have been versions and bugs in earlier [iOS](https://www.corbado.com/blog/webauthn-errors) versions that can be
found
[here](https://forums.developer.apple.com/forums/search?q=isUserVerifyingPlatformAuthenticatorAvailable)
and
[here](https://bugs.webkit.org/buglist.cgi?bug_status=__all__&content=isUserVerifyingPlatformAuthenticatorAvailable&no_redirect=1&order=Importance&query_format=specific).
For our tests on Apple devices, we will use Safari as browser.

### 2.1 Requirements to Use Passkeys on Apple Devices

To use passkeys on an [iOS 17](https://www.corbado.com/blog/apple-passkeys-integration), iPadOS 17 and macOS
Sonoma device, the following conditions must be met:

- iCloud must be set up with an Apple ID
- [iCloud Keychain](https://www.corbado.com/glossary/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.

### 2.2 Apple Always Returns true for isUVPAA()

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](https://www.corbado.com/glossary/icloud-keychain) specifically because the user has no chance
to activate them, because the enterprise company policy prevents it.

### 2.3 Device Has No Passcode or Password

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](https://www.corbado.com/blog/passkey-creation-best-practices) (screenshot from an iPad with
Touch ID):

![ipados passkeys require touch id](https://www.corbado.com/website-assets/ipados_passkeys_require_touch_id_31a5a5bfe7.png)

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.

### 2.4 Device Has No iCloud Account or Keychain Is Disabled

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](https://www.corbado.com/glossary/icloud-keychain) in the device settings:

![ipados passkeys enable icloud keychain](https://www.corbado.com/website-assets/ipados_passkeys_enable_icloud_keychain_a41ffaaa46.png)

After activating iCloud Keychain, the passkey can be created. Therefore, the user must
return to the website and retry the
[passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices). Even if iCloud Keychain is
disabled, `isUserVerifyingPlatformAuthenticatorAvailable()` will return `true`.

Please also see our article on how to test on
[managed iOS](https://www.corbado.com/blog/passkeys-managed-ios-android-testing) and
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) devices if you want to understand the
passkey behavior on managed devices better.

### 2.5 Summary of Passkey Onboarding on iOS 17, iPadOS 17 & macOS Sonoma

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](https://defcon.social/@mysk/111167154833155521)**,
thereby enrolling many Apple users into Keychain already (we suspect this being precisely
because of passkeys – which has led also to some
[critical comment](https://mjtsai.com/blog/2024/05/21/apple-updates-silently-enable-icloud-keychain/)
about missing user consent). With
[iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) on the horizon, especially in
the consumer space, it is safe to say that onboarding on versions
[iOS 17](https://www.corbado.com/blog/apple-passkeys-integration) and higher should be smooth as the
[adoption of passkeys](https://state-of-passkeys.io) increases through iCloud Keychain.

## 3. What Does isUVPAA() Return on Android 14?

A lot is going on around passkey development in Chromium and
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). In our tests, we will focus on the
default browser Chrome on [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android).

### 3.1 Requirements to Use Passkeys on Android Devices

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.

### 3.2 Google Always Returns True for isUVPAA() If Screen Lock PIN Is Set

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.

### 3.3 Android Device Has No Screen Lock with PIN

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

![android set up screen lock passkeys](https://www.corbado.com/website-assets/android_set_up_screen_lock_passkeys_9dae55f238.png)

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**.

### 3.4 Device Has No Google Account Enabled

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.

![android sign in google account passkeys ](https://www.corbado.com/website-assets/android_sign_in_google_account_passkeys_79e81fe7e2.png)

Without a Google Account, `isUserVerifyingPlatformAuthenticatorAvailable()` will still
return true and nudge the user to sign in.
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) for passkeys cannot be
turned off when using a Google Account.

### 3.5 Summary of Passkey Onboarding on Android 14

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](https://www.corbado.com/blog/how-to-use-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.

## 4. What Does isUVPAA() Return on Windows?

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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkeys-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](https://www.corbado.com/glossary/windows-hello) is
set up.

## 5. Passkey Onboarding Summary: iOS 17, Android 14 and Windows 11

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](https://www.corbado.com/blog/passkey-creation-best-practices) 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**:

![Passkey Onboarding Overview](https://www.corbado.com/website-assets/Screenshot_2024_09_04_210420_1857c22064.png)

**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.**

## 6. Conclusion

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](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/user-transition-passkeys-expert-strategies) 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](https://www.corbado.com/glossary/windows-hello)
[Authenticator](https://www.corbado.com/glossary/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.

## Frequently Asked Questions

### How do I handle isUVPAA() returning false on iOS 26 browsers like Chrome or Edge?

As of December 2025, a WebKit bug in iOS 26.2 causes isUVPAA() to return false on all
WKWebView-based browsers including Chrome, Edge and Firefox. The recommended workaround is
to use getClientCapabilities() for passkey detection instead of relying on isUVPAA()
alone.

### What actually happens when isUVPAA() returns true but a user has not set up iCloud Keychain on their iPhone?

On iOS, isUVPAA() returns true even when iCloud Keychain is disabled or no iCloud account
is connected. When the user attempts passkey creation, iOS displays a system modal
prompting them to enable iCloud Keychain in device settings. After enabling it, the user
must return to the website and retry passkey creation.

### Why does Android behave differently from iOS when evaluating isUVPAA() with no screen lock set?

Android is stricter than iOS: it returns false for isUVPAA() if no screen lock PIN is set,
whereas iOS returns true even without a passcode configured. This means Android gives
developers a more reliable signal about whether passkey creation will actually succeed
without requiring onboarding steps.

### What are the minimum requirements for isUVPAA() to return true on Windows 11?

On Windows, Windows Hello must be configured with at least a PIN for isUVPAA() to return
true. Biometric methods like facial recognition or fingerprint are optional but not
required. Since Windows passkeys are currently device-bound, no Microsoft Account or cloud
sync setup is needed.