Android 16 Passkeys: What new Features did Google ship?

While some operating system updates announce their arrival with a single, headline-grabbing feature, the story of passkeys in Android 16 is one of quiet, foundational maturation. Instead of one revolutionary change, Google has delivered a suite of deeply impactful enhancements that collectively bolster the entire digital identity ecosystem. This update represents a strategic move to make passkeys more secure, practical, and enterprise-ready than ever before.

The central theme of Android 16's passkey evolution is the systematic dismantling of the final barriers to mass adoption. For years, the promise of a passwordless future has been hampered by three persistent concerns: the user's fear of losing account access when changing devices, the tangible threat of physical device theft, and the lack of granular controls necessary for corporate deployment. Android 16 addresses each of these challenges head-on.

This blog post provides a deep dive into the four pillars of this evolution. It will explore the seamless account recovery enabled by the new Restore Credentials feature, the hardened on-device security provided by Identity Check, the "gold standard" endorsement of passkeys within the Advanced Protection Mode and the critical new enterprise controls that could finally unlock widespread adoption for managed workf devices.

One of the most significant psychological barriers to the adoption of passwordless technology has been the user's fear of irreversible account loss. Born from an era of device-bound hardware security keys that were tied to a single device, this anxiety has made many users hesitant to abandon passwords, which, despite their vulnerabilities, offer familiar (though insecure) recovery flows. Android 16 directly confronts this "new phone problem" with Restore Credentials, a feature designed to make migrating to a new device a completely seamless and secure experience.

From the user's perspective, the Restore Credentials feature is designed to be invisible. The process is automatic and occurs entirely in the background during the setup of a new device. When a user restores their apps and data, either via a local device-to-device transfer or from an encrypted cloud backup, their applications are already signed in and ready to use. There is no need to manually re-enter usernames, passwords or even re-authenticate with a passkey. The experience is so fluid that users may receive notifications from their apps on their new device before they have even been opened for the first time, fostering a sense of continuity and eliminating a major point of friction.

The mechanism powering this seamless experience is a special type of credential known as a "restore key." Critically, this is not a proprietary token but a public key fully compatible with FIDO2 standards, the same foundation upon which passkeys are built. This ensures the feature operates within the open, standardized WebAuthn ecosystem. The process is managed through Android's Credential Manager API and can be broken down into three stages for developers:

1. Creation: After a user has successfully authenticated within an app, the developer can make an API call to generate a restore key. This is done by sending a CreateRestoreCredentialRequest to the createCredential method. The
   registrationJson required for this request is the same as that used for creating a standard passkey, highlighting the shared architecture and simplifying implementation for developers already supporting passkeys.

2. Storage and Sync: The generated restore key is stored locally on the device within the encrypted Credential Manager. Developers have the option to set an isCloudBackupEnabled flag to true. When this is enabled and the user has Google Backup active with end-to-end encryption, the restore key is securely synced to the cloud. This provides a strong and resilient recovery path that is not dependent on the old device being functional.

3. Restoration: During a new device setup, the restore keys are transferred along with other app data. The application on the new device can then call the getCredential method with a GetRestoreCredentialOption to retrieve the key. This allows the app to silently re-authenticate the user in the background, completing the seamless sign-in process.

For correct implementation, developers are strongly advised to call the clearCredentialState method as soon as a user signs out of the app. This action deletes the associated restore key and prevents a potential scenario where a user who intentionally signs out is immediately and automatically logged back in upon their next app launch.

This feature fundamentally elevates the passkey value proposition. It transforms a passkey from a credential that is simply "synced" across devices within a vendor's ecosystem into a truly portable identity that survives the natural lifecycle of device migration. By building this UX on top of the open FIDO2 standard, Google is making a user's account and its associated backup functionality the central, trusted hub for their identity portability. This makes passkeys a far more practical and trustworthy replacement for passwords for the average user.

While passkeys are resistant to remote phishing attacks, their security is ultimately tied to the security of the device itself. A prevalent real-world threat model is "shoulder surfing," where an attacker observes a user's PIN or pattern before stealing their phone. With both the device and its fallback credential, an attacker could potentially access everything stored on it, including password managers and the passkeys they contain. Android 16's Identity Check feature is a direct and powerful countermeasure to this physical threat.

Initially limited to Google Pixel and select Samsung devices, Identity Check is being integrated as a core platform capability in Android 16, making it available to all device manufacturers. The feature introduces a context-aware security model that operates based on user-defined "trusted locations," such as a home or office Wi-Fi network.

When the device detects that it is outside of these trusted locations, it automatically enters a heightened security state. In this state, performing sensitive actions requires biometric authentication (a fingerprint or face scan). Most importantly, the system disables the ability to use the PIN, password or pattern as a fallback credential for these actions. This change is critical, as it renders the knowledge gained from shoulder surfing useless for accessing the most sensitive data and settings.

The list of actions protected by Identity Check is extensive, but one is important to the security of the passkey ecosystem: "Accessing saved passkeys and app passwords". This means a thief who has stolen a phone and knows the PIN cannot simply open the Google Password Manager and view or use the stored passkeys if the device is not in a trusted location.

This feature fundamentally strengthens the security guarantee of passkeys. It addresses the weakest link in the security chain, the observable PIN, by intelligently shifting the authentication requirement. In low-risk, trusted environments, the convenience of a PIN fallback is maintained. In high-risk, untrusted environments, the system enforces the superior security of an un-shareable biometric trait. By explicitly protecting access to passkeys, Identity Check is not merely a generic device security feature. It is a direct and material upgrade to the passkey security model. Its expansion to all OEMs via Android 16 transforms this from a premium, vendor-specific benefit into a universal platform standard, building greater trust in passkeys as a robust authentication method across the entire ecosystem.

For users at high risk of targeted cyberattacks, Android 16 enhances Google's Advanced Protection Program with a device-level Advanced Protection Mode. This mode acts as a one-tap security lockdown, enforcing strict policies like blocking app sideloading and restricting insecure network connections to minimize the device's attack surface.

The most significant aspect of this feature is its core requirement: to enroll in the program, a user must use a passkey or a hardware security key to sign in to their Google account. Passwords are not considered sufficiently secure for this tier of protection.

By mandating FIDO2 credentials for its highest-security offering, Google makes a powerful statement that passkeys are the designated gold standard for modern, secure authentication. This endorsement is vital for driving adoption within security-conscious communities and large enterprises.

A critical update in Android 16 for corporate adoption is a new policy for the Android Work Profile, which creates a secure container on a device that isolates work apps and data.

IT administrators can now allow or disallow specific credential managers within the Work Profile. This provides granular control and solves the "shadow IT" problem where an employee might use a personal password manager for a corporate passkey. Enterprises can now mandate that only an IT-approved credential manager is used for work-related services. This prevents credential sprawl, ensures all corporate passkeys are managed according to company policy and removes a major security obstacle for widespread passkey adoption in the enterprise.

The passkey enhancements in Android 16 represent the deliberate maturation of an entire ecosystem, making passkeys more usable, resilient, secure and enterprise-ready.

With Restore Credentials, Google has solved the key usability challenge of device migration. With Identity Check, it has hardened physical device security. By mandating passkeys in its Advanced Protection Mode, it has endorsed them as the gold standard for security. Finally, new enterprise policies for the Work Profile provide the granular control necessary for widespread corporate adoption.

Taken together, these updates demonstrate a clear commitment to a passwordless future, making passkeys the logical and superior choice over passwords. For both developers and enterprises, Android 16 marks a pivotal moment to begin implementing and planning for this transition.