If you store passwords in Google Password Manager and have started creating passkeys, you have probably noticed that the old workflow of copying a login into a browser pop-up is quietly disappearing. That shift is good for security, but it has also created a new kind of confusion. Where do your passkeys actually live? What happens when a malicious extension or a compromised device gets access to your browser profile? And what should you check before you trust the system with your accounts?
The short answer is that passkeys are dramatically harder to phish than passwords, but they are not magic. The real risk is rarely the cryptography itself. It is the surrounding environment: the browser, the extensions you have installed, the sync settings, and the recovery paths you forgot about. Security researchers have repeatedly shown that attackers prefer the easiest route, and for most people that route runs through a poisoned extension or a session that was never signed out.
This article walks through the passkey security risks that matter in 2026, explains how Google Password Manager handles passkey storage, and gives you a concrete audit you can finish in under 30 minutes. We will look at a worked example with real numbers, compare where passkeys can live, and close with a checklist and FAQ. If you are also thinking about what to delete after switching to passkeys, our guide on passkeys vs. passwords: what to do before you delete your logins covers that decision in detail.
Key Takeaways
- Passkeys resist phishing because they are bound to the legitimate domain, but they inherit the security of the browser and device that hold them.
- The most common passkey-adjacent attack is a malicious or over-permissioned browser extension, not a broken passkey protocol.
- Google Password Manager syncs passkeys across signed-in devices, so a compromised Google account or device has a wider blast radius than a single laptop.
- Audit your installed extensions, active sessions, and account recovery methods before trusting passkeys as your only sign-in method.
- Keep at least one non-passkey recovery path (such as a hardware security key or a recovery code stored offline) for critical accounts.
- Revoke sessions and remove unknown devices from your Google account on a regular schedule, not only after an incident.
What Are Passkeys and Why Do They Resist Phishing?
A passkey is a cryptographic credential, built on the WebAuthn and FIDO2 standards, that replaces a password with a public and private key pair. The private key never leaves the device or password manager that created it. The public key is registered with the website. When you sign in, the service sends a challenge, your device signs it with the private key, and the service verifies the signature.
Two properties make passkeys strong against the most common attacks. First, there is no secret you can type into a fake page. A phishing site cannot capture a passkey because there is nothing to capture; the signature is only valid for the exact origin that registered it. Second, there is no shared secret stored on the server that can be leaked in a breach and reused elsewhere.
Those properties are real, but they describe the protocol, not your whole setup. A passkey still has to be stored somewhere, unlocked by something, and synced to other devices. Every one of those steps is a place where risk can enter.
Where the Risk Actually Lives
- The browser session. If an attacker can run code inside a logged-in browser profile, they can often trigger a passkey prompt on your behalf or read data the page exposes.
- Browser extensions. An extension with broad "read and change data on all websites" permission can observe pages and interact with the DOM. This is the single biggest practical risk we see.
- Sync and cloud accounts. Passkeys synced through a cloud provider are protected by that account. Compromise the account, and you may gain access to the passkeys.
- Recovery paths. If an attacker can reset your Google account using a phone number, a backup email, or a support request, the strength of the passkey is irrelevant.
- Malware on the device. Infostealers that read browser storage, clipboard contents, or keylogged input can undermine the surrounding workflow even if the protocol holds.
How Does Google Password Manager Store Passkeys?
Google Password Manager stores passwords, passkeys, and payment details inside your Google account and syncs them to devices where you are signed in with Chrome or on Android. When you create a passkey for a site, Chrome or Android generates the key pair, keeps the private key in the password manager's encrypted store, and syncs it so you can sign in on another device.
This design is convenient, and for most users the protection is sound. The sync is end-to-end encrypted for many credential types, which means Google cannot read the contents directly. But the practical security boundary is still your Google account and the devices that can unlock it. A weak account password, a missing second factor, or a stale signed-in laptop can all matter more than the passkey format.
There is also a platform distinction worth understanding. Passkeys can be stored in a platform authenticator (Windows Hello, Touch ID, Android's built-in manager), in Google Password Manager, or on a physical security key. Each choice trades convenience against the exposure surface.
Passkey Storage Options Compared
Before you decide how much to trust Google Password Manager for passkeys, compare the realistic options. The table below is a practical comparison, not a lab benchmark.
| Storage option | Phishing resistance | Cross-device sync | Exposure if account is compromised | Recovery difficulty | Best for |
|---|---|---|---|---|---|
| Google Password Manager | High | Yes, automatic | High (account-wide) | Low | Everyday accounts, mixed devices |
| Platform authenticator (Windows Hello, Touch ID) | High | Limited to same ecosystem | Medium (device-bound) | Medium | Single-device users in one ecosystem |
| Third-party password manager with passkey support | High | Yes, vault-based | Medium (vault master password) | Medium | Users who want independent control |
| Hardware security key (FIDO2) | Very high | No, physical key | Low (requires physical possession) | High if lost without backup | Admin accounts, high-value logins |
| Passwords only, no passkeys | Low to medium | Yes | High (reusable secret) | Low | Legacy sites that lack passkey support |
The pattern is clear. Hardware keys give the strongest isolation but cost you convenience. Google Password Manager gives the smoothest experience but concentrates risk in one account. For most people the right answer is a mix: synced passkeys for everyday services, and a hardware key or stricter setup for the accounts that would hurt most if lost.
A Worked Example: How Much Exposure Does One Account Carry?
Consider a realistic scenario. Suppose you have 47 saved credentials across 12 services, of which 19 now have passkeys and 28 are still passwords. Your Google account is the root of trust for all of them. The 19 passkeys sync to your laptop, your phone, and a work tablet.
Now imagine you installed a shopping-coupon extension two years ago and never checked its permissions. It has "read and change all data on all websites." An update pushes code that begins injecting scripts into pages you visit. In that scenario, the attacker does not need to break a passkey. They can wait for you to sign in, observe the session, and abuse the logged-in state.
Work through the numbers. If the extension reaches 5 of your 12 services, and 3 of those use passkeys while 2 still use passwords, the passwords are exposed to direct capture and the passkeys are exposed to session abuse. Your effective exposure is 5 of 12 services, not zero, even though you did nothing "wrong" with passkeys.
Now apply the fix. Remove the extension, sign out of all sessions it could have touched, rotate the two password-based accounts, and confirm that the three passkey accounts still require a fresh authentication for sensitive actions. The whole exercise takes roughly 20 minutes and shrinks the exposure from 5 services to zero known paths. That is the kind of concrete outcome a passkey audit should produce.
How to Audit Your Passkey Setup in 30 Minutes
The steps below assume you use Chrome with a Google account. Follow them in order. Each one closes a specific gap.
- Open your Google Account security page. Go to myaccount.google.com and select the Security section. Confirm 2-Step Verification is on, and prefer a passkey or security key over SMS codes if the option is offered.
- Review recovery options. Under account recovery, check the recovery phone number and recovery email. Remove any number you no longer control. A stale recovery number is one of the most common takeover routes.
- Check your devices and sessions. In the same Security section, open "Your devices" and "Manage all devices." Sign out any device you do not recognize or no longer use. Note how many devices can sync your passkeys.
- Inspect Chrome extensions. Type
chrome://extensionsin the address bar. For each extension, click "Details" and read the site access setting. Anything set to "on all sites" that you do not actively need should be removed or restricted. - Remove unused extensions. Delete any extension you have not used in the last 90 days. Fewer extensions means fewer code paths that can touch your sessions.
- Review your saved passkeys. In Chrome, go to Settings, then Autofill and passwords, then Google Password Manager. Open the passkeys list and look for sites you no longer use. Delete those credentials.
- Check for the sites still on passwords. In the same manager, filter for passwords on sites that offer passkeys. Create passkeys for your most important accounts, then remove the old passwords once you have confirmed sign-in works.
- Verify a backup sign-in method. Before deleting any old password, confirm you can still sign in using a second device or a recovery code. Store recovery codes offline.
- Run a malware scan. Use a reputable scanner to check the device. An infostealer is a bigger threat to saved browser data than any single extension.
- Set a recurring reminder. Repeat steps 3 and 4 every quarter. Passkey risk changes as you install new software.
If you want a broader framework for judging extensions, our piece on browser extension permissions explained breaks down which permission grants deserve scrutiny. For extensions that redir
