A passkey is a pair of cryptographic keys created on a device and locked to a single website or application. The private key stays inside the device, or inside the credential manager that syncs it. The public key sits on the server. Signing in means the device signs a random challenge from that server, after its holder unlocks it with a fingerprint, a face scan or a screen-lock PIN. No shared secret travels across the wire, which is the entire point.

Passwords fail because they are shared secrets. Anything typed into a real login form can be typed into a convincing fake, and the same weakness extends to the second factors bolted on top: a code from an SMS message or an authenticator app can be read aloud to a caller or relayed by a proxy site. Passkeys close that gap by making the credential unusable anywhere except the domain it was created for.

How the credential works

Two ceremonies define the standard. Registration begins when a site calls navigator.credentials.create(). The authenticator generates a key pair scoped to a Relying Party Identifier, or RP ID, which is the site's domain, then returns a credential ID, the public key and optionally an attestation statement describing the hardware. Credential IDs run to a maximum of 1,023 bytes and carry at least 100 bits of entropy. The server stores a credential record: identifier, public key, signature counter and backup flags.

Authentication runs through navigator.credentials.get(). The server issues a challenge; the client assembles a JSON structure holding that challenge, the origin and the ceremony type; the authenticator signs it after verifying the user; the server checks the signature against the stored public key. Absent any stated preference, the specification defaults to ES256 and RS256, listed in the COSE registry as -7 and -257.

Domain binding is what makes the scheme phishing-resistant. A credential created for google.com cannot be invoked by a lookalike domain, because the browser passes the RP ID to the authenticator on every operation and the authenticator refuses any mismatch. Google's developer documentation reduces the properties to three: domain-bound, device-bound, and carrying no interceptable secret.

Two flavors exist. A backup-eligible credential, the synced passkey, is copied by its provider into a credential manager and reappears on other devices signed into the same account. A single-device credential, the device-bound passkey, never leaves the hardware that made it, which is how FIDO2 security keys behave. Authenticator data carries a backup eligibility flag fixed at creation and a backup state flag that changes over time, letting a server tell the two apart.

When the passkey sits on a phone and the action happens on a laptop, the browser shows a QR code. Scanning it opens a Bluetooth Low Energy channel that works as a proximity check rather than a data pipe, with Google's Ads documentation putting the range at 1 to 2 meters.

From U2F to Level 3

The FIDO Alliance was formed in 2012 and launched publicly in February 2013, aiming to reduce reliance on passwords. Its early work produced Universal 2nd Factor, the protocol behind the first USB security keys. FIDO submitted its web API to the World Wide Web Consortium in November 2015, and the Client to Authenticator Protocol 2.0 followed in September 2017. Web Authentication became a W3C Recommendation on March 4, 2019, with Level 2 following on April 8, 2021.

The consumer breakthrough came later. A March 2022 FIDO white paper described multi-device credentials, designed to survive the loss of a device. On May 5, 2022, Apple, Google and Microsoft jointly committed to supporting them, and the word passkey entered general use as the consumer-facing name. FIDO later widened it to cover any passwordless FIDO credential, including device-bound ones.

Web Authentication Level 3 became a W3C Recommendation on August 25, 2026, having been a Candidate Recommendation snapshot since May 26. It adds no phishing resistance, which Level 2 already delivered. It formalizes what implementers built in the interim: capability detection, JSON helpers, signal methods telling a credential manager which credentials a site no longer recognizes, and credentials usable across related origins.

How passkeys entered the ad stack

Google folded passkeys into Google Ads through a sequence of deadlines, not one launch. The security insights dashboard and passkeys were announced together on April 21, 2026, inside a set of Ads Advisor safety features. The same date marks the point at which the Google Ads API began requiring 2-step verification for new refresh tokens.

On May 13, 2026, version 24.1 of the API added a boolean field named passkey_enabled, letting integrations check enrollment state before attempting an operation that would fail. Later that month Google emailed advertisers about a July 15, 2026 requirement covering account linking updates and user access changes. Version 24.2, released June 24, exposed multi-party approvals at the API level, addressing the same threat surface through workflow rather than credentials.

The developer deadline came next. Google announced on July 27 that from August 5, 2026 a passkey would be required to generate new OAuth 2.0 refresh tokens through the API user authentication workflow, rolling out to all users over subsequent weeks. Password-only sign-in is refused for that step, as are TOTP and SMS codes. Existing refresh tokens keep working, and service account workflows sit outside the requirement. Downstream products riding the same API are affected: Google Ads Editor, Ads scripts, BigQuery Data Transfer Service and Data Studio.

Setup requirements are narrow. One eligible device covers an entire account. Google's minimums are Windows 10, macOS Ventura, ChromeOS 109, Android 9.0 and iOS 16, plus any FIDO2 security key, with Chrome 109, Safari 16, Edge 109 and Firefox 122 on the browser side. Private browsing blocks enrollment. A passkey status column under Access and security lets administrators audit adoption across a full account hierarchy.

Why it matters for advertisers

A passkey cannot be shared, and Google's help documentation treats that as deliberate rather than incidental. Asked whether the limitation is technical, the documentation says it is not, calling shared identities an accountability gap. The recommended fix is for agencies to invite each employee under an individual address.

That collides with how much of the industry operates. Shared logins, contractor access and long-dormant permissions are common, and the consequences are documented. A former agency wiped a client's Merchant Center account by closing its own, six years after the relationship ended, because super admin privileges had never been removed. In April 2026, agencies reported fabricated client inquiries built to reach accounts through the linking process rather than through email.

Google has narrowed the same perimeter from several directions. Administrators gained the ability to require business email addresses instead of personal ones in 2024. A second-administrator approval requirement arrived in July 2026, leaving solo administrators unable to complete some changes alone. A pilot now blocks free email domains from sensitive actions entirely. Passkeys are the credential-layer component of that program.

Frictions and disputes

Google's documentation does not agree with itself on how long a new passkey takes to become usable. One page says roughly one to two days to pair with Ads, a troubleshooting entry advises waiting 48 hours, and both the FAQ and the API security guide cite a seven-day delay. Agencies rotating staff face the sharpest version: a new hire enrolling on the day access is needed may find the credential inert.

Coverage gaps persist. Passkeys generated automatically on Android cannot verify sensitive Google Ads actions, and Android browsers cannot complete those challenges at all. Enterprise single sign-on does not substitute: Google requires its own passkey regardless of an Okta deployment.

Terminology remains contested. The WebAuthn specification lists passkey as a deprecated synonym for a client-side discoverable credential. The FIDO Alliance applies the word to any passwordless FIDO credential, including device-bound keys that are not discoverable. Both meanings circulate.

Portability was the longest-running criticism, since passkeys made in one ecosystem were stranded there. FIDO's Credential Exchange Format reached review draft in March 2025, and Google began rolling out import and export between Google Password Manager and third-party managers on Android in June 2026.

Adoption is broad but incomplete. The FIDO Alliance estimated 5 billion passkeys in use on May 7, 2026, drawing on a Sapio Research study across ten countries. Awareness reached 90 percent and 75 percent had enabled a passkey somewhere, but only 49 percent used them regularly where offered. Recovery remains the residual weakness: a help desk that resets a lost passkey reintroduces the human step the credential was meant to remove.

Distinguishing passkeys from adjacent terms

2-step verification adds a second factor to a password. A passkey replaces the password rather than supplementing it, satisfying possession and knowledge in one step.

Security key describes hardware. A FIDO2 key holds device-bound passkeys, but a passkey needs no dedicated hardware.

Single sign-on federates identity across applications. It governs which systems a person can reach; a passkey governs how identity is proved at the door.

OAuth refresh token is an authorization artifact letting software act on an account. The passkey requirement governs the moment a token is minted, not its use afterwards.

Recent developments

Two changes landed on August 25, 2026. WebAuthn Level 3 became a W3C Recommendation, while WhatsApp disclosed that more than a billion accounts have set up a passkey while replacing its six-digit two-step verification PIN with an alphanumeric password.

Standards work is moving toward machines. The FIDO Alliance formed two working groups in May 2026 covering AI agent authentication and agentic payments. Agent access to ad accounts still runs on OAuth: Meta's ads MCP server authenticates through Facebook Login for Business, with no passkey in the path.

Timeline

  • 2012: FIDO Alliance formed; public launch follows in February 2013
  • November 2015: FIDO submits its web API specification to the W3C
  • May 2016: First Working Draft of Web Authentication published
  • September 2017: Client to Authenticator Protocol 2.0 published
  • April 2018: WebAuthn advances to Candidate Recommendation
  • March 4, 2019: WebAuthn Level 1 becomes a W3C Recommendation
  • April 8, 2021: WebAuthn Level 2 becomes a W3C Recommendation
  • March 2022: FIDO white paper describes multi-device credentials
  • May 5, 2022: Apple, Google and Microsoft commit to passkey support
  • March 2025: Credential Exchange Format reaches review draft
  • January 13, 2026: WebAuthn Level 3 published as a Candidate Recommendation snapshot
  • April 21, 2026: Google Ads API begins requiring 2-step verification
  • May 7, 2026: FIDO Alliance estimates 5 billion passkeys in use
  • May 13, 2026: Google Ads API v24.1 adds the passkey_enabled field
  • May 26, 2026: Second Candidate Recommendation snapshot of Level 3
  • June 2026: Google begins rolling out passkey import and export on Android
  • July 15, 2026: Google Ads requires passkeys for sensitive account actions
  • July 20, 2026: W3C proposes advancing Level 3 to Recommendation
  • July 27, 2026: Google announces the Google Ads API passkey requirement
  • August 5, 2026: Passkeys required for new Google Ads API refresh tokens
  • August 25, 2026: WebAuthn Level 3 becomes a W3C Recommendation

Summary

Who: The FIDO Alliance and the W3C Web Authentication Working Group define the standard. Apple, Google and Microsoft implement it in platforms. In advertising, Google Ads advertisers, agency staff and API developers are the affected population.

What: A passkey is a public and private key pair created on a device, scoped to one domain, and unlocked by biometrics or a screen-lock PIN. It replaces the password and displaces SMS and TOTP second factors for the workflows where it is enforced.

When: The concept was named in March 2022 and backed by the major platforms on May 5, 2022. Google Ads began requiring passkeys for sensitive account actions on July 15, 2026, and for new API refresh tokens from August 5, 2026. WebAuthn Level 3 became a W3C Recommendation on August 25, 2026.

Where: Inside Google Ads account settings, the Google Ads API user authentication workflow, and any downstream product built on that API, including Google Ads Editor, Ads scripts, BigQuery Data Transfer Service and Data Studio.

Why: Passwords and relayed one-time codes can be phished. Passkeys cannot, because the credential is bound to a domain and never leaves the device. For advertising specifically, the requirement forces a move away from shared agency logins toward individually held credentials, closing an access route that account hijacking campaigns have exploited.