Google is making passkeys mandatory for users generating new OAuth 2.0 refresh tokens through the Google Ads API, part of a broader push to strengthen account security across Google Ads.
The rollout begins on 5 August and will expand to all users over the following weeks.
What's new
Users following the Google Ads API's user authentication workflow will be required to authenticate with a passkey when generating new OAuth 2.0 refresh tokens.
| Item | Detail |
|---|
| Authentication | Passkeys replace password-only authentication and traditional two-factor methods such as SMS codes and TOTP for this workflow |
| Users without a passkey | Prompted to create one during authentication |
| Existing OAuth refresh tokens | Continue to work and won't require reauthorisation |
| A newly created passkey | May be subject to a seven-day security delay before becoming fully trusted |
Google recommends creating a passkey ahead of time to avoid delays when new authentication is required.
Why we care
While most advertisers won't notice the change, developers, agencies and SaaS platforms that generate OAuth refresh tokens for Google Ads users will need to prepare.
Teams onboarding new users after the rollout should account for the passkey requirement — and the potential seven-day trust period — to avoid unexpected delays.
Applications using service accounts for automated workflows are not affected.
Also affected
The passkey requirement extends to other Google Ads products that rely on the Google Ads API:
| Product |
|---|
| Google Ads Editor |
| Google Ads Scripts |
| BigQuery Data Transfer Service |
| Looker Studio |
Users accessing these tools without a passkey will be prompted to create one.
Bottom line
Starting in August, passkeys become the standard authentication method for generating new Google Ads API refresh tokens. Existing integrations will continue working, but developers should prepare new users for the updated sign-in process before the rollout begins.
Practical takeaways
The seven-day delay is the real risk here. More than the feature itself, the time before a new passkey is fully trusted is what disrupts schedules — have any client scheduled for onboarding create a passkey now.
Leave existing tokens alone. Reauthorisation is explicitly not required; pre-emptively regenerating tokens risks running into the seven-day delay.
Check exposure beyond the API. Editor, Scripts, BigQuery Data Transfer and Looker Studio are all caught — if reporting automation runs through Looker Studio, that is in scope too.
Identify where service accounts are used. Automated workflows on service accounts are unaffected, so listing which integrations are user-auth and which are service accounts narrows the work.
Agencies should prepare client communication. Advertisers themselves notice nothing until a new account connection suddenly blocks — advance notice reduces support load.
Read it with security and policy converging on the account UI. Certification applications moving into the account appear in Google Moves Certification Applications Into Google Ads Accounts, and API feature changes in Google Ads API v25. Bundling the API upgrade and the authentication change into one development window is more efficient.