Google Ads API Now Demands Passkeys for New Refresh Tokens

Anyone who has ever automated a new advertiser onboarding at 4pm on a Friday knows the value of a single OAuth call that just works. That call is about to grow a passkey step. Google is now requiring passkey authentication for any new OAuth 2.0 refresh token generated through the Google Ads API, and the phased rollout has already started.

For platform engineers building on top of Google Ads, this is the kind of quiet API change that doesn't break production on day one, but silently breaks your next client migration two months later. The scope is narrow. The blast radius, if you ignore it, is not.

Key Details

The requirement, as ALM Corp reported, became mandatory on August 5, 2026, with a phased rollout reaching accounts in the weeks after. Any user following the standard OAuth 2.0 flow to mint a new refresh token against the Google Ads API must now authenticate with a passkey instead of a password plus two-step verification code.

The mechanics are straightforward. Passkeys use cryptographic keys, with the private key generated and stored on the user's device. If a user doesn't have a passkey configured, they'll be forced to set one up at authentication time. No passkey, no refresh token.

Two details matter more than the headline change.

First, existing refresh tokens are safe. Tokens created before August 5 keep working. This is not a mass-revocation event. The change bites only when someone spins up a new integration, onboards a new advertiser, or rotates credentials.

Second, there is a seven-day trust delay. A freshly minted passkey is functional but untrusted for the first week. Google explicitly recommends creating passkeys ahead of time to burn down that grace period before you need to authenticate in anger. For agencies onboarding a client with less than a week's runway, that is a scheduling problem dressed up as a security feature.

The scope extends beyond raw API calls. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are all affected. Standard users of Scripts and Looker Studio get pulled in too, not just backend developers. Any integration that connects a Google Ads account to another application will eventually require a passkey.

The one clean exemption: organizations using service accounts. Because service accounts don't use the standard user authentication flow, they sit outside this requirement entirely. That single sentence is the most important line in the announcement for anyone architecting new integrations from scratch.

Why This Matters for Performance Marketing

Every agency I've worked with over the last decade has the same skeleton in the closet: a shared Google account, a refresh token minted years ago by someone who has since left, and a cron job that quietly pulls reports every morning. That token still works. Fine. But the moment you onboard a new client, spin up a new sub-MCC integration, or migrate to a new reporting stack, you're in the new regime.

The operational impact splits three ways. SaaS platforms selling Google Ads management tooling have to rework their onboarding UX. The old "click here, log in with Google, done" flow now includes a passkey provisioning step for users who don't have one. That's not a huge lift, but it is a support burden. Expect a spike in tickets from clients who don't know what a passkey is and can't figure out why their Yubikey isn't working the way their password manager used to.

Agencies onboarding new advertisers face the seven-day trust window as a scheduling constraint. If your standard SLA is "we'll have your campaigns migrated within 48 hours," that promise is now at odds with Google's default posture. My take: agencies should add a passkey-provisioning checklist item to their pre-kickoff paperwork, right next to billing setup and tracking pixel access.

Production incidents I've seen in similar auth migrations follow a predictable pattern. Something works in staging because staging uses long-lived tokens. Then a production token expires or rotates, the re-auth flow hits the new requirement, and reporting silently stops. Nobody notices until a client asks why last Tuesday's numbers are missing. Passkey rollouts are especially prone to this because the failure mode is often "user prompted to set up passkey in a headless context," which just hangs.

The uncomfortable read: if your platform still relies on end-user OAuth for headless integrations, this is Google telling you, politely, to move to service accounts.

Industry Impact

For the broader traffic and performance-marketing stack, this is a nudge, not a shove, toward a more defensible authentication posture. Passkeys are objectively better security than password plus TOTP. The private key never leaves the device, phishing resistance is baked in, and the attack surface for credential stuffing collapses. Nobody sensible is arguing against passkeys as a primitive.

The friction is in the plumbing. Ad-tech vendors, bid managers, feed automation tools, cross-channel reporting platforms, they all built onboarding assuming a human at a browser could complete an OAuth dance in one sitting. The seven-day untrusted window forces a two-phase onboarding: provision credentials now, activate integration later. Teams that treat this as a UX redesign rather than a checkbox will come out ahead.

There's also a knock-on effect for the BI layer. If your marketing analytics pipeline uses BigQuery Data Transfer Service to sync Google Ads data, and someone recreates that transfer under a new account, they'll hit the passkey requirement. Looker Studio dashboards owned by individuals rather than service accounts are in the same boat. Expect finance and analytics teams to file confused tickets over the next quarter.

The strategic signal is clear: Google is standardizing on passkeys across its developer surface, and the Ads API is a large early domino. Teams that have been putting off a proper secrets-management review, service-account migration, or auth-provider consolidation now have a forcing function. That's healthy. Painful, but healthy.

Worth noting for those juggling multi-platform stacks: Meta's Marketing API has its own auth model with system users that sidesteps this class of problem, and it's a reasonable reference point for how service-account-style patterns hold up operationally.

What to Watch

Three signals will tell you how bumpy the next quarter gets.

Watch for SaaS vendors quietly updating their onboarding docs with passkey instructions. The vendors that ship clean guidance within the first month of the phased rollout are the ones that have engineering discipline. The ones still shipping "log in with your Google password" screenshots in November are the ones you should ask hard questions about.

Watch your own token rotation calendar. If you have any refresh tokens on scheduled rotation, verify whether the rotation triggers a new token grant or reuses the existing one. Rotation policies written for the pre-August 5 world may now inadvertently pull you into the passkey flow at the worst possible moment.

Watch for a migration wave to service accounts. Google has effectively priced end-user OAuth higher, in operational terms, than service account auth for headless workloads. Any team still using a human account to run backend Ads API jobs should have "migrate to service account" on the roadmap by end of quarter. Not because the sky is falling, but because the alternative is explaining to your CTO why reporting broke over a passkey trust window during a client demo.

Key Takeaways

• New tokens only: Existing OAuth refresh tokens minted before August 5, 2026 continue to work. Panic is not the response, planning is.
• Seven-day trust delay is a scheduling problem: Provision passkeys at least a week before you need to onboard a new advertiser or integration.
• Service accounts are the escape hatch: Headless workloads should migrate off end-user OAuth. Google gave you a reason; take it.
• Onboarding UX needs a rewrite: SaaS platforms managing Google Ads accounts on behalf of clients must add passkey provisioning to their flow and support docs.
• Scope is wider than the API: Google Ads Editor, Scripts, BigQuery Data Transfer, and Looker Studio integrations all fall under the same requirement. Audit every surface, not just the obvious one.