Are PassKey Browser Extensions a Security Risk?

Are PassKey Browser Extensions a Security Risk?

Yes. A specific class of browser extension can register a PassKey for any domain without a user's explicit intent, bypassing phishing resistance entirely. Security teams need to understand the mechanism and what they can do about it.

What PassKeys Are and Why They Were Built

PassKeys are a password replacement built on the FIDO2 standard. The core promise is phishing resistance: a PassKey credential is bound to the originating domain, so a credential created for google.com cannot be used on a fake googIe.com site. That binding is what makes PassKeys harder to steal than passwords, which can be typed into any site that asks for them.

The PassKey model split into two rollout paths. Device-native PassKeys (stored in Apple Keychain, Google Password Manager, or Windows Hello) store credentials in the operating system's secure enclave. Browser extension PassKeys store credentials in, well, browser extensions. Both paths use the same underlying WebAuthn protocol. The security properties are supposed to be the same.

They are not.

How PassKey Registration Works in Extensions

When you register a PassKey on a site, your browser creates a public-private key pair. The private key stays with the authenticator. The public key goes to the website. On subsequent logins, the website sends a challenge, the authenticator signs it with the private key, and the website verifies the signature using the public key.

In the browser extension model, the extension acts as the authenticator. It handles the key generation and signing. When you grant an extension permission to "create PassKeys," it can call the WebAuthn registration function for any domain you visit.

This is where the vulnerability lives.

The Vulnerability: Extensions Can Register PassKeys for Any Domain

WebAuthn registration requires a calling origin. In normal browser behavior, that origin is the domain of the page triggering registration. But a browser extension with the right permissions can call navigator.credentials.create() with any origin it chooses.

A rogue or compromised extension can therefore:
1. Register a PassKey for google.com while you are on example.com
2. The PassKey is now associated with your Google account in the extension's storage
3. On your next visit to Google, the extension silently supplies the maliciously registered credential
4. Google accepts it because the credential looks legitimate

No phishing required. No credential theft. The attacker registered a key for the real domain before the victim ever logged in.

This is not theoretical. Security researchers documented this attack class in PassKey registration flows, and MSP practitioners flagged it as an active concern in community discussions.

Why Email Authentication Does Not Stop This

DMARC, SPF, and DKIM protect email sending domains from being spoofed. They verify that a mail server is authorized to send from a particular domain. None of them touch web authentication flows.

A PassKey registered via a rogue browser extension is a legitimate credential on the real domain. Email authentication standards have no visibility into web authentication events, and vice versa.

This means organizations that have invested heavily in email authentication still have an unaddressed attack surface in their web authentication infrastructure. These are separate threat models requiring separate controls.

What Security Teams Should Do Now

1. Audit installed PassKey browser extensions.
List every browser extension with permission to create PassKeys or manage credentials. In Chrome, check at chrome://extensions. In Firefox, check the extensions panel. Flag any extension you did not intentionally install for this purpose.

2. Review actual permissions granted.
Many PassKey-capable extensions were installed for password management and later gained PassKey support. "Read and change data on all sites" covers more than most users realize.

3. Prefer device-native credential storage.
PassKeys in Apple Keychain, Google Password Manager, or Windows Hello have a different trust model. They cannot silently register credentials for arbitrary domains from a browser extension context. Where possible, use device-native PassKeys over browser extension PassKeys.

4. Restrict extension permissions.
If your organization uses a PassKey browser extension, set it to ask before registering credentials rather than allowing it automatically. Some extensions support this granular permission model.

5. Monitor vendor updates.
Browser vendors and FIDO2 implementers are aware of the registration-phase risk. Proposed mitigations are expected in upcoming WebAuthn revisions. Track FIDO Alliance announcements for updates.

Standards Status

The WebAuthn specification does not currently restrict extensions from registering credentials for arbitrary origins. This is a known gap. The FIDO Alliance has discussed registration-phase hardening as a priority for the next revision of the FIDO2 standard, but no final specification or timeline is settled.

Browser vendors have taken independent approaches. Some have added friction to cross-origin registration calls, but full prevention is not in place at the time of writing.

The practical risk remains. Organizations that rely on PassKeys for authentication should treat the extension permission model as an area requiring active monitoring.

Bottom Line

PassKey browser extensions can register credentials for any domain without the user's full awareness. This creates an account takeover path that does not rely on phishing, credential theft, or any of the attacks that PassKeys were specifically designed to stop.

The risk is real, the attack is silent, and current browser extension permission models do not fully prevent it. Security teams should audit their installed base, prefer device-native credential storage where possible, and watch for standards-level fixes from the FIDO Alliance.