How to Test Passkeys on Managed iOS & Android Devices

+70-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

This guide offers developers and test engineers a comprehensive walkthrough to simulate enterprise-managed environments for testing passkey behavior in native iOS and Android applications. We focus on scenarios where corporate policies disable passkey syncing via iCloud Keychain and Google Password Manager, a common setup in corporate environments. This article is technical and based on real-world testing with physical devices.

The guide details the setup of a managed iOS test and a managed Android test environment. By simulating corporate policies that disable passkey syncing, you can validate your application's passkey implementation on managed devices. The procedures are based on hands-on testing with physical devices.

Our goal is to create a test environment that mimics an iPhone where a Mobile Device Management (MDM) profile forbids iCloud Keychain synchronization. This will force passkeys to be "device-bound," stored only in the device's Secure Enclave.

• A physical test iPhone
• A macOS computer
• iMazing Profile Editor: A free tool for creating Apple configuration profiles. Download from the iMazing website or the Mac App Store.
• Apple Configurator: A free tool for supervising devices and deploying profiles. Download from the Mac App Store.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Relying parties can determine if a passkeys work on a device by using the ´isUserVerifyingPlatformAuthenticatorAvailable()´ JavaScript API in the browser.

Let's review the steps to configure the test environment.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

We will use the iMazing Profile Editor to create a profile that disables keychain syncing.

1. Open iMazing Profile Editor.
2. Create a new profile (File > New).

3. In the General section, fill out the details:
   • Name: A descriptive name, e.g., "Disable iCloud Keychain Sync".
   • Identifier: A unique identifier, e.g., com.yourcompany.disablekeychainsync.

4. In the left sidebar, find the Restrictions payload and click Add Payload.

5. Navigate to the iCloud tab within the Restrictions payload.
6. Check the box for Disallow iCloud Keychain sync.

7. Save the profile (File > Save). It will be saved as a .mobileconfig file.

To install the profile, the iPhone must be "supervised," which typically requires a factory reset.

1. Connect the supervised iPhone to your Mac.
2. Open Apple Configurator.
3. Right-click on the device, select Add > Profiles....

4. Choose the .mobileconfig file you just created.
5. On the iPhone, you will likely need to approve the installation. Open the Settings app

6. Search for "Profile" and open the "VPN & Device Management" section.
7. On the bottom of the screen should be the profile you just transferred. Click on it.
8. Tap Install in the top-right corner and follow the on-screen prompts to complete the installation.

9. Confirm by clicking Install again.

10. Click Install again.

11. The profile is successfully installed.

With the "Disable iCloud Keychain" profile active, passkeys become device-bound. They are created and stored exclusively in the device's Secure Enclave and will not synchronize across a user's devices. This is a critical managed iOS test case.

The user experience during passkey creation may differ slightly across iOS versions, but the underlying principle remains the same.

• Passkey Creation: When a user attempts to create a passkey, the operating system will typically proceed with the creation. However, iOS may present a notification to inform the user that the passkey will only be saved on the current device and will not be available on their other devices due to organizational restrictions. The ASAuthorizationController will complete successfully, returning a valid credential.
• Passkey Login: Authentication with an existing device-bound passkey functions as expected. Logging in with a passkey that was previously synced via iCloud Keychain before the policy was enforced also remains operational.

• Passkey Creation: The behavior is different to iOS 18. Passkey creation cannot be completed and the error message from below appears.
• Passkey Login: Works without issue for both device-bound passkeys and previously synced passkeys.

• Passkey Creation: The behavior is consistent to iOS 17. Passkey creation cannot be completed and the error message from below appears.
• Passkey Login: Works without issue for both device-bound passkeys and previously synced passkeys.

For Android, our goal is to set up a "fully managed" device and use a Device Policy Controller (DPC) to block passkey syncing via Google Password Manager. This setup is a common scenario for a corporate managed device.

• An Android device that has been or can be factory reset.
• (Optional) Android Debug Bridge (adb) installed on your computer for inspection.

Let's see the different steps needed to get to our test setup.

We will use a special code during setup to install Google's Test DPC app as the device owner. This grants it full administrative control.

1. Factory reset the Android device.
2. Proceed through the initial setup screens (language, Wi-Fi, etc.).
3. When you reach the Google Account sign-in screen, instead of an email, enter the code: afw#testdpc.
4. The system will now download and install the Test DPC app.
5. Follow the on-screen prompts to set up the device. Agree to make Test DPC the owner of the device. Choose to set up a fully managed device ("USE FOR WORK ONLY").

Once the device is set up, we'll use the Test DPC app to apply the necessary restrictions.

1. Open the Test DPC app from the app drawer.

2. Search for "user restrictions" and select Set user restrictions.
3. Find and enable the following two restrictions by toggling them on:
   • Disallow autofill (DISALLOW_AUTOFILL_SERVICE): This is the primary policy that prevents Google Password Manager (and other autofill services) from saving or providing passkeys.

*   **Disallow modify accounts** (`DISALLOW_MODIFY_ACCOUNTS`): This adds a secondary layer of restriction, preventing users from adding or removing accounts, which can interfere with sync services.

With the above configuration, passkeys should become device-bound. They would be created and stored only in the local Trusted Execution Environment (TEE) and will not sync.

For testing, you might need to enable Chrome from the system apps. To do so:

1. Open the Test DPC app.
2. Search for "enable system apps".
3. Click on the Chrome icon to enable and use it for testing.

Below are the results from our managed Android test on different OS versions.

Passkey creation and login work as long as a device screen lock is set up. However, the passkey is not synced via Google Password Manager, thus it's only available on this one device, making it effectively device-bound.

On Android 14, our managed Android test revealed that the DISALLOW_AUTOFILL_SERVICE policy is highly restrictive. When an application initiates the create call from the Credential Manager API, the operating system may not show any user-facing prompt for passkey creation, including the screen lock or biometrics confirmation. Consequently, passkey creation fails and the API returns an error to the application. This makes it impossible to create or test device-bound passkeys under this specific policy configuration.

The following diagram summarizes the observed behavior in our test environments.

graph TD;
    subgraph "Managed Passkey Test Environment Summary";
        direction LR;

        subgraph "iOS (Managed via Profile)";
            direction TB;
            A["<b>Policy:</b><br/>'Disallow iCloud Keychain'"] --> B["<b>Passkey Creation:</b><br/>Succeeds (Device-Bound)<br/>User is notified it won't sync."];
            A --> C["<b>Passkey Sync:</b><br/>Blocked by Policy"];
        end

        subgraph "Android (Managed via DPC)";
            direction TB;
            D["<b>Policy:</b><br/>'DISALLOW_AUTOFILL_SERVICE'"] --> E["<b>Passkey Creation:</b><br/>Blocked on Android 14+<br/>May succeed on older versions (Device-Bound)"];
            D --> F["<b>Passkey Sync:</b><br/>Blocked by Policy"];
        end
    end
    style A fill:#f9f9f9,stroke:#333,stroke-width:2px
    style B fill:#e8f5e9,stroke:#333,stroke-width:1px
    style C fill:#ffebee,stroke:#333,stroke-width:1px
    style D fill:#f9f9f9,stroke:#333,stroke-width:2px
    style E fill:#fff8e1,stroke:#333,stroke-width:1px
    style F fill:#ffebee,stroke:#333,stroke-width:1px

Testing passkeys in an environment that simulates corporate restrictions is a non-negotiable step for any application intended for enterprise use. By following this guide, you can configure both managed iOS and managed Android devices to create robust test cases for device-bound passkeys.

This validation ensures that your application handles these scenarios gracefully, provides clear user feedback, and maintains a high standard of reliability and security. Proactively testing on a managed device will prevent unexpected issues for your enterprise customers and is a critical part of a comprehensive quality assurance strategy.

Use the free iMazing Profile Editor to create a .mobileconfig file with the 'Disallow iCloud Keychain sync' restriction enabled, then deploy it to a supervised iPhone via Apple Configurator. The iPhone must be supervised, which typically requires a factory reset, but no paid MDM server is necessary.

On Android 14, the DISALLOW_AUTOFILL_SERVICE policy prevents the OS from showing any user-facing prompt during passkey creation, including biometric or screen lock confirmation, so the Credential Manager API returns an error. On Android 12, passkey creation succeeds under the same policy and the credential is stored locally in the TEE without syncing to Google Password Manager.

On managed iOS 18 with iCloud Keychain sync disabled, passkey creation completes successfully via ASAuthorizationController and the user receives a notification that the passkey is device-bound only. On iOS 16 and iOS 17 under the same restriction, passkey creation cannot be completed and an error message is displayed.

Relying parties can use the isUserVerifyingPlatformAuthenticatorAvailable() JavaScript API in the browser to determine if a passkey-capable platform authenticator is available on the device. This check helps applications handle managed device scenarios gracefully before initiating a passkey creation or authentication flow.