Passwords are no longer the front line of account security. Google has spent the past three years pushing users toward passkeys, and by 2026 the shift has real numbers behind it: one global passkey adoption survey found that roughly 90% of consumers now recognize the term “passkey,” and about 75% of those who tried one have kept it enabled on at least one account. A separate mid-2026 authentication trends analysis puts total passkeys in active use worldwide near 5 billion, spanning consumer and enterprise accounts. Google sits at the center of that growth: Authsignal reported in May 2025 that Google passkeys were enabled on 800 million accounts, and Dashlane found in October 2025 that 40% of its users stored at least one passkey, versus 20% in 2024. If you still sign into Gmail, Drive, or YouTube with a typed password and an SMS code, this tutorial walks through exactly what changed, why it matters, and how to rebuild your account’s defenses in a single sitting.
This guide covers the full setup: running Google’s Security Checkup, registering a passkey on desktop and mobile, adding a hardware security key as a fallback, turning on 2-Step Verification, auditing OAuth app access, and, for readers who manage a Google Workspace fleet, enforcing passkeys across an organization with the Admin SDK. Expect to spend 40 to 60 minutes end to end if you are starting from a bare password-only account.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Google Passkeys and 2-Step Verification Matter Right Now
Phishing is still the single most common way accounts get taken over, and it works because a password and a typed one-time code can both be copied by a fake login page in real time. A passkey removes that weakness at the protocol level. As Google put it when it opened passkeys to all personal accounts, “passkeys are a new way to sign in to apps and websites. They’re both easier to use and more secure than passwords” (Google, official blog).
The mechanism matters here. A passkey is a WebAuthn credential tied to a specific device and a specific site. The private key never leaves your phone, laptop, or security key, so there’s nothing typed that a phishing page can capture and replay. Google’s own security engineering team has described the shift plainly: “passkeys are a safer and more secure alternative to passwords” (Google Security Blog). The National Institute of Standards and Technology reaches a similar conclusion in its digital identity guidelines, which rank phishing-resistant authenticators like WebAuthn above SMS and app-based one-time codes for high-assurance sign-in (NIST SP 800-63B).
None of this means you should drop 2-Step Verification. Passkeys and 2SV solve overlapping but distinct problems: a passkey replaces the password entirely on devices that support it, while 2SV protects the account on devices or browsers where a passkey hasn’t been registered yet, and during account recovery. Google’s help documentation is explicit that the two work together rather than one replacing the other outright: “when you sign in with a passkey, it bypasses your second authentication step, since it verifies that you have possession of your device” (Google Account Help). That’s why this tutorial sets up both layers instead of treating them as either/or.
The shift also shows up in how account-takeover incidents get investigated after the fact. Security teams reviewing breach postmortems in 2026 increasingly find the same root cause: a reused or phished password paired with an OTP the attacker intercepted through a real-time relay page, not a cracked encryption scheme or a zero-day exploit. Passkeys don’t just make that specific attack harder — they remove the field (a typed secret) that the attack depends on entirely. That’s a meaningfully different security posture than “add one more factor,” which is why account-security guidance shifted from recommending 2SV as sufficient to recommending passkeys as the default, with 2SV kept as the fallback layer rather than the primary one.
Prerequisites: What You Need Before You Start
Passkeys rely on a device’s built-in biometric or PIN unlock, so you need at least one modern device to register the first credential. Nothing here requires a paid subscription, every tool in this walkthrough is free.
- A Google Account with a working recovery email and phone number on file.
- One primary device with screen-lock biometrics or a PIN: Windows 10/11 with Windows Hello, macOS with Touch ID, an Android phone (Android 9 or later), or an iPhone/iPad (iOS 16 or later).
- A current version of Chrome, Edge, Safari, or Firefox, all four browsers ship WebAuthn/passkey support in their default release channel as of 2026.
- Optional but recommended: a FIDO2 hardware security key (YubiKey, Google Titan, or similar) as a device-independent backup passkey.
- Optional: a password manager that syncs passkeys across platforms (1Password, Bitwarden, or your OS-level keychain) if you don’t want passkeys locked to a single device ecosystem.
- For the admin section: a Google Workspace super admin or user-management admin role, plus Python 3.9+ and the
google-api-python-clientlibrary if you want to run the audit scripts.
If you’re also managing password reuse across other services, it’s worth pairing this walkthrough with a password manager comparison, see our breakdown of 1Password vs LastPass vs RoboForm if you haven’t settled on one yet, since several managers now store and sync passkeys the same way they store passwords.
Step 1: Run the Google Security Checkup Baseline
Start by establishing a baseline instead of guessing what’s already configured. Go to myaccount.google.com/security-checkup while signed in. Google walks through recent security activity, your devices, 2-Step Verification status, and third-party access, flagging anything that needs attention with a yellow or red marker.
Note every flagged item before moving on, an old recovery phone number, a stale session on a device you no longer own, or an app you granted access to years ago and forgot about. You’ll clear each of these systematically in the steps below rather than trying to fix everything from inside the checkup flow itself, which doesn’t expose the more granular controls (like conditional mediation testing or hardware-key registration) that this guide covers.
Step 2: Lock Down Recovery Email and Phone
Recovery contact details are the fallback Google uses to verify your identity if you’re ever locked out, which also makes them a target. An attacker who compromises your recovery email can often reset your Google Account password even with 2SV enabled, because account-recovery flows are designed to work around lost second factors.
Under Security in your Google Account, confirm the recovery email is one you actively control and that it is itself protected with a passkey or 2SV, because securing your primary account while leaving a Yahoo or Hotmail recovery address wide open just moves the weak point one hop over. Google describes recovery contacts, phones, emails, and the selfie video option it announced on October 15, 2026 as complementary, so keeping every one of them current matters even after you add a passkey. Do the same for your recovery phone number: remove any number tied to a SIM you no longer use, since SIM-swap attacks remain one of the more common ways account recovery gets abused.
Step 3: Confirm Passkey Support on Your Devices
Before registering a passkey, it helps to confirm your browser actually exposes the WebAuthn platform authenticator API rather than discovering a failure mid-setup. Open your browser’s developer console (F12, then the Console tab) on the device you plan to use, and paste the following:
if (window.PublicKeyCredential &&
PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable) {
PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
.then((available) => {
console.log("Platform authenticator (Windows Hello / Touch ID / fingerprint) available:", available);
});
} else {
console.log("WebAuthn platform authenticator API not supported in this browser.");
}
// Check whether the browser supports passkey autofill (conditional UI)
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
PublicKeyCredential.isConditionalMediationAvailable()
.then((supported) => console.log("Passkey autofill supported:", supported));
}Both checks should return true on a current Chrome, Edge, or Safari release running on Windows 11, macOS, Android, or iOS. If isUserVerifyingPlatformAuthenticatorAvailable returns false, your device either lacks a biometric sensor/PIN lock or the OS hasn’t enabled one, set up Windows Hello or Touch ID first, then re-run the check.
Step 4: Create a Passkey on Desktop (Windows, macOS, or Chrome OS)
With platform authenticator support confirmed, go to myaccount.google.com/security (or visit g.co/passkeys, the address Google’s current setup guidance points to), open Passkeys and security keys, and select “Create a passkey.” Google will trigger your OS-level prompt (Windows Hello, Touch ID, or your device PIN) to confirm it’s actually you sitting at the machine. Once approved, the passkey is generated locally and only the public half is registered with Google; the private key stays on your device or inside your OS/browser’s credential manager.
If your browser is signed into a password manager with passkey sync (Chrome’s Google Password Manager, Windows’ linked Microsoft account, or a third-party manager like 1Password or Bitwarden), the passkey syncs to every device signed into that same manager. If you want a passkey that isn’t tied to any sync service, useful for a work laptop you don’t want linked to a personal cloud account, choose “Use another device” during creation and register a hardware key instead, covered in Step 6.
Step 5: Create a Passkey on Android and iPhone
On mobile, open the Google app or Chrome, sign in, go to your Google Account, then Security, then Passkeys and security keys. Tap “Create a passkey” and confirm with your fingerprint, face unlock, or device PIN. On Android, the passkey saves to Google Password Manager by default and becomes available across any Android device signed into the same Google Account. On iPhone, iOS will offer to save it to iCloud Keychain unless you’ve set a different default password manager, in which case it saves there instead.
This is also the point where cross-device sign-in becomes relevant: if you’re logging into Google on a desktop that doesn’t have a passkey registered yet, choose “Try another way” at the sign-in screen, select “Use a passkey from another device,” and scan the QR code with your phone’s camera. That flow uses Bluetooth to confirm device proximity, so a remote attacker who steals the QR code image can’t complete the sign-in without also being physically near you. If you’re setting up a family member’s Android device for the first time and need a broader walkthrough, our guide on how to migrate passkeys between password manager apps on Android covers moving credentials between Google Password Manager and third-party managers step by step.
Step 6: Add a Hardware Security Key as a Backup Passkey
A phone-based passkey is convenient, but it has one failure mode: if the phone is lost, stolen, wiped, or simply not with you, you need another route in. A FIDO2 hardware security key solves this because it’s a physical object independent of any single device or cloud sync account.
From the same Passkeys and security keys page, select “Create a passkey,” then choose “Use another device” and pick “USB security key” (or NFC/Bluetooth, depending on the key). Insert the key, tap it when prompted, and Google registers it as a second, independent passkey. Keep this key somewhere separate from your primary phone, a desk drawer at a different location, a safe, or with a trusted family member, specifically so a single event (lost bag, house fire, stolen phone) can’t take out both your phone-based and hardware-based passkeys at once.
Step 7: Turn On 2-Step Verification
Passkeys cover devices where you’ve registered one. 2-Step Verification covers everything else, a friend’s computer, a public library terminal, or the brief window on a new device before you’ve had a chance to add a passkey. Go to the Security tab, select 2-Step Verification, and turn it on. Google will ask you to choose a second factor: an authenticator app (Google Authenticator or any TOTP-compatible app), a prompt sent to a trusted phone, or as a last resort, SMS.
Pick the authenticator app or Google prompt over SMS if you have the choice. SMS-based codes remain vulnerable to SIM-swapping and SS7 interception, and NIST’s own guidance has flagged SMS as the weakest of the standard second-factor options for years (NIST SP 800-63B). Keep SMS configured as a final fallback if you want it, but don’t make it your primary method.
Step 8: Generate and Store Backup Codes
Backup codes are single-use codes that work even if you lose access to every other second factor at once, phone, security key, and authenticator app. Under 2-Step Verification, scroll to “Backup codes” and generate a set of ten. Do not store these in a plain-text file on the same device that holds your passkeys; if that device is compromised, the codes and the passkeys go together.
Print them and store the paper copy somewhere physically secure, or save them inside a password manager’s secure notes feature with its own independent unlock method. Cross off each code as you use it, and regenerate a fresh set once you’re down to two or three remaining, old codes get invalidated automatically when you generate a new batch.
Step 9: Audit Third-Party App and OAuth Access
Every app you’ve ever signed into with “Continue with Google” has a standing OAuth grant to some slice of your account data. Go to myaccount.google.com/connections and review the full list. Revoke access for anything you don’t recognize, don’t use anymore, or that requests more scope than it plausibly needs (a note-taking app asking for full Gmail access is a red flag).
If you’re a developer and want to check a specific OAuth token’s granted scopes programmatically before deciding whether to revoke it, Google’s tokeninfo endpoint returns the scope list for a given access token without requiring extra credentials:
curl -s "https://oauth2.googleapis.com/tokeninfo?access_token=YOUR_ACCESS_TOKEN" | python3 -m json.tool
# Example output:
# {
# "scope": "https://www.googleapis.com/auth/drive.readonly https://www.googleapis.com/auth/userinfo.email",
# "expires_in": "3599",
# "email": "[email protected]"
# }
# To revoke a token directly (kills that app's access immediately):
curl -s -X POST "https://oauth2.googleapis.com/revoke?token=YOUR_ACCESS_TOKEN"For everyday cleanup, though, the myaccount.google.com/connections page does the same job with no scripting required, the API route above is mainly useful when you’re auditing tokens issued to your own app during development.
Step 10: Review Devices and Kill Unfamiliar Sessions
Under “Your devices” in the Security section, Google lists every device with an active session on your account, along with approximate location and last-active time. Sign out of anything you don’t recognize immediately, then sign out of devices you recognize but no longer use, an old phone traded in without a factory reset, a work laptop you returned, or a browser profile on a shared family computer.
This step matters more after you’ve just added passkeys and 2SV, not less: an attacker with an already-active session from before you locked things down can sometimes ride that session past your new protections, since session cookies aren’t always invalidated by a password or 2SV change alone. Forcing a sign-out on every device closes that gap.
Step 11: Turn On Enhanced Safe Browsing and Run Password Checkup
Two more one-time toggles round out the account-level defenses. First, in Chrome’s settings under Privacy and Security, switch Safe Browsing from Standard to Enhanced, this checks URLs and downloads against Google’s threat lists in real time rather than relying on a periodically updated local list, catching newly registered phishing domains faster. Second, run Password Checkup at passwords.google.com, which flags any saved password that’s weak, reused across sites, or has appeared in a known data breach.
If you want to check a specific password against breach data yourself without exposing the plaintext password to a third-party service, Have I Been Pwned’s Pwned Passwords API uses k-anonymity: you send only the first five characters of the password’s SHA-1 hash, and the API returns all breached hash suffixes matching that prefix, so the full password never leaves your machine.
import hashlib
import urllib.request
def check_password_pwned(password: str) -> int:
sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
prefix, suffix = sha1[:5], sha1[5:]
url = f"https://api.pwnedpasswords.com/range/{prefix}"
with urllib.request.urlopen(url) as response:
body = response.read().decode("utf-8")
for line in body.splitlines():
hash_suffix, count = line.split(":")
if hash_suffix == suffix:
return int(count)
return 0
count = check_password_pwned("correcthorsebatterystaple")
print(f"Seen in {count} known breaches" if count else "Not found in known breaches")Replace anything flagged with a unique, generated password of at least 16 characters stored in a password manager, not a variation of a password you use elsewhere.
Step 12: For Admins: Enforce Passkeys Across a Google Workspace Fleet
Everything above covers a single personal account. If you’re a Workspace admin responsible for a whole organization, the Admin console lets you require 2-Step Verification org-wide under Security, and the Admin SDK Directory API exposes per-user enrollment status so you can track rollout programmatically instead of checking accounts one by one. The Users resource includes isEnrolledIn2Sv and isEnforcedIn2Sv boolean fields for exactly this purpose:
from googleapiclient.discovery import build
from google.oauth2 import service_account
SCOPES = ["https://www.googleapis.com/auth/admin.directory.user.readonly"]
DELEGATED_ADMIN = "[email protected]"
credentials = service_account.Credentials.from_service_account_file(
"service-account.json", scopes=SCOPES
).with_subject(DELEGATED_ADMIN)
service = build("admin", "directory_v1", credentials=credentials)
results = service.users().list(customer="my_customer", maxResults=100).execute()
for user in results.get("users", []):
email = user["primaryEmail"]
enrolled = user.get("isEnrolledIn2Sv", False)
enforced = user.get("isEnforcedIn2Sv", False)
status = "OK" if enrolled else "NOT ENROLLED"
print(f"{email:40s} enrolled={enrolled} enforced={enforced} [{status}]")Run this weekly (or wire it into a scheduled job) to catch new hires or contractors who haven’t completed enrollment before an enforcement deadline hits and locks them out mid-workday. To pull each user’s granted OAuth apps for a security audit, the same API exposes a tokens endpoint per user (admin.directory.user.security scope), which returns every third-party app with standing access, the org-wide equivalent of the personal connections page from Step 9. If your organization is also standardizing on keyless service-to-service authentication elsewhere in the stack, it’s worth a look at our GCP Workload Identity Federation setup guide, which applies the same “no long-lived secret to steal” principle to service accounts instead of user logins.
Passkeys vs 2-Step Verification vs Passwords: What Each Actually Protects
It helps to see the three methods side by side, since they get conflated constantly in casual conversation but protect against different attack types.
| Method | Phishing-resistant? | Works offline? | Device-bound? | Typical recovery risk |
|---|---|---|---|---|
| Password alone | No | Yes | No | High: reused/breached passwords are the top account-takeover cause |
| Password + SMS 2SV | Partial | No (needs signal) | No | Medium: vulnerable to SIM swap and real-time phishing relay |
| Password + authenticator app 2SV | Partial | Yes | Yes | Medium: safe from SIM swap, still relayable via phishing |
| Passkey (phone or security key) | Yes | Yes | Yes | Low: cryptographically bound to the real domain, nothing to relay |
The practical takeaway: a passkey blocks the phishing relay attacks that both password-only and OTP-based 2SV remain exposed to, because the credential itself checks that it’s talking to the genuine google.com domain before it will respond, a fake login page simply gets nothing back. That’s also why security teams increasingly describe passkeys not as “another MFA option” but as a structurally different category. Google’s help documentation frames it directly: “with a passkey, you can sign in to your Google Account with your fingerprint, face scan, or phone screen lock, like a PIN” (Google Account Help), the authentication happens locally, and nothing secret ever crosses the network.
Device and Browser Passkey Support in 2026
Support is broad at this point, but a few platform-specific quirks still trip people up during setup.
| Platform | Passkey storage | Sync scope | Cross-device sign-in via QR |
|---|---|---|---|
| Windows 10/11 + Chrome/Edge | Windows Hello + Google Password Manager or Windows Account | Synced Google/Microsoft account devices | Yes |
| macOS + Safari/Chrome | iCloud Keychain (Safari) or Google Password Manager (Chrome) | Apple ID or Google Account devices | Yes |
| Android 9+ | Google Password Manager (or chosen default) | All Android devices on the same Google Account | Yes (source device) |
| iOS 16+ / iPadOS 16+ | iCloud Keychain (or chosen default) | All Apple devices on the same Apple ID | Yes (source device) |
| FIDO2 hardware key | On-device secure element | None: physically portable instead | N/A, plug in directly |
The one gap worth flagging: if you use different password managers on different platforms (say, Google Password Manager on Android and a standalone manager like Bitwarden on your work laptop), passkeys created on one won’t automatically appear on the other. You either need cross-device sign-in via QR code each time, or you export/import the passkey between managers where supported, the FIDO Alliance has been standardizing a credential exchange format for exactly this reason (FIDO Alliance).
5 Common Pitfalls When Setting Up Google Passkeys
- Registering only one passkey on only one device. If that device is lost, stolen, or wiped, you’re back to recovery flows. Register at least two independent authenticators, one phone-based, one hardware key, before you consider setup finished.
- Leaving a weak recovery email as the actual weak point. Hardening your Google Account while your recovery Yahoo or Outlook account still runs on a reused password just relocates the vulnerability. Secure the recovery account first or in parallel.
- Assuming a passkey disables 2SV entirely. It bypasses the second step on devices where the passkey is registered, but any device without one still falls back to your password and 2SV, so skipping 2SV setup leaves that fallback path exposed.
- Storing backup codes next to the device holding the passkeys. A stolen laptop with both a synced passkey and a text file of backup codes on the desktop hands an attacker everything they need in one theft.
- Never revisiting third-party app permissions after initial setup. OAuth grants don’t expire on their own in most cases. An app you approved three years ago and stopped using still has standing access until you manually revoke it.
- Enforcing passkeys org-wide without a pilot group first. Admins who flip enforcement for an entire Workspace domain in one step tend to generate a wave of help-desk tickets from users whose devices fail the platform-authenticator check. Roll it out to one organizational unit first, confirm the audit script shows full enrollment, then expand.
8 Troubleshooting Fixes for Passkey and 2SV Problems
1. “Create a passkey” button is greyed out or missing. This almost always means the browser doesn’t detect a platform authenticator. Re-run the JavaScript feature-detection snippet from Step 3, if it returns false, enable Windows Hello, Touch ID, or a screen-lock PIN in your OS settings first.
2. QR code scan for cross-device sign-in fails or times out. Both devices need Bluetooth enabled, the QR flow uses Bluetooth to confirm physical proximity even though the actual handshake happens over the internet. Toggle Bluetooth on both devices and retry within the 3-minute window before the code expires.
3. Passkey created on Android doesn’t appear on a Windows laptop. Passkeys sync within a credential-manager ecosystem, not universally. A passkey saved to Google Password Manager on Android appears on any device signed into that same Google Account through Chrome, but not automatically inside Windows’ native credential store unless you’re using Chrome there too.
4. Locked out with no working second factor. Use a backup code from Step 8. If those are gone too, Google’s account recovery flow asks device and account-history questions, the more accurate and specific your answers, the faster it resolves.
5. Security key isn’t recognized when plugged in. Try a different USB port (some keys have issues with USB hubs or certain USB-C to USB-A adapters), confirm the key supports FIDO2/WebAuthn specifically (older U2F-only keys work for 2SV but not as a full passkey), and check the browser has permission to access USB devices in its site settings.
6. 2SV prompt notification never arrives on the trusted phone. Check that the Google app has notification permissions enabled and that the phone has a data or Wi-Fi connection, prompts require connectivity, unlike TOTP codes which work fully offline once the authenticator app is set up.
7. Passkey Checkup flow keeps asking to re-verify even after successful sign-in. This is typically a sensitive-action re-authentication step (changing account recovery info, viewing saved passwords), not a sign-in failure. Google intentionally re-checks identity for high-risk actions even within an already-authenticated session.
8. Workspace admin enforcement locks out users mid-rollout. Stage enforcement with a grace period using an organizational unit rollout instead of enforcing org-wide on day one, move a pilot OU to enforced first, confirm the audit script from Step 12 shows 100% enrollment in that OU, then expand.
Advanced Tips: Phishing-Resistant MFA and Conditional Access
Once the baseline setup above is done, a few additional moves push account security further for readers managing higher-risk accounts (admin roles, financial access, or public-facing identities).
First, consider Google’s Advanced Protection Program if you’re a journalist, executive, election worker, or anyone else facing targeted attacks rather than opportunistic ones. It requires two hardware security keys at enrollment and restricts app access to reviewed apps only, trading some convenience for materially stronger phishing resistance.
Second, for organizations running Workspace, context-aware access policies in the Admin console can require a phishing-resistant method (passkey or security key specifically, not just any 2SV) before granting access to particularly sensitive apps like the Admin console itself or finance tools, treating authentication strength as a per-app policy rather than a single account-wide setting.
Third, audit conditional mediation (passkey autofill) support across your team’s browser fleet using the same feature-detection snippet from Step 3, since inconsistent support across an organization’s device fleet is one of the more common reasons passkey rollouts stall, some fraction of users hit a browser or OS combination that silently falls back to password prompts, and without checking, that gap goes unnoticed until an incident.
Finally, treat recovery-flow hardening as an ongoing task, not a one-time step. The UK’s National Cyber Security Centre notes that account recovery paths are frequently the weakest link precisely because they’re designed to work around lost credentials, which means every convenience added to recovery is a convenience an attacker can potentially exploit too (NCSC guidance). Revisit your recovery email and phone number every few months, the same way you’d revisit any other access control.
The Complete Working Project: A Personal Security Audit Checklist Script
Rather than relying on memory to redo this setup periodically, the script below turns the whole checklist into a runnable audit that opens each relevant Google security page in sequence and logs what you’ve confirmed to a local file, so you (or a future you, six months from now) have a dated record of the last full review.
#!/usr/bin/env bash
# google-security-audit.sh
# Walks through the full Google Account hardening checklist from this guide
# and logs a timestamped confirmation for each step.
set -euo pipefail
LOG_FILE="$HOME/.google-security-audit.log"
TIMESTAMP=$(date +"%Y-%m-%d %H:%M")
CHECKLIST=(
"Security Checkup baseline reviewed|https://myaccount.google.com/security-checkup"
"Recovery email and phone confirmed current|https://myaccount.google.com/signinoptions/rescueemail"
"Passkey registered on primary device|https://myaccount.google.com/security"
"Backup hardware security key registered|https://myaccount.google.com/security"
"2-Step Verification enabled|https://myaccount.google.com/signinoptions/two-step-verification"
"Backup codes generated and stored offline|https://myaccount.google.com/signinoptions/two-step-verification/backup-codes"
"Third-party app access reviewed|https://myaccount.google.com/connections"
"Signed-in devices reviewed, unknown sessions killed|https://myaccount.google.com/device-activity"
"Enhanced Safe Browsing enabled in Chrome|chrome://settings/security"
"Password Checkup run, weak passwords replaced|https://passwords.google.com"
)
echo "=== Google Account Security Audit, $TIMESTAMP ===" | tee -a "$LOG_FILE"
for entry in "${CHECKLIST[@]}"; do
IFS='|' read -r label url <<< "$entry"
echo ""
echo "-> $label"
echo " $url"
read -rp " Confirmed? (y/n): " confirmed
if [[ "$confirmed" == "y" ]]; then
echo "[$TIMESTAMP] OK - $label" >> "$LOG_FILE"
else
echo "[$TIMESTAMP] TODO - $label" >> "$LOG_FILE"
fi
done
echo ""
echo "Audit complete. Full history saved to $LOG_FILE"
echo "Run this script again in 3-6 months to catch drift."Save it as google-security-audit.sh, run chmod +x google-security-audit.sh, and execute it with ./google-security-audit.sh. Each run appends to the log file rather than overwriting it, so over time you build a real audit trail, genuinely useful if you ever need to demonstrate due diligence after an incident, or just want to confirm nothing has quietly drifted since your last review.
Backup Methods Compared: Security Keys vs Authenticator Apps vs Backup Codes
Every setup needs at least one fallback beyond the primary passkey. Here’s how the three main options stack up on the factors that matter most when you’re actually locked out.
| Fallback method | Works without internet | Survives phone loss | Cost | Best for |
|---|---|---|---|---|
| Hardware security key | Yes | Yes (separate object) | $25-$60 one-time | Primary backup for high-value or high-risk accounts |
| Authenticator app (TOTP) | Yes | No, unless backed up separately | Free | Everyday second device coverage |
| Printed backup codes | Yes | Yes (paper, not digital) | Free | Last-resort recovery when everything else fails |
A reasonable minimum setup pairs a phone-based passkey for daily use with one hardware key as a portable backup and a printed set of codes stored somewhere physically separate from both. That combination survives the three most common failure scenarios, lost phone, dead battery with no signal, and a device that’s simply unavailable when you need it, without requiring a second phone or duplicate hardware.
How This Compares to Securing Other Accounts
The same passkey-plus-2SV pattern now applies well beyond Google. Gaming platforms, cloud consoles, and social accounts have converged on nearly identical flows, which means the muscle memory from this guide transfers directly. If you’re locking down a gaming account next, the setup mirrors what we covered for enabling 2FA on Epic Games and Fortnite accounts almost step for step, recovery contact first, then a phishing-resistant second factor, then backup codes. And if remote-access accounts are part of your threat model, the session-hijacking risks described in Step 10 above are the same class of problem we walked through in our guide to hardening Windows RDP against brute-force attacks, different protocol, same underlying principle of not trusting a session just because it was valid five minutes ago.
The pattern holds because the underlying threat hasn’t changed platform to platform: credential theft and session replay are still the two dominant paths into an account in 2026, and phishing-resistant authentication plus active session hygiene is still the most direct answer to both.
Frequently Asked Questions
Do I still need a password if I set up a passkey?
Yes. Google doesn’t let you delete your password entirely as of 2026, since some legacy sign-in flows and account-recovery paths still reference it. But once a passkey is registered, you’ll rarely be prompted for the password during normal sign-in on that device.
What happens if I lose the only device with my passkey?
You fall back to 2-Step Verification, then to backup codes, then to Google’s account recovery flow if all else fails. This is exactly why Step 6 (hardware key backup) and Step 8 (backup codes) matter, without them, losing one device can mean a lengthy recovery process.
Can I use the same passkey across multiple Google Accounts?
No. A passkey is generated per account per authenticator, each Google Account you sign into gets its own distinct passkey, even on the same physical device or security key.
Is a passkey the same thing as Face ID or Touch ID?
Not quite. Face ID and Touch ID are the local unlock mechanism your device uses to confirm it’s really you before releasing the passkey’s cryptographic signature. The biometric data itself never leaves your device or gets sent to Google.
Will turning on 2-Step Verification lock out apps that don’t support it?
Modern apps using OAuth sign-in handle 2SV transparently. Older apps that ask for your raw Google password directly (increasingly rare) may need an app-specific password instead, generated from the Security section.
How often should I redo this security audit?
Every 3 to 6 months for a personal account, or immediately after any major life change, new phone, lost device, or a service you used told you it suffered a data breach. The bash script in this guide is built specifically to make that repeat review fast.
Do passkeys work if I’m signed into Google on a shared or public computer?
Yes, via the cross-device QR sign-in flow from Step 5, you scan the code with your phone rather than registering a passkey on the shared machine itself, which is exactly the behavior you want on a device you don’t control.
Is Google’s Advanced Protection Program overkill for a personal account?
For most users, yes, the standard passkey plus hardware-key-backup setup in this guide covers the realistic threat model. Advanced Protection makes sense specifically for high-risk individuals (journalists, executives, election workers) facing targeted rather than opportunistic attacks.
Does enforcing passkeys across a Google Workspace organization cost extra?
No. Passkeys and 2-Step Verification enforcement are part of the standard Admin console security controls at every Workspace tier, there’s no separate license needed. The only cost is optional hardware security keys if you choose to distribute physical backup keys to staff.
