Passkeys for Google Accounts: UX decisions inside the rollout
Passkeys let users sign in with a device screen lock—fingerprint, face, or PIN—instead of typing a password. Google helped build the underlying FIDO infrastructure and also runs one of the largest services using it. That puts the company on both sides: refining the platform and measuring how a real, high-traffic deployment behaves. Google’s passkey rollout for Google Accounts has been gradual, with UX choices driven by internal research and live feedback. The screenshot sequence below shows the production flow as it exists today.
How users are introduced to the new flow
Authentication research consistently shows that convenience, not security, is what users value most. People want to get through sign-in quickly and move on to the actual experience. Passkeys require changing old habits, though, so users need a concrete reason to switch. The Google Account passkey screens were designed around two principles at every step: ease of use and security.
Lead with what the user gains
The first passkey screen keeps the message light and digestible. The headline focuses on the benefit: “Simplify your sign in.” Body copy follows with “With passkeys you can now use your fingerprint, face or screen lock to verify it’s really you.” The visual grounds that message, and the primary action button pushes users forward. A “Not now” secondary action keeps the decision with the user, and “Learn more” is available for those who want details before committing.
Google tested many variations during sign-in, including copy that emphasized security, the technology itself, and other angles. Convenience consistently won. The final design uses illustration, interaction, and content to make that point first.
Build familiarity with “passkeys” by pairing it with known terms
Passkeys are new to most people, so the term is surfaced throughout the sign-in flow in body copy rather than in headings. Each mention is deliberately placed next to experiences users already associate with security: fingerprint, face scan, or device screen lock. Internal research shows users broadly connect biometrics with safety. Passkeys don’t require biometrics—a device PIN works too—but associating them with biometrics helps users see the security value of the new tech.
The “Learn more” content goes deeper, including reassurance that biometric data stays on the personal device and is never stored or shared when creating or using passkeys. Most users found the convenience appealing, but only a few mentioned the biometric element unprovoked.
Time the introduction for when it lands
Not every user sees the passkey introductory screen. Google’s heuristics select accounts based on factors like whether two-step verification is enabled and whether the account is regularly accessed from the same device. The goal is to start with users most likely to succeed and expand gradually. Anyone can begin directly at g.co/passkeys regardless.
For selected users, the prompt to create a passkey arrives right after a successful username-and-password sign-in. That point in the journey makes sense for a few reasons:
- Users just entered their credentials and are aware of their authentication steps.
- They are demonstrably on their own device, not a shared machine.
- A sign-in attempt that succeeds gives “make next time easier” a tangible payoff.
Position passkeys as an alternative, not a replacement
Initial research shows many users still want a password as a fallback sign-in method, and not everyone has the technology required to use passkeys. While the industry narrative (Google included) points toward a passwordless future, the Google UI treats passkeys as a simple and secure alternative to passwords. The screens focus on passkey benefits without implying passwords are going away.
The enrollment step
When a user opts in, the browser presents a platform-specific modal to create the passkey. The passkey appears with the industry-standard icon plus the display name and username used to generate it. FIDO Alliance guidance recommends using the proven passkeys icon, and Google shows it consistently throughout the journey so users recognize it during sign-in and management. The icon never appears without context.
After the user clicks “Continue,” the modal varies by platform. Internal research found that a confirmation screen after creation materially improves comprehension and gives the step closure.
The confirmation page is a deliberate pause that bookends the whole introduction-and-creation arc. This is likely the first passkey a user has ever made, so the page gives a structured ending. Google tried smaller tools like notifications and even a follow-up email before settling on a standalone page. Clicking “Continue” on that page drops the user at their destination.
Signing back in
The next sign-in screen reuses the layout, illustration, and primary call to action from the creation flow. Users who enrolled already recognize the steps. The WebAuthn UI text stays brief and generic so the same screens work for both authentication and reauthentication.
Where passkeys live in account settings
Adding a passkey management page to Google Account settings meant mapping existing navigation, hierarchy, and content patterns so the new page feels native.
Group passkeys by ecosystem
Google groups passkeys by the ecosystem where they were created and used, so users can tell where each one lives. The labels use each provider’s own ecosystem name: Google Password Manager, iCloud Keychain, and Windows Hello. Each passkey entry carries metadata like creation and last-used date plus the specific OS. Administratively, the API supports only three actions: renaming, revoking, and creating.
Renaming lets users assign personally meaningful names, which helps some cohorts track and distinguish their passkeys. Revoking a passkey doesn’t remove it from the user’s password manager (e.g., Google Password Manager); it just makes the passkey unusable until set up again. The action is shown with a cross icon rather than a trash can to reflect that. For enrollment copy, “Create passkey” tested better with users than “Add a passkey”—a deliberate wording choice that separates passkeys from physical hardware security keys, even though passkeys can be stored on some of them.
Support content was ready at launch
Passkey usage itself was fairly seamless in internal testing, but users still had questions. Google published help content at launch explaining how the technology works behind the screen lock, why it is more secure, and the common “what if” scenarios uncovered during UX testing. Having that material available at release is essential for any service adopting passkeys.
Leaving the new system is straightforward: “try another way” on the auth prompt, or exiting the WebAuthn UI, both route users back to traditional credential entry or another passkey attempt.
Principles for passkey UX
The long-term direction of the passkey experience on Google Accounts will continue to evolve with user feedback and real-world data. For anyone designing passkey flows today, Google’s take boils down to four principles:
- Introduce passkeys when they are relevant to the user’s current context.
- Emphasize the convenience benefits of passkeys, not just the security story.
- Use every opportunity to build user familiarity with the concept.
- Present passkeys as an alternative to passwords users already trust, not a forced upgrade.
