Uses of Passkey Authentication for Google Account

Passkey authentication for Google Accounts is a passwordless sign-in method designed to enhance both security and user convenience. Developed by the FIDO Alliance in collaboration with major tech companies like Google, Apple, and Microsoft, passkeys leverage public-key cryptography to provide a phishing-resistant, user-friendly alternative to traditional passwords.

Passkeys are digital credentials that allow users to authenticate their identity without entering a username or password. Instead, they rely on biometric authentication (e.g., fingerprint or face scan), a PIN, or a device screen lock to verify the user’s identity. Unlike passwords, which are shared secrets vulnerable to phishing and breaches, passkeys are device-bound, phishing-resistant credentials that rely on a user’s device (e.g., smartphone, computer, or hardware security key) and a user verification method (e.g., biometric or PIN). They are designed to simplify sign-ins while enhancing security, making them a core component of Google’s push toward a passwordless future.

Technical Foundation: FIDO2 and WebAuthn

Passkeys are built on the FIDO2 framework, which consists of two main components:

  1. WebAuthn (Web Authentication): A W3C standard that defines how browsers and websites interact with authenticators (e.g., devices or security keys) to perform secure authentication.
  2. CTAP (Client to Authenticator Protocol): A FIDO Alliance standard that governs communication between the authenticator (e.g., a smartphone or hardware key) and the client device (e.g., a browser).

Together, these standards enable passkeys to:

  • Ensure credentials are scoped to a specific website or app, preventing phishing attacks.
  • Generate and manage public-private key pairs.
  • Authenticate users without transmitting sensitive data to the server.

Passkeys operate using public-key cryptography, where a private key is securely stored on the user’s device, and a corresponding public key is shared with the relying party (in this case, Google). Below is a detailed breakdown of the process, divided into creation and authentication phases.

1. Passkey Creation

When a user creates a passkey for their Google Account, the following occurs:

  1. Initiation:
    • The user navigates to Google’s passkey settings or is prompted during sign-in to create a passkey.
    • The browser (e.g., Chrome) communicates with Google’s servers using the WebAuthn API.
  2. Key Pair Generation:
    • The user’s device (e.g., Android phone, iPhone, Windows PC or a hardware security key) generates a public-private key pair unique to the Google Account and the specific website (accounts.google.com).
    • The private key is securely stored in the device’s secure enclave (within a Trusted Execution Environment (TEE) like Android’s TrustZone) or trusted platform module (TPM), or within a password manager like Google Password Manager or iCloud Keychain. It never leaves your device and is protected by your device’s screen lock (PIN, pattern, fingerprint, face scan).
    • The public key is sent to Google’s servers and associated with the user’s account. This key is stored with Google (the service provider).
  3. User Verification:
    • The device requires user verification to ensure the passkey is created by the account owner. This typically involves:
      • Biometric authentication (e.g., fingerprint or face scan).
      • A device PIN or pattern.
      • For hardware security keys, a PIN or biometric input (if supported).
    • Biometric data never leaves the device; it’s used only to unlock the private key locally.
  4. Storage and Syncing:
    • The passkey is stored on the device or synced via a password manager:
      • On Android, passkeys are automatically stored in Google Password Manager and synced across devices signed into the same Google Account.
      • On iOS/macOS, passkeys are stored in iCloud Keychain (if enabled) for syncing across Apple devices.
      • Third-party providers like 1Password or NordPass can also store passkeys for cross-platform use.
    • The passkey is scoped to Google’s domain, ensuring it can only be used for Google services.
  5. Completion:
    • Google registers the public key and associates it with the user’s account. The passkey is now ready for authentication.
    • Users can create multiple passkeys for different devices or security keys.

2. Passkey Authentication

When a user signs into their Google Account using a passkey, the process is as follows:

  1. Sign-In Request:
    • The user visits a Google service (e.g., Gmail) and selects the passkey sign-in option (or it’s prompted automatically if set as the default).
    • Google’s server sends a challenge (a random string of data) to the browser via WebAuthn.
  2. Device Selection:
    • If the passkey is on the same device, the browser communicates with the device’s authenticator (e.g., secure enclave or password manager).
    • For cross-device authentication (e.g., signing into a laptop using a phone), the browser displays a QR code or prompts the user to select a trusted device via Bluetooth or USB (for hardware keys).
  3. User Verification:
    • The device prompts the user to verify their identity using:
      • Biometric authentication (fingerprint, face scan).
      • A PIN or device passcode.
      • For hardware keys, a PIN or button press.
    • This step ensures only the authorized user can access the private key.
  4. Signature Generation:
    • The device retrieves the private key from its secure storage.
    • It signs the challenge from Google with the private key, creating a digital signature.
    • The signature is sent back to Google’s server via the browser.
  5. Verification by Google:
    • Google’s server uses the stored public key to verify the digital signature.
    • If the signature is valid, the user is authenticated and granted access to their account.
  6. Cross-Device Authentication:
    • For cross-device scenarios (e.g., phone to laptop), the phone scans a QR code displayed on the laptop. The phone performs the signature process and communicates the result to the laptop’s browser, which forwards it to Google.
    • Alternatively, if devices are “remembered” (via prior pairing), the phone can authenticate over Bluetooth without a QR code.
  7. Session Establishment:
    • Once verified, Google establishes a secure session, and the user is logged in.
    • The passkey replaces the need for a password and, in most cases, additional 2FA steps, as it combines possession (the device) and knowledge/inherence (PIN or biometric).

Passkeys leverage public-key cryptography, secure hardware, and standardized protocols to provide a passwordless authentication system that is resistant to common attack vectors like phishing, credential theft, and brute-force attacks. These mechanisms work together to protect Google Accounts by ensuring that credentials are device-bound, scoped to specific services, and accessible only to verified users. Below, I’ll detail each security mechanism, explaining how it functions, its role in securing Google Accounts, and how it mitigates specific risks.

Mechanism:

  • Passkeys rely on public-key cryptography, specifically asymmetric encryption, to authenticate users without sharing sensitive credentials.
  • During passkey creation, a unique public-private key pair is generated for the Google Account:
    • The private key is securely stored on the user’s device (e.g., in a secure enclave or trusted platform module) or within a password manager like Google Password Manager.
    • The public key is sent to Google’s servers and associated with the user’s account.
  • When signing in, the device signs a challenge (a random nonce) from Google with the private key, creating a digital signature. Google verifies this signature using the public key.

Security Benefits:

  • No Shared Secrets: Unlike passwords, which are shared with the server and stored in a hashed form, the private key never leaves the device. This eliminates the risk of credential theft from server breaches.
  • Immunity to Interception: Since only the public key is shared, and it’s useless without the private key, attackers cannot misuse intercepted data.
  • Cryptographic Strength: Passkeys typically use strong algorithms like ECDSA (Elliptic Curve Digital Signature Algorithm) with the P-256 curve, providing high security with efficient performance.

Mitigated Threats:

  • Server Breaches: Even if Google’s servers are compromised, attackers only access public keys, which cannot be used to authenticate.
  • Man-in-the-Middle (MITM) Attacks: The challenge-response mechanism, conducted over a secure TLS channel, prevents attackers from intercepting usable credentials.

Example:

  • If an attacker hacks Google’s servers, they obtain only the public key for a user’s Google Account. Without the private key, stored in the user’s iPhone secure enclave, the attacker cannot sign in.

Mechanism:

  • Passkeys are scoped to a specific relying party (RP) identifier, in this case, Google’s domain (e.g., accounts.google.com).
  • The WebAuthn protocol ensures that the authenticator (e.g., a phone or security key) only releases a signature if the domain requesting authentication matches the one registered during passkey creation.
  • This is enforced by the browser or operating system, which verifies the RP ID before allowing the authenticator to proceed.

Security Benefits:

  • Prevents Phishing: A fraudulent site (e.g., goog1e.com) cannot use a passkey created for Google’s legitimate domain, as the browser or authenticator will reject the request due to a domain mismatch.
  • No User Error Exploitation: Unlike passwords, which users might enter on fake login pages, passkeys cannot be tricked into working on unauthorized sites, eliminating human error as a vulnerability.

Mitigated Threats:

  • Phishing Attacks: Common phishing tactics, such as fake login pages or malicious emails, are ineffective because passkeys are domain-specific.
  • Spear-Phishing: Even targeted attacks that mimic Google’s login interface cannot bypass domain scoping.

Example:

  • A user receives an email with a link to a phishing site mimicking Google’s login page. When they attempt to sign in, their passkey (stored on their Android phone) refuses to authenticate because the domain doesn’t match accounts.google.com.

Mechanism:

  • The private key for a passkey is stored in a secure, hardware-backed environment on the user’s device, such as:
    • Secure Enclave (Apple devices): A dedicated chip for cryptographic operations on iPhones, iPads, and Macs.
    • Trusted Platform Module (TPM): Used on Android devices and Windows PCs to securely store keys.
    • Password Managers: Services like Google Password Manager or third-party providers (e.g., 1Password) store passkeys in encrypted vaults.
  • These environments isolate the private key from the device’s operating system and applications, ensuring it cannot be extracted by malware or unauthorized apps.
  • For hardware security keys (e.g., YubiKey, Google Titan), the private key is stored in a tamper-resistant chip.

Security Benefits:

  • Protection Against Malware: The private key is inaccessible to malicious software, even if the device is compromised.
  • Tamper Resistance: Secure enclaves and TPMs are designed to resist physical and software-based attacks, ensuring the key remains secure.
  • Isolation: The key is only accessible during authentication after user verification, reducing exposure.

Mitigated Threats:

  • Malware Extraction: Keyloggers or spyware cannot access the private key, as it’s stored in a hardware-protected environment.
  • Device Theft: Even if a device is stolen, the private key cannot be used without user verification (see below).

Example:

  • A user’s Windows PC is infected with malware that attempts to steal credentials. The passkey’s private key, stored in the TPM, remains inaccessible, preventing unauthorized use.

Mechanism:

  • Passkeys require user verification to access the private key, ensuring that only the authorized user can authenticate. Verification methods include:
    • Biometric Authentication: Fingerprint, face scan (e.g., Face ID on iPhones), or iris scan.
    • Device PIN or Passcode: A numeric or alphanumeric code set by the user.
    • Hardware Security Key PIN: For FIDO2-compliant keys, a PIN or biometric input (if supported).
  • Biometric data is processed locally in the device’s secure enclave or TPM and never sent to Google or stored on servers.
  • The authenticator enforces user verification before signing a challenge, ensuring the private key is only used by the account owner.

Security Benefits:

  • Prevents Unauthorized Access: Even if a device is stolen, the passkey cannot be used without the user’s biometric or PIN.
  • Privacy Protection: Biometric data remains on the device, reducing the risk of exposure in a breach.
  • Strong Authentication: Combines “something you have” (the device) with “something you are/know” (biometric or PIN), providing inherent multi-factor authentication (MFA).

Mitigated Threats:

  • Device Theft: A stolen phone or security key is useless without the user’s biometric or PIN.
  • Impersonation: Attackers cannot bypass user verification, even with physical access to the device.

Example:

  • If a thief steals a user’s iPhone with a passkey for their Google Account, they cannot sign in without the user’s Face ID or passcode, rendering the passkey unusable.

Mechanism:

  • Passkey authentication uses a challenge-response protocol to verify the user’s identity without transmitting sensitive data.
  • When signing in, Google’s server sends a challenge (a random nonce) to the device via the WebAuthn API.
  • The device signs the challenge with the private key, producing a digital signature, which is sent back to Google.
  • Google verifies the signature using the stored public key, ensuring the request came from the legitimate device.

Security Benefits:

  • Prevents Replay Attacks: The challenge is a one-time-use nonce, ensuring that intercepted signatures cannot be reused.
  • Secure Communication: The challenge-response process occurs over a TLS-encrypted channel, protecting against interception.
  • No Credential Exposure: The private key never leaves the device, and the signature is only valid for the specific challenge.

Mitigated Threats:

  • Replay Attacks: Attackers cannot reuse a captured signature, as each authentication requires a new challenge.
  • MITM Attacks: The secure TLS channel and domain-specific scoping prevent attackers from manipulating the authentication process.

Example:

  • An attacker intercepts a digital signature during a sign-in attempt. When they try to reuse it, Google rejects the signature because it doesn’t match the new challenge issued for the next login.

Mechanism:

  • Passkeys can be synced across devices using services like Google Password Manager (Android), iCloud Keychain (Apple), or third-party providers (e.g., 1Password, NordPass).
  • Synced passkeys are encrypted end-to-end, ensuring that only the user’s devices can access them.
  • For example, Google Password Manager encrypts passkeys with a key derived from the user’s Google Account credentials, and iCloud Keychain uses Apple’s end-to-end encryption framework.

Security Benefits:

  • Secure Backup: Synced passkeys prevent lockout if a device is lost, as they are available on other trusted devices.
  • Privacy Preservation: End-to-end encryption ensures that Google, Apple, or third-party providers cannot access the private key.
  • Cross-Platform Flexibility: Users can access passkeys on different ecosystems (e.g., Android to iOS) via third-party managers, maintaining security across devices.

Mitigated Threats:

  • Device Loss: Synced passkeys ensure users can still sign in from another device without relying on a single device.
  • Cloud Breaches: End-to-end encryption protects passkeys even if the syncing service’s servers are compromised.

Example:

  • A user loses their Android phone but can still sign into their Google Account from their iPad, where the passkey is synced via Google Password Manager’s encrypted storage.

Mechanism:

  • During passkey creation, the authenticator (e.g., a phone or security key) may provide an attestation certificate to Google, proving that the passkey was created on a legitimate, secure device.
  • Attestation verifies that the authenticator meets security standards (e.g., a secure enclave or TPM) and isn’t a compromised or emulated environment.
  • Google can use attestation to enforce policies, such as only allowing passkeys from trusted hardware.

Security Benefits:

  • Prevents Fraudulent Authenticators: Ensures passkeys are created on secure, manufacturer-verified hardware.
  • Policy Enforcement: Google can restrict passkey creation to devices meeting specific security criteria, enhancing trust.
  • High-Risk User Protection: Attestation is particularly valuable for Google’s Advanced Protection Program, ensuring only secure devices are used.

Mitigated Threats:

  • Compromised Devices: Prevents passkeys from being created on insecure or jailbroken devices.
  • Emulated Environments: Blocks attackers from creating passkeys in virtualized or malicious environments.

Example:

  • An attacker attempts to create a passkey on a compromised Android device lacking a TPM. Google rejects the passkey due to a missing or invalid attestation certificate.

Mechanism:

  • Passkeys support cross-device authentication, allowing a user to sign into one device (e.g., a laptop) using a passkey stored on another (e.g., a phone) via QR codes, Bluetooth, or USB (for hardware keys).
  • The process is secured by:
    • Encrypting communication between devices (e.g., via TLS or Bluetooth encryption).
    • Requiring user verification on the authenticating device (e.g., biometric or PIN).
    • Ensuring the passkey is only used for the intended domain.

Security Benefits:

  • Secure Remote Authentication: Cross-device sign-ins are protected by the same phishing-resistant and cryptographic mechanisms as local sign-ins.
  • Device Pairing: Devices can be “remembered” for future logins, reducing friction while maintaining security through user verification.
  • Flexibility Without Compromise: Users can authenticate from any trusted device without exposing the private key.

Mitigated Threats:

  • Unauthorized Cross-Device Access: Requires user verification on the authenticating device, preventing misuse.
  • Interception: Encrypted communication channels prevent attackers from capturing passkey data during cross-device authentication.

Example:

  • A user signs into Gmail on a public computer by scanning a QR code with their iPhone. The iPhone authenticates using Face ID, signs the challenge, and securely sends the signature to the computer, ensuring a phishing-resistant login.

Mechanism:

  • Passkeys are integrated into Google’s broader security framework, including:
    • Google Password Manager: Automatically creates and syncs passkeys on Android devices, secured by end-to-end encryption.
    • Advanced Protection Program (APP): Passkeys provide phishing-resistant authentication for high-risk users, complementing or replacing security keys.
    • Account Recovery: Google maintains fallback options (e.g., passwords, recovery email/phone) to ensure access if a passkey is unavailable.
  • Google’s servers enforce strict security policies, such as rejecting invalid signatures or requiring attestation for certain accounts.

Security Benefits:

  • Holistic Protection: Passkeys work alongside Google’s anomaly detection, IP-based checks, and other security measures to protect accounts.
  • High-Risk User Support: APP users benefit from passkeys’ phishing resistance, reducing the risk of targeted attacks.
  • Fallback Mechanisms: Recovery options ensure users aren’t locked out, maintaining security without compromising accessibility.

Mitigated Threats:

  • Targeted Attacks: High-risk users (e.g., activists) are protected against sophisticated phishing or social engineering.
  • Account Lockout: Fallbacks prevent permanent loss of access, balancing security with usability.

Example:

  • A journalist enrolled in APP uses a passkey on their YubiKey to sign into Google Drive, ensuring protection against targeted spear-phishing campaigns.

Mechanism:

  • Passkeys are not user-generated, eliminating the risk of weak or guessable credentials.
  • The private key is a large, cryptographically secure random number, making brute-force attacks computationally infeasible.
  • Since passkeys are unique to each account and service, credential stuffing (using stolen credentials from one site on another) is impossible.

Security Benefits:

  • No Weak Credentials: Unlike passwords, which may be simple (e.g., “123456”), passkeys are inherently strong.
  • No Reuse: Each passkey is specific to the Google Account and domain, preventing reuse across sites.
  • High Entropy: The cryptographic strength of the private key ensures resistance to guessing or cracking attempts.

Mitigated Threats:

  • Brute-Force Attacks: The complexity of private keys makes them immune to brute-force attempts.
  • Credential Stuffing: Passkeys cannot be reused, rendering stolen credentials from other sites useless.

Example:

  • An attacker tries to use a password stolen from a breached website to access a user’s Google Account. The passkey, unique to Google, renders the stolen password irrelevant.

Potential Limitations and Mitigations

While passkeys are highly secure, there are edge cases to consider, along with Google’s mitigations:

  • Device Loss:
    • Challenge: Losing a device with a passkey could prevent access.
    • Mitigation: Synced passkeys (via Google Password Manager or iCloud Keychain) and fallback options (passwords, recovery email/phone) ensure continued access.
  • Compromised Device Security:
    • Challenge: If a device’s secure enclave or TPM is bypassed (extremely rare), the private key could be at risk.
    • Mitigation: User verification (biometric/PIN) and attestation ensure only trusted devices are used.
  • Adoption Barriers:
    • Challenge: Older devices or browsers may not support passkeys.
    • Mitigation: Google supports passwords and 2FA as fallbacks and ensures passkeys work on modern platforms (Android 9+, iOS 16+, Chrome 109+).

To set up and use passkeys for your Google Account, your device and software must meet the following requirements:

  • Mobile Devices:
    • Android: Android 9.0 or later with a screen lock enabled.
    • iOS: iOS 16 or later (iOS 17 for Microsoft Authenticator passkeys). iCloud Keychain must be enabled for syncing across Apple devices.
  • Computers:
    • Windows: Windows 10 or later.
    • macOS: macOS Ventura or later.
    • ChromeOS: Version 109 or later.
  • Browsers:
    • Google Chrome: Version 109 or later.
    • Apple Safari: Version 16 or later.
    • Microsoft Edge: Version 109 or later.
  • Hardware Security Keys:
    • Must support the FIDO2 protocol (e.g., Google’s Titan Security Key or YubiKey with PIN or biometric support). Older keys may not work for passkey creation.
  • Additional Requirements:
    • A screen lock (PIN, pattern, or biometric) must be enabled on the device.
    • For cross-device sign-ins (e.g., using a phone to sign into a computer), Bluetooth may be required.
    • For Google Workspace accounts, administrators must enable passwordless authentication.

Passkeys are designed for flexibility across devices:

  • Synced Passkeys:
    • On Android, Google Password Manager syncs passkeys across devices signed into the same Google Account.
    • On Apple devices, iCloud Keychain syncs passkeys across iPhones, iPads, and Macs.
    • Third-party password managers (e.g., 1Password, NordPass) support passkeys for cross-platform use (e.g., Android to iOS).
  • Cross-Device Authentication:
    • Users can sign into one device (e.g., a laptop) using a passkey stored on another (e.g., a phone) via QR codes or Bluetooth.
    • For example, scanning a QR code on a laptop with an iPhone triggers the iPhone to authenticate the user and sign the challenge.
  • Hardware Security Keys:
    • Passkeys can be stored on FIDO2-compliant security keys (e.g., YubiKey, Google Titan). These keys can authenticate across devices via USB, NFC, or Bluetooth.

Google integrates passkeys into its ecosystem as follows:

  • Google Password Manager: Automatically creates and manages passkeys on Android devices (version 9.0+) and syncs them across Chrome and other signed-in devices.
  • Default Sign-In Option: Since October 2023, passkeys are the default sign-in method for personal Google Accounts when supported devices are used.
  • Fallback Options: Passwords and 2FA (e.g., SMS codes, authenticator apps) remain available if a passkey is inaccessible.
  • Google Workspace: For enterprise accounts, administrators must enable passwordless authentication. Passkeys may serve as a second factor unless explicitly configured otherwise.
  • Advanced Protection Program: Passkeys are supported for high-risk users, providing phishing-resistant authentication alongside security keys.

  1. Device Dependency:
    • Passkeys are tied to specific devices. If you lose access to a device, you cannot use its passkey. You’ll need to use an alternative login method (e.g., password) or set up a new passkey on another device.
    • For Apple devices, enabling iCloud Keychain ensures passkeys sync across devices, reducing this risk.
  2. Google Workspace Restrictions:
    • For Google Workspace accounts (e.g., through an employer or school), passkeys may only be used as a secondary authentication factor unless the administrator enables passwordless sign-in.
  3. Hardware Security Key Issues:
    • Older security keys or those without FIDO2 support may not work for passkey creation. If a key is already enrolled as a 2FA device, you may need to unenroll it before creating a passkey.
  4. Potential Technical Issues:
    • Some users report issues with passkeys not working (e.g., greyed-out buttons or errors). Troubleshooting steps include updating the device’s OS and browser, clearing Chrome’s cache, or restarting the device.reddit.com
    • If a passkey is deleted accidentally, you may need to re-add your Google Account to the device or create a new passkey.
  5. Not Fully Passwordless Yet:
    • While passkeys aim for a passwordless future, passwords and 2FA remain available as fallback options. Google may limit password use over time as passkey adoption grows.

Passkeys offer a range of benefits that make them a superior alternative to traditional passwords and even some forms of two-factor authentication (2FA). These benefits span security, usability, privacy, and ecosystem compatibility, making them a cornerstone of Google’s push for a passwordless future.

One of the most significant advantages of passkeys is their resistance to phishing attacks, a common threat that compromises millions of accounts annually.

  • How It Works:
    • Passkeys are scoped to a specific domain (e.g., accounts.google.com). This means the private key stored on the user’s device will only work for Google’s legitimate domain and cannot be used on a fraudulent site mimicking Google’s login page.
    • Unlike passwords, which users might inadvertently enter on phishing sites, passkeys rely on the WebAuthn protocol, which ensures the browser or authenticator verifies the domain before signing a challenge. This eliminates the risk of credential theft via phishing.
  • Security Impact:
    • Phishing attacks often exploit human error (e.g., mistyping a URL or clicking a malicious link). Passkeys mitigate this by ensuring credentials are unusable outside their intended context.
    • According to the FIDO Alliance, phishing-resistant authentication methods like passkeys can reduce account compromise rates significantly, as they eliminate the shared-secret model of passwords.
  • Example:
    • If a user receives a phishing email directing them to a fake Google login page (e.g., goog1e.com), their passkey will not work because the domain doesn’t match the one registered with the public key. The browser or device will reject the authentication attempt, protecting the account.

Traditional passwords are shared secrets, meaning both the user and the server (Google) store a version of the credential, making them vulnerable to server-side breaches or interception.

  • How Passkeys Address This:
    • Passkeys use public-key cryptography, where the private key remains on the user’s device (in a secure enclave or password manager) and is never shared with Google.
    • The public key, stored on Google’s servers, is useless without the private key, ensuring that even a server breach cannot compromise the credential.
    • During authentication, the device signs a challenge with the private key, and Google verifies it with the public key, without transmitting sensitive data.
  • Security Impact:
    • Eliminates risks associated with password databases being stolen, as seen in high-profile breaches (e.g., LinkedIn 2012, Yahoo 2013).
    • Reduces the attack surface, as attackers cannot intercept or guess passkeys like they can with passwords.
    • Provides inherent multi-factor authentication (MFA), combining “something you have” (the device) with “something you are/know” (biometric or PIN), without requiring separate 2FA steps in most cases.
  • Example:
    • If Google’s servers were compromised, attackers would only access public keys, which cannot be used to authenticate without the private key securely stored on the user’s device.

Password reuse and weak passwords are leading causes of account compromises, with studies indicating that over 50% of users reuse passwords across multiple sites.

  • How Passkeys Mitigate This:
    • Passkeys eliminate the need for passwords entirely, rendering reuse irrelevant.
    • Each passkey is unique to the Google Account and device, automatically generated with strong cryptographic properties (e.g., using ECDSA with the P-256 curve).
    • Users don’t need to create or memorize passwords, removing the temptation to use weak or repeated credentials.
  • Security Impact:
    • Prevents credential stuffing attacks, where attackers use stolen passwords from one site to access others.
    • Ensures all credentials are cryptographically strong, unlike user-generated passwords that may be predictable (e.g., “password123”).
  • Example:
    • A user who previously used the same password for Google and another compromised site is no longer at risk, as their Google passkey is unique and cannot be reused elsewhere.

Passkeys inherently combine multiple authentication factors, streamlining the login process while maintaining or exceeding the security of traditional 2FA.

  • How It Works:
    • Passkeys require possession of the device (e.g., phone, computer, or security key) and user verification (biometric or PIN).
    • This combines “something you have” and “something you are/know,” meeting MFA requirements without additional steps like SMS codes or authenticator apps.
    • For Google Accounts, enabling a passkey can replace the need for a second authentication factor in many cases, as the passkey itself is sufficiently secure.
  • Security Impact:
    • Reduces vulnerabilities associated with weaker 2FA methods, such as SMS-based codes, which can be intercepted via SIM-swapping attacks.
    • Provides a seamless MFA experience, increasing user adoption compared to complex 2FA setups.
    • Supports Google’s Advanced Protection Program, offering phishing-resistant authentication for high-risk users (e.g., journalists, executives).
  • Example:
    • Instead of entering a password and waiting for an SMS code, a user scans their fingerprint on their phone to sign into Gmail, achieving MFA in a single step.

Keyloggers and man-in-the-middle (MITM) attacks can capture passwords during entry or transmission, but passkeys are immune to these threats.

  • How Passkeys Address This:
    • Since passkeys don’t involve typing a credential, keyloggers cannot capture them.
    • The private key is never transmitted, and the authentication process uses a challenge-response mechanism over a secure channel (e.g., TLS in the browser), thwarting MITM attacks.
    • Biometric data or PINs used for user verification are processed locally on the device, not sent over the network.
  • Security Impact:
    • Eliminates risks from malware that records keystrokes or intercepts network traffic.
    • Ensures authentication remains secure even on compromised networks (e.g., public Wi-Fi).
  • Example:
    • A user on a compromised laptop with a keylogger can still safely sign into their Google Account using a passkey stored on their phone, as no password is entered or transmitted.

Passkeys significantly enhance the login experience, making security more accessible and less cumbersome.

  • How It Works:
    • Users authenticate with a biometric (fingerprint, face scan) or PIN, which is faster and more intuitive than typing a password.
    • Google reports that passkey sign-ins are up to 40% faster than password-based logins.
    • Passkeys sync across devices via Google Password Manager (Android), iCloud Keychain (Apple), or third-party providers (e.g., 1Password), ensuring accessibility on multiple devices.
    • Cross-device authentication (e.g., using a phone to sign into a laptop via QR code) is seamless and eliminates the need to enter credentials manually.
  • User Benefits:
    • Eliminates the need to memorize complex passwords or manage password resets.
    • Reduces friction for users who struggle with 2FA setup or frequent password changes.
    • Encourages adoption of secure authentication, as passkeys are easier to use than traditional MFA methods.
  • Example:
    • A user signs into YouTube on a new laptop by scanning a QR code with their phone and using Face ID, completing the process in seconds without typing anything.

Passkeys prioritize user privacy by minimizing the data shared with Google and keeping sensitive information on the device.

  • How It Works:
    • Biometric data (e.g., fingerprints, facial scans) is processed and stored locally in the device’s secure enclave or TPM, never sent to Google.
    • The private key remains on the device, and only the public key is shared with Google, which cannot be used to identify the user or their biometric data.
    • Authentication occurs without transmitting sensitive user information over the network.
  • Privacy Impact:
    • Reduces the risk of biometric data exposure in server breaches.
    • Aligns with privacy-focused regulations (e.g., GDPR, CCPA) by minimizing data collection.
    • Builds user trust by ensuring Google cannot access or store biometric information.
  • Example:
    • When a user authenticates with a fingerprint, the biometric data is processed in the iPhone’s secure enclave and never leaves the device, ensuring Google has no access to it.

Passkeys are built on open standards, ensuring broad compatibility and future-proofing Google Account security.

  • How It Works:
    • Passkeys adhere to FIDO2 and WebAuthn standards, supported by major platforms (Android, iOS, Windows, macOS) and browsers (Chrome, Safari, Edge).
    • Google Password Manager, iCloud Keychain, and third-party providers (e.g., NordPass, 1Password) enable passkey syncing across ecosystems.
    • The FIDO Alliance, backed by Google, Apple, Microsoft, and others, promotes passkeys across industries, with adoption by services like PayPal, DocuSign, and Shopify.
  • Security and Usability Impact:
    • Users can use passkeys across devices and platforms, reducing dependency on a single ecosystem.
    • Widespread adoption ensures passkeys remain relevant as more services transition to passwordless authentication.
    • Provides a consistent authentication experience across Google services and other platforms.
  • Example:
    • A user creates a passkey on their Android phone for Google and uses it to sign into PayPal on a Windows PC, leveraging the same credential stored in Google Password Manager.

For organizations using Google Workspace, passkeys offer operational efficiencies that indirectly benefit individual account security.

  • How It Works:
    • Passkeys reduce the need for password reset support, as users rely on biometrics or PINs, which are less likely to be forgotten.
    • Eliminates costs associated with SMS-based 2FA, which can be expensive for large organizations.
    • Simplifies account recovery by leveraging device-based authentication and synced passkeys.
  • Security Impact:
    • Fewer support requests free up IT resources to focus on proactive security measures.
    • Encourages adoption of secure authentication across organizations, reducing the risk of employee-related breaches.
  • Example:
    • A company using Google Workspace enables passkeys, reducing helpdesk tickets for password resets by 30%, allowing IT to prioritize security training.

Passkeys are integrated into Google’s Advanced Protection Program (APP), designed for users at high risk of targeted attacks (e.g., journalists, activists, executives).

  • How It Works:
    • Passkeys provide phishing-resistant authentication, meeting APP’s stringent security requirements.
    • They can be used alongside or as an alternative to hardware security keys, offering flexibility for high-risk users.
    • Synced passkeys ensure accessibility without compromising security.
  • Security Impact:
    • Protects against sophisticated attacks, such as spear-phishing or state-sponsored hacking.
    • Simplifies APP adoption by offering a user-friendly alternative to security keys, which may require additional hardware.
  • Example:
    • A journalist enrolled in APP uses a passkey on their iPhone to securely access Google Drive, ensuring protection against targeted phishing attempts.

Passkeys position Google Accounts for a passwordless future, aligning with industry trends and user expectations.

As more services adopt passkeys, a user seamlessly signs into Google, PayPal, and Shopify with the same passkey stored in their password manager, streamlining their online experience.

How It Works:

  • Google has made passkeys the default sign-in method for personal accounts since October 2023, signaling a shift away from passwords.
  • The FIDO Alliance reports that 53% of users have enabled passkeys on at least one account, with 22% using them wherever possible, indicating growing adoption.
  • Passkeys are scalable, supporting new devices, browsers, and services as adoption expands.

Security and Usability Impact:

  • Prepares users for a world where passwords are obsolete, reducing reliance on outdated and vulnerable authentication methods.
  • Encourages other services to adopt passkeys, creating a more secure digital ecosystem.

Example:

  • As more services adopt passkeys, a user seamlessly signs into Google, PayPal, and Shopify with the same passkey stored in their password manager, streamlining their online experience.

While passkeys offer significant benefits, there are challenges to consider, which Google mitigates effectively:

  • Device Dependency:
    • Challenge: Losing a device with a passkey can prevent access.
    • Mitigation: Synced passkeys (via Google Password Manager or iCloud Keychain) ensure availability across devices. Fallback options like passwords or recovery methods (email, phone) provide access if a device is lost.
  • Initial Setup Complexity:
    • Challenge: Users may find passkey setup unfamiliar compared to passwords.
    • Mitigation: Google’s intuitive setup process at g.co/passkeys and automatic passkey creation on Android simplify adoption.
  • Limited Support in Some Scenarios:
    • Challenge: Older devices or browsers may not support passkeys.
    • Mitigation: Google maintains password and 2FA support as fallbacks, and passkeys are compatible with modern platforms (Android 9+, iOS 16+, Chrome 109+).

Passkeys are primarily used to authenticate users across Google’s ecosystem of services, such as Gmail, YouTube, Google Drive, Google Photos, and Google Calendar, replacing passwords with a faster and more secure method.

How It Works:

  • When a user accesses a Google service on a supported device or browser, Google Password Manager prompts the use of a passkey by default.
  • The user authenticates with a biometric (e.g., fingerprint, face scan) or PIN, and the device signs a challenge from Google’s server using the private key.
  • Google verifies the signature with the public key, granting access without requiring a password.

Example:

  • Scenario: Priya wants to check her emails on her Android phone (Pixel 8, Android 14).
  • Process:
    • Priya opens the Gmail app, which detects a passkey stored in Google Password Manager (created automatically during account setup).
    • The app prompts her to scan her fingerprint.
    • The phone’s TPM retrieves the private key, signs Google’s challenge, and sends the signature to the server.
    • Google verifies the signature, and Priya accesses Gmail in seconds.
  • Benefits:
    • Security: Phishing-resistant due to domain scoping; biometric verification ensures only Priya can authenticate.
    • Convenience: Faster than typing a password; synced passkey requires no setup on the device.

Applications:

  • Accessing Gmail for email management.
  • Signing into YouTube to watch videos or manage subscriptions.
  • Using Google Drive to store or share files.
  • Checking Google Calendar for scheduling.

Passkeys enable users to sign into Google services on one device using a passkey stored on another, such as using a phone to authenticate on a laptop or public computer. This is particularly useful for devices without stored passkeys or in shared environments.

How It Works:

  • The user initiates a sign-in on a device (e.g., a laptop), and Google displays a QR code or prompts for a nearby device via Bluetooth.
  • The authenticating device (e.g., a phone) uses Google Password Manager to retrieve the passkey, verifies the user (via biometric or PIN), and signs the challenge.
  • The signature is securely transmitted to the initiating device, which completes the login.

Example:

  • Scenario: Jamal signs into Google Photos on a friend’s Windows laptop using Chrome.
  • Process:
    • Jamal navigates to photos.google.com and clicks “Sign in.”
    • Chrome prompts the default passkey option, displaying a QR code since no passkey is stored on the laptop.
    • Jamal scans the QR code with his Android phone, where Google Password Manager has a synced passkey.
    • He authenticates with his face scan, and the phone signs the challenge, sending the signature to the laptop via WebAuthn.
    • Google verifies the signature, granting access to Google Photos.
  • Benefits:
    • Security: No credentials are stored on the shared laptop; phishing resistance ensures the passkey only works for Google’s domain.
    • Convenience: QR code scanning is quick and doesn’t require typing.

Applications:

  • Signing into Google services on public or work computers without storing credentials.
  • Authenticating on a new device (e.g., a tablet) using a trusted phone.
  • Accessing Google services on smart TVs or gaming consoles via a phone-based passkey.

Passkeys can be used to authenticate Google Accounts for single sign-on (SSO) with third-party services that support FIDO2 or Google SSO, such as PayPal, DocuSign, or Shopify, streamlining access across platforms.

How It Works:

  • The third-party service redirects the user to Google’s authentication page, which prompts the default passkey option.
  • Google Password Manager retrieves the passkey, the user authenticates (e.g., with a fingerprint), and Google verifies the signature.
  • Google issues an SSO token to the third-party service, granting access.

Example:

  • Scenario: Maria signs into PayPal using her Google Account on her Android tablet.
  • Process:
    • Maria visits paypal.com on Chrome and selects “Sign in with Google.”
    • Google’s authentication page prompts her to use a passkey (default method).
    • Google Password Manager retrieves the passkey from the tablet’s TPM, and Maria authenticates with her fingerprint.
    • The tablet signs the challenge, Google verifies it, and issues an SSO token to PayPal, granting Maria access.
  • Benefits:
    • Security: Phishing-resistant authentication ensures the passkey only works for Google’s SSO process.
    • Convenience: One passkey authenticates multiple services, reducing credential management.

Applications:

  • Signing into e-commerce platforms like Shopify for shopping.
  • Accessing document signing services like DocuSign for contracts.
  • Authenticating with collaboration tools (e.g., Slack) that support Google SSO.

Passkeys are integrated into Google’s Advanced Protection Program (APP), designed for high-risk users like journalists, activists, or executives, providing phishing-resistant authentication to protect against targeted attacks.

How It Works:

  • Users enrolled in APP can use passkeys as a primary authentication method, replacing or complementing hardware security keys.
  • The passkey, stored in Google Password Manager or a FIDO2-compliant security key, requires user verification and is verified by Google’s strict security policies.

Example:

  • Scenario: Emma, a journalist enrolled in APP, accesses Google Workspace on her Android tablet.
  • Process:
    • Emma opens Gmail on her tablet, which prompts the default passkey option.
    • Google Password Manager retrieves the passkey, and Emma authenticates with her face scan.
    • The tablet’s TPM signs the challenge, and Google verifies it, granting access under APP’s stringent requirements.
  • Benefits:
    • Security: Phishing-resistant passkeys protect against targeted spear-phishing attacks.
    • Convenience: Passkeys simplify APP authentication compared to carrying physical security keys.

Applications:

  • Securing Gmail for sensitive communications.
  • Protecting Google Drive for storing confidential documents.
  • Authenticating Google Workspace for high-risk organizational users.

Passkeys, synced via Google Password Manager, facilitate account access and recovery when a device is lost, stolen, or replaced, ensuring users aren’t locked out of their Google Accounts.

How It Works:

  • Synced passkeys are available on all devices signed into the same Google Account.
  • If a device is lost, users can access their account on another device with the synced passkey or use fallback methods (password, recovery email/phone) to sign in and create a new passkey.

Example:

  • Scenario: Alex loses his Android phone and needs to access Google Calendar on a new phone.
  • Process:
    • Alex’s passkey was synced via Google Password Manager from his lost phone.
    • He buys a new Android phone and signs into his Google Account using his password and recovery email (as a fallback).
    • Google Password Manager syncs the passkey to the new phone’s TPM.
    • Alex opens Google Calendar, authenticates with his fingerprint, and accesses his account using the passkey.
  • Benefits:
    • Security: End-to-end encryption ensures synced passkeys remain secure.
    • Convenience: Synced passkeys prevent the need to recreate credentials on new devices.

Applications:

  • Restoring access to Google services after device loss.
  • Setting up new devices without manual passkey creation.
  • Maintaining access during travel or device upgrades.

Passkeys allow secure sign-ins on shared or public devices (e.g., library PCs, work computers) without leaving credentials behind, leveraging cross-device authentication.

How It Works:

  • The user initiates a sign-in on the shared device, which prompts a QR code or Bluetooth-based authentication.
  • A trusted device (e.g., a phone) with a passkey in Google Password Manager authenticates the user and completes the login.

Example:

  • Scenario: Sarah uses a library computer to access Google Docs.
  • Process:
    • Sarah opens Chrome on the library PC and navigates to docs.google.com.
    • Chrome prompts the default passkey option, displaying a QR code.
    • Sarah scans the QR code with her Android phone, where Google Password Manager stores her passkey.
    • She authenticates with her PIN, and the phone signs the challenge, sending the signature to the PC.
    • Google verifies the signature, granting access to Google Docs.
  • Benefits:
    • Security: No credentials are stored on the public device; phishing resistance ensures safety.
    • Convenience: QR code authentication is quick and secure.

Applications:

  • Accessing Google services on work or school computers.
  • Signing into Google on public kiosks or shared tablets.
  • Temporary use of borrowed devices.

For users with personal Google Workspace accounts (e.g., for small businesses or freelancers), passkeys simplify secure access to productivity tools like Gmail, Google Drive, and Google Meet.

How It Works:

  • Passkeys are used as the default authentication method for personal Google Workspace accounts, unless restricted by an administrator.
  • Google Password Manager manages passkeys, enabling seamless access across devices.

Example:

  • Scenario: Maria, a freelancer, uses Google Workspace to manage her business email on her Chromebook.
  • Process:
    • Maria opens Gmail on her Chromebook, which prompts the default passkey option.
    • Google Password Manager retrieves the passkey, and Maria authenticates with her Chromebook’s PIN.
    • The Chromebook signs the challenge, and Google verifies it, granting access to her business email.
  • Benefits:
    • Security: Phishing-resistant authentication protects sensitive business communications.
    • Convenience: Synced passkeys streamline access across her devices.

Applications:

  • Managing business emails via Gmail.
  • Storing client files in Google Drive.
  • Joining Google Meet calls securely.

Google Password Manager is a built-in service for Android devices (version 9.0 and later) and the Chrome browser, designed to store passwords, passkeys, and other credentials securely. With passkey support, introduced by Google in 2022 and made the default sign-in method for personal Google Accounts in October 2023, the Password Manager automatically generates, stores, and syncs passkeys across devices signed into the same Google Account. This integration leverages end-to-end encryption to protect passkeys and enables seamless authentication across Google services (e.g., Gmail, YouTube, Google Drive) and third-party services that support FIDO2/WebAuthn standards.

Key Features of the Integration:

  • Automatic Passkey Creation: On Android devices, Google Password Manager can automatically create passkeys for Google Accounts when the user enables the feature or signs in.
  • End-to-End Encryption: Passkeys are encrypted with a key derived from the user’s Google Account credentials, ensuring that only authorized devices can access them.
  • Cross-Device Syncing: Passkeys are synced across Android devices, Chrome browsers, and other platforms signed into the same Google Account, making them accessible wherever the user is signed in.
  • Cross-Platform Support: While primarily designed for Google’s ecosystem, passkeys stored in Google Password Manager can be used on non-Google platforms (e.g., Windows, iOS) via Chrome or third-party password managers that support passkeys.
  • User Verification: Passkeys require biometric authentication (e.g., fingerprint, face scan) or a device PIN, processed locally in the device’s secure enclave or Trusted Platform Module (TPM).
  • Fallback Options: Google Password Manager supports passwords and other authentication methods as backups if passkeys are unavailable.

Security Mechanisms:

  • Passkeys use public-key cryptography, with the private key stored in the device’s secure hardware and the public key registered with Google.
  • Phishing resistance is ensured by scoping passkeys to specific domains (e.g., accounts.google.com).
  • End-to-end encryption protects synced passkeys, preventing Google or third parties from accessing the private key.

Below, I’ll provide detailed examples of how passkeys integrated with Google Password Manager are used in various scenarios, highlighting their security, convenience, and cross-platform functionality.

These examples illustrate practical use cases for passkeys managed by Google Password Manager, covering different devices, contexts, and authentication scenarios. Each example emphasizes how the integration enhances security and user experience.

Example 1: Signing into Gmail on an Android Phone

Scenario:

  • Sarah, a Google Account user, wants to sign into Gmail on her new Android phone (running Android 12). She has previously enabled passkeys via Google Password Manager on her old Android device, and the passkey is synced to her Google Account.

Steps:

  1. Setup on Old Device:
    • On her old Android phone, Sarah visited g.co/passkeys or accessed Google Account settings under “Security” > “Passkeys and security keys.”
    • Google Password Manager automatically created a passkey for her Google Account when she signed in, storing the private key in the phone’s TPM and syncing it to her Google Account with end-to-end encryption.
  2. Sign-In on New Phone:
    • Sarah signs into her Google Account on her new phone, which syncs the passkey via Google Password Manager.
    • She opens the Gmail app, which prompts her to use a passkey.
    • The phone displays a biometric prompt, and Sarah scans her fingerprint.
    • The TPM retrieves the private key, signs a challenge from Google’s server, and sends the signature via the Gmail app.
    • Google verifies the signature with the public key, granting Sarah access to Gmail.
  3. Outcome:
    • Sarah signs in without entering a password or 2FA code, completing the process in seconds.
    • The passkey, synced via Google Password Manager, ensures seamless access on her new device without additional setup.

Security Benefits:

  • Phishing resistance: The passkey only works for accounts.google.com, protecting against fake login pages.
  • End-to-end encryption: The synced passkey is inaccessible to Google or attackers, even if servers are compromised.
  • Biometric verification: Only Sarah’s fingerprint can unlock the passkey, preventing unauthorized access.

User Experience:

  • Fast and intuitive: Fingerprint authentication is quicker than typing a password.
  • Seamless syncing: No need to re-create the passkey on the new phone.

Example 2: Cross-Device Authentication on a Windows Laptop

Scenario:

  • John, a student, wants to sign into YouTube on his Windows laptop using Chrome. His passkey is stored on his Android phone via Google Password Manager, and he uses cross-device authentication to log in.

Steps:

  1. Passkey Creation:
    • John previously enabled a passkey on his Android phone (running Android 14) through Google Password Manager. The passkey is synced to his Google Account and stored in the phone’s TPM.
  2. Sign-In on Laptop:
    • On his laptop, John opens Chrome (version 109 or later) and navigates to YouTube, clicking “Sign in.”
    • The browser prompts him to use a passkey and displays a QR code.
    • John opens the Google app or a QR code scanner on his Android phone, scans the QR code, and is prompted to authenticate with his face scan (using the phone’s biometric sensor).
    • The phone signs Google’s challenge with the private key, encrypts the signature, and sends it to the laptop via a secure WebAuthn channel.
    • Chrome forwards the signature to Google’s servers, which verify it with the public key, granting access to YouTube.
  3. Outcome:
    • John signs into YouTube without entering a password, using his phone as the authenticator.
    • Google Password Manager’s syncing ensures the passkey is available without needing to create one on the laptop.

Security Benefits:

  • Phishing resistance: The passkey only authenticates for YouTube’s legitimate domain.
  • Secure cross-device communication: The QR code and WebAuthn channel prevent interception.
  • Device-bound security: The private key remains on the phone, inaccessible to the laptop or attackers.

User Experience:

  • Convenient: Scanning a QR code and using face scan is faster than typing credentials.
  • Flexible: John can use his phone to sign in on any device running a supported browser.

Example 3: Signing into a Third-Party Service with Google Password Manager

Scenario:

  • Maria, a small business owner, uses her Google Account passkey to sign into a third-party service like PayPal, which supports FIDO2 passkeys. Her passkey is managed by Google Password Manager on her Android tablet.

Steps:

  1. Passkey Creation:
    • Maria enabled a passkey for her Google Account on her Android tablet, stored in Google Password Manager and synced to her Google Account.
    • PayPal supports passkey authentication and allows users to sign in with their Google Account credentials.
  2. Sign-In Process:
    • Maria visits PayPal’s website on her tablet’s Chrome browser and selects “Sign in with Google.”
    • PayPal redirects to Google’s authentication service, which prompts Maria to use her passkey.
    • Google Password Manager retrieves the passkey from the tablet’s TPM, and Maria authenticates with her fingerprint.
    • The tablet signs a challenge for accounts.google.com, and Google verifies it, completing the single sign-on (SSO) process.
    • PayPal grants Maria access based on Google’s authentication.
  3. Outcome:
    • Maria signs into PayPal using her Google Account passkey, managed by Google Password Manager, without needing a separate PayPal password.
    • The process is secure and streamlined, leveraging Google’s infrastructure.

Security Benefits:

  • Phishing resistance: The passkey ensures authentication only for Google’s domain, preventing misuse on fake SSO pages.
  • Single sign-on security: Google’s verification ensures PayPal receives a trusted authentication token.
  • End-to-end encryption: The passkey remains secure within Google Password Manager.

User Experience:

  • Unified experience: Maria uses one passkey for multiple services, reducing credential management.
  • Fast authentication: Fingerprint sign-in is quicker than entering multiple passwords.

Example 4: Using a Passkey on a Shared Device

Scenario:

  • Alex, a freelance designer, uses a shared family computer to access Google Drive. His passkey is stored on his Android phone via Google Password Manager, ensuring secure access without storing credentials on the shared device.

Steps:

  1. Passkey Setup:
    • Alex enabled a passkey on his Android phone, stored in Google Password Manager and synced to his Google Account.
  2. Sign-In on Shared Computer:
    • On the family computer, Alex opens Chrome and navigates to Google Drive, selecting “Sign in with a passkey.”
    • Chrome displays a QR code, which Alex scans with his phone.
    • The phone prompts Alex to authenticate with his PIN, as the computer is not a trusted device.
    • Google Password Manager retrieves the private key, signs the challenge, and sends the signature to the computer via WebAuthn.
    • Google verifies the signature, granting Alex access to Google Drive.
  3. Outcome:
    • Alex securely signs in without leaving credentials on the shared computer.
    • Google Password Manager’s syncing ensures the passkey is available without needing to set it up on the computer.

Security Benefits:

  • No credential residue: The shared computer stores no sensitive data, reducing risk on untrusted devices.
  • User verification: Alex’s PIN ensures only he can use the passkey.
  • Phishing resistance: The passkey only works for Google’s domain, protecting against malicious sites.

User Experience:

  • Secure and convenient: Alex avoids entering passwords on a shared device, reducing exposure.
  • Flexible: The phone-based passkey works on any device with a supported browser.

Example 5: Recovering Access After Losing a Device

Scenario:

  • Priya loses her Android phone, where her Google Account passkey was stored. She uses Google Password Manager’s synced passkey on her new Android device to regain access.

Steps:

  1. Passkey Syncing:
    • Priya’s original passkey was created on her lost phone and synced to her Google Account via Google Password Manager with end-to-end encryption.
  2. Access on New Device:
    • Priya gets a new Android phone and signs into her Google Account using a fallback method (e.g., password and recovery email).
    • Google Password Manager syncs the passkey to the new phone’s TPM.
    • Priya opens the Google app, selects the passkey option, and authenticates with her fingerprint.
    • The new phone signs a challenge, and Google verifies it, granting access to her account.
  3. Outcome:
    • Priya regains access to her Google Account without needing to create a new passkey.
    • Google Password Manager’s syncing ensures continuity despite device loss.

Security Benefits:

  • End-to-end encryption: The synced passkey is inaccessible to Google or attackers.
  • Fallback options: Passwords and recovery methods prevent lockout.
  • Secure storage: The new phone’s TPM protects the passkey.

User Experience:

  • Seamless recovery: Priya resumes passkey use without reconfiguring authentication.
  • User-friendly: Fingerprint authentication restores access quickly.

When passkeys became the default sign-in method for personal Google Accounts, Google began prompting users to create or use passkeys automatically during sign-in or account setup on compatible devices (e.g., Android 9+, iOS 16+, Chrome 109+). Passkeys are managed by Google Password Manager, which stores and syncs them across devices signed into the same Google Account, using end-to-end encryption for security. If a passkey is unavailable (e.g., on an unsupported device), users can fall back to passwords or other authentication methods like two-factor authentication (2FA).

Key Aspects of the Default Implementation:

  • Automatic Prompting: When signing into a Google service (e.g., Gmail, YouTube, Google Drive), users are prompted to use a passkey if one exists or create one if supported by their device.
  • Device Compatibility: Passkeys work on Android (9.0+), iOS (16+), Windows (10+), macOS (Ventura+), and ChromeOS (109+), with browsers like Chrome, Safari, and Edge (109+).
  • Cross-Device Authentication: Users can sign in on one device (e.g., a laptop) using a passkey stored on another (e.g., a phone) via QR codes or Bluetooth.
  • Security Features: Passkeys are phishing-resistant, tied to Google’s domain (accounts.google.com), and require user verification (biometric or PIN) stored in secure hardware (e.g., secure enclave, TPM).
  • Fallback Options: Passwords, 2FA (e.g., SMS codes, authenticator apps), and recovery methods (email, phone) remain available for unsupported devices or scenarios.

Why Passkeys Are Default:

  • Google’s data suggests passkeys are up to 40% faster than password-based logins and significantly reduce phishing risks, as they eliminate shared secrets and are domain-specific.
  • The FIDO Alliance reports 53% of users have enabled passkeys on at least one account, reflecting growing adoption, which Google leverages to push passwordless authentication.

These examples demonstrate how passkeys function as the default authentication method in real-world scenarios, highlighting their integration with Google Password Manager, cross-device functionality, and fallback mechanisms.

Example 1: Signing into Gmail on a New Android Phone

Scenario:

  • Priya, a Google Account user, buys a new Android phone (running Android 14) and wants to sign into Gmail. Since passkeys are the default, Google prompts her to use or create a passkey.

Steps:

  1. Initial Setup:
    • Priya signs into her Google Account on the new phone during device setup, using her password as a fallback (since no passkey exists yet).
    • Google Password Manager detects the compatible device and automatically creates a passkey, storing the private key in the phone’s Trusted Platform Module (TPM) and syncing it to her Google Account with end-to-end encryption.
  2. Sign-In Process:
    • Priya opens the Gmail app, which recognizes the passkey as the default sign-in method.
    • The app prompts her to authenticate with her fingerprint (the phone’s biometric sensor).
    • The TPM retrieves the private key, signs a challenge from Google’s server (for accounts.google.com), and sends the signature via the Gmail app.
    • Google verifies the signature with the stored public key, granting Priya access to Gmail.
  3. Outcome:
    • Priya signs in without entering a password, as the passkey is automatically used as the default method.
    • The passkey is synced via Google Password Manager, making it available for future sign-ins on other devices.

Security Benefits:

  • Phishing Resistance: The passkey only works for Google’s domain, preventing use on fake login pages.
  • Secure Storage: The private key in the TPM is inaccessible to malware or attackers.
  • User Verification: Priya’s fingerprint ensures only she can use the passkey.

User Experience:

  • Fast: Fingerprint authentication is quicker than typing a password.
  • Seamless: Automatic passkey creation eliminates manual setup.

Example 2: Signing into YouTube on a Windows Laptop via Cross-Device Authentication

Scenario:

  • Jamal, a YouTube user, wants to sign into his Google Account on a Windows laptop using Chrome. His passkey, created on his Android phone and stored in Google Password Manager, is used as the default method.

Steps:

  1. Passkey Creation:
    • Jamal previously signed into his Google Account on his Android phone (Android 13), where Google Password Manager automatically created a passkey and synced it to his account.
  2. Sign-In on Laptop:
    • Jamal opens Chrome (version 120) on his laptop and navigates to YouTube, clicking “Sign in.”
    • Since passkeys are the default, Chrome prompts him to use a passkey and displays a QR code for cross-device authentication.
    • Jamal scans the QR code with his Android phone’s camera or Google app, which prompts him to authenticate with his face scan.
    • The phone’s TPM retrieves the private key, signs Google’s challenge, and sends the signature to the laptop via a secure WebAuthn channel over TLS.
    • Chrome forwards the signature to Google’s servers, which verify it with the public key, granting access to YouTube.
  3. Outcome:
    • Jamal signs in without a password, using his phone as the authenticator, as prompted by the default passkey option.
    • Google Password Manager’s syncing ensures the passkey is available without needing to create one on the laptop.

Security Benefits:

  • Phishing Protection: The passkey is scoped to accounts.google.com, preventing misuse on fraudulent sites.
  • Secure Cross-Device Communication: The QR code and WebAuthn channel are encrypted, thwarting interception.
  • Device-Bound Security: The private key remains on the phone, inaccessible to the laptop.

User Experience:

  • Convenient: Scanning a QR code and using face scan is faster than entering credentials.
  • Flexible: Jamal can sign in on any supported browser without storing credentials on the laptop.

Example 3: Signing into Google Drive on a Chromebook

Scenario:

  • Maria, a teacher, uses a Chromebook (running ChromeOS 115) to access Google Drive for lesson plans. Her passkey, managed by Google Password Manager, is the default sign-in method.

Steps:

  1. Passkey Setup:
    • Maria previously signed into her Google Account on her Android tablet, where Google Password Manager created a passkey and synced it to her account.
  2. Sign-In on Chromebook:
    • Maria opens Chrome on her Chromebook and navigates to Google Drive.
    • As passkeys are the default, Chrome prompts her to use her passkey, detecting it via Google Password Manager.
    • Maria authenticates with her Chromebook’s PIN (set as the screen lock).
    • The Chromebook’s TPM retrieves the synced private key, signs Google’s challenge, and sends the signature to Google’s servers.
    • Google verifies the signature, granting Maria access to Google Drive.
  3. Outcome:
    • Maria signs in seamlessly using the default passkey, without needing a password.
    • The passkey, synced via Google Password Manager, ensures consistency across her devices.

Security Benefits:

  • Phishing Resistance: The passkey only authenticates for Google’s domain.
  • End-to-End Encryption: The synced passkey is protected, inaccessible to Google or attackers.
  • User Verification: The PIN ensures only Maria can use the passkey.

User Experience:

  • Streamlined: PIN authentication is quick and familiar on ChromeOS.
  • Synced Access: No need to create a new passkey on the Chromebook.

Example 4: Signing into a Third-Party Service with Google Account Passkey

Scenario:

  • Alex, a freelancer, signs into a third-party service like DocuSign, which supports FIDO2 passkeys and Google Account single sign-on (SSO). His passkey, stored in Google Password Manager, is used as the default method.

Steps:

  1. Passkey Creation:
    • Alex enabled a passkey on his Android phone via Google Password Manager, which synced it to his Google Account.
  2. Sign-In Process:
    • Alex visits DocuSign’s website on his Android phone’s Chrome browser and selects “Sign in with Google.”
    • DocuSign redirects to Google’s authentication service, which prompts Alex to use his passkey (the default method).
    • Google Password Manager retrieves the passkey from the phone’s TPM, and Alex authenticates with his fingerprint.
    • The phone signs a challenge for accounts.google.com, and Google verifies it, issuing an SSO token to DocuSign.
    • DocuSign grants Alex access based on Google’s authentication.
  3. Outcome:
    • Alex signs into DocuSign using his Google Account passkey, prompted as the default method, without needing a separate DocuSign password.
    • Google Password Manager simplifies authentication across services.

Security Benefits:

  • Phishing Resistance: The passkey ensures authentication only for Google’s domain, protecting the SSO process.
  • Secure SSO: Google’s verification ensures DocuSign receives a trusted token.
  • Encrypted Storage: The passkey remains secure in Google Password Manager.

User Experience:

  • Unified: Alex uses one passkey for Google and third-party services.
  • Fast: Fingerprint authentication streamlines SSO.

Example 5: Fallback to Password on an Unsupported Device

Scenario:

  • Sarah, a Google Account user, tries to sign into Google Photos on an older Windows PC running an outdated browser (e.g., Chrome 90). Her passkey, stored in Google Password Manager, is unavailable due to lack of WebAuthn support, so she uses a fallback method.

Steps:

  1. Passkey Setup:
    • Sarah’s passkey was created on her Android phone and synced via Google Password Manager.
  2. Sign-In Attempt:
    • Sarah opens Chrome 90 on the old PC and navigates to Google Photos.
    • Since the browser doesn’t support WebAuthn, the passkey option (default) is unavailable.
    • Google automatically prompts Sarah to use her password instead, with an option for 2FA (e.g., SMS code).
    • Sarah enters her password and receives an SMS code, completing the sign-in.
  3. Outcome:
    • Sarah accesses Google Photos despite the lack of passkey support, demonstrating the fallback mechanism.
    • Google Password Manager’s passkey remains available for future sign-ins on supported devices.

Security Benefits:

  • Fallback Security: Passwords and 2FA ensure access without compromising account security.
  • Phishing Resistance: The passkey remains secure on Sarah’s phone, unused in this scenario.
  • Flexibility: Google’s fallback options accommodate older devices.

User Experience:

  • Accessible: Sarah isn’t locked out due to browser limitations.
  • Encourages Upgrade: Google may prompt Sarah to update her browser or use a supported device for passkeys.

Example 6: High-Risk User in Advanced Protection Program

Scenario:

  • Emma, a journalist enrolled in Google’s Advanced Protection Program (APP), signs into Google Workspace on her Android tablet. Her passkey, managed by Google Password Manager, is the default method for phishing-resistant authentication.

Steps:

  1. Passkey Setup:
    • Emma enabled a passkey on her Android tablet, stored in Google Password Manager and synced to her Google Account, meeting APP’s requirement for phishing-resistant credentials.
  2. Sign-In Process:
    • Emma opens Google Workspace (e.g., Gmail) on her tablet.
    • As passkeys are the default, Google Password Manager prompts her to authenticate with her tablet’s face scan.
    • The tablet’s TPM signs Google’s challenge, and Google verifies it, granting access.
    • The passkey replaces the need for a security key, simplifying APP authentication.
  3. Outcome:
    • Emma signs in securely, leveraging the passkey as the default method, tailored for high-risk users.
    • Google Password Manager ensures the passkey is available across her devices.

Security Benefits:

  • Phishing Resistance: Critical for APP users vulnerable to targeted attacks.
  • High Security: The passkey meets APP’s stringent requirements, equivalent to a security key.
  • Secure Syncing: End-to-end encryption protects the passkey.

User Experience:

  • Simplified: Emma avoids carrying a physical security key, using her tablet instead.
  • Seamless: The passkey integrates with her Google Workspace workflow.

Additional Notes on Passkeys as the Default Method

  • Automatic Adoption: Google’s default setting encourages users to adopt passkeys without manual configuration, increasing security adoption. Users are prompted at or during sign-in to enable passkeys.
  • Cross-Platform Flexibility: While optimized for Android and Chrome, passkeys work on iOS, Windows, and macOS via Chrome or third-party password managers, ensuring broad accessibility.
  • Third-Party Service Growth: As more services (e.g., PayPal, DocuSign) adopt FIDO2, Google Password Manager’s passkeys can be used beyond Google services, enhancing their utility.
  • User Control: Users can manage passkeys , disabling the default setting or deleting passkeys if needed.
  • Fallback Mechanisms: Google ensures accessibility by maintaining passwords, 2FA, and recovery options, critical for unsupported devices or edge cases.

Passkeys leverage public-key cryptography, secure hardware (e.g., secure enclave, TPM), and user verification (e.g., biometrics, PINs) to provide strong security. However, their effectiveness depends on proper device and account management. Below are detailed best practices, organized by category, with explanations of their importance and implementation steps.

Why It’s Important:

  • Passkeys are tied to specific devices (e.g., phones, computers, or hardware security keys), with private keys stored in secure hardware like a Trusted Platform Module (TPM) or secure enclave. If a device is compromised or stolen, an attacker could potentially use the passkey if they bypass the device’s screen lock.

Best Practices:

  • Enable a Strong Screen Lock:
    • Use a robust PIN, password, or biometric authentication (e.g., fingerprint, face scan) on all devices storing passkeys.
    • Avoid simple PINs (e.g., “1234”) or patterns; use a complex PIN (6+ digits) or a long passphrase.
    • Example: On an Android phone, go to Settings > Security > Screen Lock and set a 6-digit PIN or enable fingerprint authentication.
  • Keep Devices Updated:
    • Regularly update the device’s operating system and apps to patch security vulnerabilities that could compromise the secure enclave or TPM.
    • Example: On an iPhone, go to Settings > General > Software Update to ensure iOS is up to date (e.g., iOS 16+ for passkey support).
  • Use Trusted Devices:
    • Only create passkeys on devices you own and control. Avoid using shared or public devices (e.g., library PCs) to store passkeys, as they may be insecure.
    • Example: Create a passkey on your personal Android phone rather than a work computer shared with colleagues.
  • Enable Remote Wipe:
    • Activate features like Find My Device (Android) or Find My iPhone (iOS) to remotely lock or wipe a lost or stolen device, protecting stored passkeys.
    • Example: On Android, enable Find My Device in Settings > Security > Find My Device and link it to your Google Account.

Mitigated Risks:

  • Device theft: A strong screen lock prevents unauthorized access to the passkey.
  • Malware: Updates patch vulnerabilities that could target secure hardware.
  • Shared device exposure: Using personal devices reduces the risk of passkey misuse.

Why It’s Important:

  • Although passkeys are the default sign-in method for personal Google Accounts (since October 2023), passwords remain a fallback option for unsupported devices or recovery scenarios. A weak password could compromise the account if passkeys are unavailable.

Best Practices:

  • Create a Long, Unique Password:
    • Use a password that is at least 32–64 characters long, randomly generated, and unique to your Google Account.
    • Avoid reusing passwords across sites to prevent credential stuffing attacks.
    • Example: Generate a password like “X7p#9mZ!qW2kL8vN3rT5yU0jF6hP2dQ” using Google Password Manager or a third-party tool like 1Password.
  • Store Password Securely:
    • Save the password in Google Password Manager or a trusted third-party password manager to avoid memorizing it.
    • Example: In Chrome, go to Settings > Autofill > Password Manager to save and manage your Google Account password.
  • Avoid Sharing or Writing Down Passwords:
    • Never share your password or store it in insecure locations (e.g., sticky notes, unencrypted files).
    • Example: If you must write down your password, store it in a locked safe or encrypted digital vault.

Mitigated Risks:

  • Credential stuffing: A unique password prevents attackers from using credentials stolen from other sites.
  • Fallback compromise: A strong password ensures security when passkeys cannot be used (e.g., on older browsers).

Why It’s Important:

  • If you lose access to all devices with passkeys (e.g., due to theft or failure), recovery options like email or phone numbers allow you to regain access to your Google Account and create new passkeys.

Best Practices:

  • Add Recovery Email and Phone Number:
    • Set up a secondary email address and phone number for account recovery.
    • Example: Go to myaccount.google.com > Security > Recovery Email/Phone and add a trusted email (e.g., a secondary Gmail account) and phone number.
  • Use Secure Recovery Options:
    • Ensure the recovery email and phone number are associated with secure accounts or devices you control.
    • Example: Use a recovery email protected by a strong password and 2FA, and a phone number tied to a trusted device.
  • Regularly Verify Recovery Options:
    • Check and update recovery details periodically to ensure they’re current and accessible.
    • Example: Every 6 months, visit myaccount.google.com to confirm your recovery email and phone number are still valid.
  • Enable 2FA for Recovery Access:
    • Enable two-factor authentication (e.g., authent PURPLE) on your recovery email account to secure it.
    • Example: Set up 2FA for your recovery Gmail account at myaccount.google.com > Security > 2-Step Verification.

Mitigated Risks:

  • Account lockout: Recovery options ensure access if all passkey devices are lost.
  • Unauthorized recovery: Secure recovery accounts prevent attackers from hijacking recovery processes.

Why It’s Important:

  • Passkeys stored in Google Password Manager are synced across devices signed into the same Google Account using end-to-end encryption. This ensures availability and prevents lockout if a single device is lost or unavailable.

Best Practices:

  • Enable Google Password Manager Syncing:
    • On Android devices (9.0+), ensure passkeys are synced via Google Password Manager.
    • Example: Sign into your Google Account on an Android phone, and Google Password Manager will automatically create and sync a passkey .
  • Use Multiple Devices:
    • Create passkeys on multiple trusted devices (e.g., phone, tablet, computer) to ensure redundancy.
    • Example: Set up passkeys on both your Android phone and Chromebook to access your Google Account from either device.
  • Verify Synced Passkeys:
    • Check google passkeys to confirm which devices have passkeys and ensure they’re synced.
    • Example: Visit the passkey settings to see a list of devices (e.g., “Samsung Galaxy S23,” “Chromebook”) with active passkeys.
  • Consider Third-Party Password Managers:
    • For cross-platform flexibility (e.g., Android to iOS), use third-party password managers like 1Password or NordPass that support passkeys.
    • Example: Export passkeys to 1Password for use on a non-Google ecosystem device like an iPhone.

Mitigated Risks:

  • Device loss: Synced passkeys ensure access from other devices.
  • Ecosystem lock-in: Third-party managers provide flexibility across platforms.

Why It’s Important:

  • Passkeys are only as secure as the devices or hardware security keys they’re stored on. Using untrusted or insecure authenticators (e.g., jailbroken devices) could compromise the private key.

Best Practices:

  • Choose Secure Devices:
    • Create passkeys on devices with hardware-backed security (e.g., secure enclave on iPhones, TPM on Android/Windows).
    • Example: Use an iPhone 14 with iOS 17 or a Google Pixel 8 with Android 14 for passkey creation.
  • Use FIDO2-Compliant Security Keys:
    • For hardware-based passkeys, use FIDO2-compliant keys like YubiKey 5 or Google Titan Security Key, which support PIN or biometric verification.
    • Example: Register a YubiKey at google passkeys for use with Google’s Advanced Protection Program.
  • Avoid Compromised Devices:
    • Do not create passkeys on rooted, jailbroken, or otherwise compromised devices, as they may bypass secure hardware protections.
    • Example: Avoid using an Android phone with an unlocked bootloader for passkey storage.

Mitigated Risks:

  • Compromised authenticators: Trusted devices and keys ensure the private key remains secure.
  • Unauthorized access: FIDO2-compliant keys require user verification, preventing misuse.

Why It’s Important:

  • Passkeys are tied to specific devices or security keys. If a device is lost, stolen, or compromised, unauthorized passkeys must be revoked to prevent access.

Best Practices:

  • Review Passkeys Periodically:
    • Visit google passkeys to check the list of devices and security keys with registered passkeys.
    • Example: Check passkey settings to confirm only your current phone, laptop, and YubiKey are listed.
  • Revoke Passkeys for Lost Devices:
    • Remove passkeys associated with lost or decommissioned devices to prevent unauthorized use.
    • Example: If you lose your old phone, go to myaccount.google.com > Security > Passkeys and security keys and delete the passkey for that device.
  • Audit Synced Passkeys:
    • Ensure only trusted devices have synced passkeys via Google Password Manager.
    • Example: Remove a passkey from a tablet you no longer use to reduce risk.

Mitigated Risks:

  • Unauthorized access: Revoking passkeys for lost devices prevents misuse.
  • Stale credentials: Regular audits ensure only current devices have access.

Why It’s Important:

  • While passkeys are phishing-resistant due to domain scoping (e.g., only working for accounts.google.com), users must still avoid phishing attempts that trick them into revealing recovery details or authenticating on fake sites.

Best Practices:

  • Verify Website Domains:
    • Ensure you’re signing in on legitimate Google domains (e.g., accounts.google.com) before using a passkey.
    • Example: Check the URL bar in Chrome to confirm it’s “https://accounts.google.com” before scanning a QR code.
  • Be Cautious with QR Codes:
    • Only scan QR codes displayed by trusted devices or websites for cross-device authentication.
    • Example: Avoid scanning a QR code from an email link unless you initiated the sign-in process on a known Google service.
  • Educate Yourself on Phishing Tactics:
    • Learn to recognize phishing emails or messages that mimic Google’s login prompts.
    • Example: Ignore emails claiming “Your Google Account needs verification” and go directly to myaccount.google.com to check your account status.

Mitigated Risks:

  • Phishing attacks: Domain scoping ensures passkeys don’t work on fake sites.
  • Social engineering: Awareness prevents users from being tricked into revealing recovery details.

Why It’s Important:

  • High-risk users (e.g., journalists, activists, executives) face targeted attacks like spear-phishing. Google’s Advanced Protection Program (APP) integrates passkeys for phishing-resistant authentication, enhancing security.

Best Practices:

  • Enroll in APP:
    • Sign up for APP at myaccount.google.com/advancedprotection and use a passkey or FIDO2 security key as the primary authentication method.
    • Example: Register a passkey on your Android phone or a YubiKey for APP authentication.
  • Use Passkeys as Default:
    • Since passkeys are the default for personal accounts, ensure APP uses a passkey stored in Google Password Manager or a hardware key.
    • Example: Set up a passkey on your iPhone for APP, synced via Google Password Manager for redundancy.
  • Combine with Recovery Options:
    • Ensure APP accounts have secure recovery email and phone options to avoid lockout.
    • Example: Add a recovery email protected by 2FA to your APP-enabled Google Account.

Mitigated Risks:

  • Targeted attacks: Passkeys provide phishing-resistant authentication for high-risk users.
  • Account compromise: APP’s strict requirements ensure robust protection.

Why It’s Important:

  • Understanding how passkeys work helps users avoid mistakes, such as creating passkeys on insecure devices or failing to set up recovery options.

Best Practices:

  • Learn Passkey Basics:
    • Read Google’s documentation at support.google.com or the FIDO Alliance website to understand passkey mechanics (e.g., public-key cryptography, domain scoping).
    • Example: Review Google’s passkey guide to learn how private keys are stored in secure hardware.
  • Practice Safe Authentication:
    • Familiarize yourself with cross-device authentication (e.g., QR code scanning) and user verification processes.
    • Example: Practice signing into Gmail on a laptop using a phone-based passkey to understand the workflow.
  • Stay Informed on Updates:
    • Monitor Google’s announcements for passkey feature updates or new security recommendations.
    • Example: Check blog.google for posts about passkey enhancements or adoption milestones.

Mitigated Risks:

  • User errors: Knowledge prevents mistakes like creating passkeys on untrusted devices.
  • Obsolescence: Staying updated ensures compatibility with new passkey features.

Scenario:

  • Alex, a Google Account user, wants to secure his account using passkeys as the default sign-in method (since October 2023). He follows these best practices to ensure maximum security.

Implementation:

  1. Device Security:
    • Alex sets a 6-digit PIN and enables fingerprint authentication on his Android phone (Pixel 7, Android 14).
    • He updates his phone to the latest OS version via Settings > System > System Update.
    • He enables Find My Device to allow remote wiping if the phone is lost.
  2. Strong Password:
    • Alex generates a 32-character random password using Google Password Manager and stores it securely in the manager.
  3. Recovery Options:
    • He adds a recovery email (protected by 2FA) and a trusted phone number at myaccount.google.com > Security > Recovery Email/Phone.
  4. Synced Passkeys:
    • Alex enables a passkey on his Android phone via google passkeys, which Google Password Manager syncs to his Google Account.
    • He also creates a passkey on his Chromebook for redundancy.
  5. Trusted Authenticators:
    • Alex uses his Pixel 7’s TPM for the passkey, avoiding a rooted tablet he owns.
  6. Passkey Management:
    • He checks google passkeys to confirm only his phone and Chromebook have passkeys, removing an old device he no longer uses.
  7. Phishing Awareness:
    • Alex verifies URLs before signing in and ignores suspicious emails claiming account issues.
  8. Education:
    • He reads Google’s passkey guide to understand cross-device authentication and practices signing into Gmail using his phone’s passkey on his Chromebook.