Google Ads API will require passkeys for new OAuth tokens starting 5 August

The Google Ads API will start requiring passkeys when users generate new OAuth 2.0 refresh tokens. The rollout begins on 5 August 2026 and reaches all users over the following weeks. Password-only sign-in will not be accepted for that workflow, and neither will 2FA methods such as TOTP authenticator apps or SMS codes. Google announced it on the Google Ads Developer Blog on 27 July 2026.

Existing OAuth refresh tokens keep working. Nobody gets a reauthorization prompt for a connection that is already live. The requirement applies to new tokens, which means the moment it bites is the moment you connect something new. The announcement is on the Google Ads Developer Blog.

What changes on 5 August

A user generating a new OAuth 2.0 refresh token for the Google Ads API will be challenged for a passkey. A password plus an authenticator code will not clear that challenge. The rollout starts on 5 August and expands to all users over the weeks after.

Google also says the products built on top of the Google Ads API will require passkey-based authentication: Google Ads Editor, Google Ads scripts, BigQuery Data Transfer Service and Data Studio. That list is what turns a developer-blog post into an agency operations problem, because those are the tools account managers touch, not just engineers.

The seven-day trust delay is the part that will hurt

Google warns that a 7-day security delay may apply before a newly created passkey becomes trusted. Enrolling a passkey on the morning you need it may not be enough.

Work backwards from that and the deadline is not 5 August. It is now. A client onboarding scheduled for mid-August, a reporting reconnection after a token expires, an agency taking over an account: each of those can stall for a week if the passkey does not exist yet. The failure will not look like a policy block either. It will look like a login that will not complete, on a day when someone is waiting for a dashboard.

Service accounts are not affected

Service account workflows sit outside this requirement, and Google explicitly recommends them for automated or offline applications. If you run scheduled reporting, a bulk upload job or any unattended integration on a personal OAuth token, this is the nudge to move it.

That was already the better design. A pipeline tied to one person's Google account breaks when that person leaves, changes their security settings, or takes leave during month-end. Tying it to a service account removes a category of outage that has nothing to do with passkeys.

What to check in your own setup

• Which integrations authenticate through a personal OAuth token rather than a service account.
• Whose Google account each of those tokens belongs to, including people who have left.
• Whether the people who onboard new client accounts have passkeys enrolled today.
• Which reporting connections you expect to rebuild in August and September.
• Whether anyone still relies on SMS codes as their second factor for the accounts that touch the API.

The list of affected products is worth reading against your actual reporting stack rather than in the abstract. A Looker Studio connection or a BigQuery transfer that has run untouched for a year is exactly the thing nobody thinks about until it needs reauthorizing. Teams whose measurement and reporting setup spans several data sources should map every Google Ads connection they own before August.

What this means for Thai marketers

Any agency or in-house team in Thailand that expects to reconnect Looker Studio, Google Ads scripts or a third-party reporting tool after 5 August should create passkeys now rather than discover the block during a month-end reporting crunch. The seven-day trust delay does not care that a client report is due Friday.

Passkey support on the devices most Thai teams already use is not the obstacle. Habit is. Accounts here still lean heavily on SMS one-time codes as the second factor, and SMS is specifically not accepted for this workflow. An account manager who has never enrolled a passkey and needs to connect a new client account in the second week of August is the scenario to prevent, and the prevention takes about five minutes per person.

Common questions

Will my existing connections break on 5 August?

No. Existing OAuth refresh tokens keep working, with no reauthorization prompt.

Does this apply to service accounts?

No. Service account workflows are not affected, and Google recommends them for automated or offline applications.

Can I keep using an authenticator app?

Not for generating new OAuth refresh tokens for the Google Ads API. TOTP apps and SMS codes are disallowed for that workflow.

Does Google Ads Editor need a passkey too?

Google says products that use the Google Ads API, including Editor, scripts, BigQuery Data Transfer Service and Data Studio, will require passkey-based authentication.

Do this before August

Enrol passkeys for everyone who authenticates a Google Ads connection, and start with whoever handles new account access. Then move any unattended job off a personal token and onto a service account. If you would rather hand the whole audit over, our Google Ads team can inventory your account connections and reporting integrations before the rollout reaches you.