iOS 18+/Chrome 136: Automatic Passkey Creation & Upgrades

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

Automatic passkey creation represents a significant leap forward in authentication technology, allowing users to seamlessly upgrade from password-based authentication to passkey-based security without additional friction. This functionality has been implemented by both Apple and Google in their respective browsers and platforms.

In this article, we will explore:

• How automatic passkey creation/upgrades work in general
• Apple's implementation in Safari (iOS 18+, macOS 15+)
• Google's implementation in Chrome 136+
• A detailed comparison between the two approaches

Automatic passkey upgrades eliminate the traditional barrier of asking users to explicitly create passkeys, making the transition from passwords to passkeys invisible and frictionless.

Apple introduced automatic passkey upgrades as part of iOS 18, iPadOS 18, and macOS 15, alongside their new standalone password manager app called Passwords. This implementation was first announced at WWDC 2024 and represents Apple's commitment to making passkey adoption seamless across both web and native app experiences.

You can test the automatic passkey upgrade in this demo.

The introduction of a stand-alone password app shows how crucial passwords, passkeys and secret management is in the eyes of Apple. Apple thereby created an app on the same level as established password managers (e.g. 1Password or Dashlane), “sherlocking” these products. At the same time, Safari 18 supports automatic passkey upgrades.

The upgrades build on the WebAuthn Conditional Registration Extension (see also our other blog post). This extension allows relying parties to register a passkey automatically during password autofill login facilitating a smooth transition from passwords to passkeys.

The important part is that this passkey upgrade happens automatically after a password autofill by the new Passwords app on iOS 18. As autofill triggers a Face ID or Touch ID scan in the same process, the creation of a credential with the iOS 18 authenticator will be allowed. The browser knows that it just mediated a password manager autofill and only then will allow the automatic passkey creation. In other cases (e.g. entering password manually), the conditional mediation will not work, because there is no prior authentication that can count as consent to a passkey creation

If you already have the iOS 18 installed, you can test passkey upgrades with the demo that Nov Matake has created (source code available here). The details and source code examples from Apple can be found here.

We have created some screenshots for you in case you have not installed iOS18 yet:

In the first picture, we start by creating a password-based account and store the password in the new Passwords app by Apple (see the notification at the top of the screenshot).

In the second screen, we log in using the password autofill of the Passwords app. The example app supports Conditional Mediation for passkey creation and therefore a passkey is automatically created, because the security is upgraded with a non-phishable passkey.

Apple has named it “upsell” or passkey upgrade (see the notification on top of the third screenshot).

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Apple's native implementation allows iOS and macOS apps to automatically upgrade password-based sign-ins to passkeys using the Authentication Services framework. The key is using the .conditional request style.

Native iOS/macOS Code Example:

// Automatic passkey upgrade in native apps
func signIn() async throws {
    let userInfo = try await signInWithPassword()
    guard !userInfo.hasPasskey else { return }
 
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier: "example.com")
 
    let request = provider.createCredentialRegistrationRequest(
        challenge: try await fetchChallenge(),
        name: userInfo.user,
        userID: userInfo.accountID,
        requestStyle: .conditional)  // Key parameter for automatic upgrades
 
    do {
        let passkey = try await authorizationController.performRequest(request)
        // Save new passkey to the backend
    } catch {
        // No passkey created this time - continue normally
    }
}

Key Requirements for Native Apps:

• iOS 18+, iPadOS 18+, or macOS 15+
• Device must have a passcode/password set up
• Authentication Services framework integration
• Recent password authentication for the same account
• Use requestStyle: .conditional parameter

The system performs the same checks as the web implementation: verifying that a credential manager is available, the device supports passkeys, and that a password was recently used for the same account.

Information regarding the technical background of passkey upgrades can be found in the current W3C Editor’s Draft. The explainer and the resulting issue for the WebAuthn standard were mainly driven by Apple. But let’s take a look at the actual implementation.

Detect support within browser

// Check if PublicKeyCredential is supported in the current browser
 
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
    return;
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
 
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        if (!capabilities.conditionalCreate) {
            console.log(
                "Conditional create is not supported. Do not continue with mediation.",
            );
            return; // Do not continue with mediation
        }
        console.log("Conditional create is supported. Continue with mediation.");
        // Continue with mediation
    } catch (error) {
        console.error("Error getting client capabilities:", error);
        // Handle the error appropriately
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
    // Handle the case where the method is not supported
}

At first, we need to detect if the passkey upgrade functionality can be used in current browser. At the moment, the only browser that will support it is Safari 18, but more browsers are expected to follow soon. As you can see, the getClientCapabilities() call is used to determine the functionality. This is a new function that has been implemented to reflect all future functionality that might be part of WebAuthn. Safari has supported it since version 17.4.

Part of the result are all information that are helpful from a RP perspective. Keep in mind that this function is not yet implemented in all browsers. Most of the information is currently available via other interfaces, for example: userVerifyingPlatformAuthenticator is available via isUserVerifyingPlatformAuthenticatorAvailable() call.

After detecting support for conditionalCreate, we can use Conditional Mediation in the navigator.credentials.create call:

Implementation of conditional registration:

const options = {
 
    "publicKey": {
        "rp": {
            …
        },
        "user": {
 
            "name": userInfo.user,
            …
        },
        "challenge": …,
        "pubKeyCredParams": […]
    },
    "mediation": "conditional"
};
 
await navigator.credentials.create(options);

As you can see above, the implementation is very similar to Conditional UI. By adding ”mediation”: “conditional” to the PublicKeyCredentialCreationOptions, the process will be triggered by Safari after a password autofill and a passkey will be created.

Resulting passkeys

Passkeys created via the Conditional Create Mediation do not carry the UP or UV flag (see JSON above) because the identification was not part of the actual WebAuthn ceremony. That means that those flags need to be monitored on further authentication ceremonies and the implementation needs to take care that those flags are represented correctly in future ceremonies. During our tests, the UP and UV flag were both set to true, when the automatically created passkey was used for authentication.

Become part of our Passkeys Community for updates & support.

Join

Google introduced automatic passkey creation in Chrome 136 for desktop platforms (Windows, macOS, Linux). Android support is pending due to the ongoing development of the Android Credential Manager API, which needs to stabilize before automatic passkey upgrades can be implemented on Chrome for Android.

Chrome's approach centers around Google Password Manager (GPM) making the decision to create passkeys automatically. The key requirement is that a password must have been used recently (within 5 minutes) for the same username on the same site.

Key features of Chrome's implementation:

• Conditional Creation: Uses the same mediation: 'conditional' approach as Safari
• Time Window: Strict 5-minute window after last password sign-in
• Decision Point: Google Password Manager enclave makes the final decision
• Platform Support: Available on Chrome 136+ for Windows, macOS, and Linux desktop platforms

Chrome's implementation follows the WebAuthn Conditional Registration Extension specification but adds its own constraints and decision-making logic.

Detecting Chrome Support:

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
    const capabilities = await PublicKeyCredential.getClientCapabilities();
    if (capabilities.conditionalCreate) {
        // Chrome 136+ supports conditional passkey creation
        console.log("Conditional create is supported in Chrome");
    }
}

Implementation:

const cred = await navigator.credentials.create({
    publicKey: options,
    mediation: "conditional", // Enables automatic passkey creation
});

Chrome's Decision Process:

1. User signs in with a saved password from Google Password Manager
2. Website calls navigator.credentials.create() with mediation: 'conditional'
3. Chrome checks if the password was used within the last 5 minutes
4. Google Password Manager enclave makes the final decision
5. If approved, a passkey is created automatically with minimal user notification

The implementation leverages Chrome's GPMEnclaveTransaction which performs the eligibility check and creation decision within Google's secure enclave system.

Both Apple and Google have implemented automatic passkey creation, but with different approaches for web browsers and native applications, and varying levels of platform support.

Chrome's Approach: Google Password Manager enforces that a password with the same username must have been used within 5 minutes for an upgrade to succeed. The decision-making process happens within Google's secure enclave:

• Chromium's client controller starts an enclave transaction
• GPMEnclaveTransaction performs the real decision in the enclave
• Strict 5-minute time window is enforced
• Source: Chromium tracking issue and implementation details

Apple's Approach (Web & Native): Both Safari and native iOS/macOS apps use Apple's Authentication Services as the decision-making authority. The process is unified across platforms:

• Safari/WebKit forwards conditional requests to Authentication Services
• Native apps directly use Authentication Services via the conditional request style
• Authentication Services makes the final decision at the OS level
• No published exact time window - Apple recommends calling immediately after password login
• Source: WWDC 2024 session and WebKit implementation

For Chrome:

• Call conditional create within 5 minutes of password authentication
• Ensure Google Password Manager integration is working
• Test with Chrome 136+ on desktop platforms

For Apple Platforms (Safari & Native Apps):

• Call conditional create immediately after successful password login
• For web: Use mediation: 'conditional' with WebAuthn
• For native: Use requestStyle: .conditional with Authentication Services
• Ensure compatibility with Apple's new Passwords app
• Test on iOS 18+, iPadOS 18+, and macOS 15+

For Android (Future):

• Wait for Android Credential Manager API stabilization
• Monitor Chrome Android updates for automatic passkey upgrade support
• Prepare native Android implementations using the expected Credential Manager patterns

Both Apple and Google implementations provide seamless user experiences while maintaining security through their respective enclave systems, though Apple currently has broader platform coverage.

Automatic passkey creation represents a significant milestone in the evolution of authentication, with Apple leading the way by implementing comprehensive support across both web browsers and native applications, while Google has made strong progress on desktop web browsers with Android support pending.

Key Takeaways:

• Apple's Comprehensive Approach: Full support across Safari 18+, iOS 18+, iPadOS 18+, and macOS 15+ for both web and native applications
• Google's Desktop Focus: Chrome 136+ provides excellent desktop web support, but Android implementations are pending Credential Manager API stabilization
• Unified Decision Models: Apple uses Authentication Services across all platforms, while Google leverages Password Manager enclaves for web browsers
• Platform Fragmentation: Currently, automatic passkey upgrades work best on Apple platforms due to their integrated ecosystem approach

Industry Outlook:

Apple's comprehensive implementation across web and native platforms demonstrates the potential of automatic passkey upgrades. Google's pending Android support will be crucial for widespread adoption, as it will complete the ecosystem coverage needed for developers to confidently implement automatic upgrades across all major platforms.

The current state shows that automatic passkey creation is ready for production use on Apple platforms and Chrome desktop, making it essential for developers to implement these features to stay competitive and provide users with the most secure and convenient authentication experience available.