July 27, 2026 • Search Engine Land
Google will require a passkey before it issues a new OAuth 2.0 refresh token for the Google Ads API starting August 5, according to Search Engine Land. The change is framed as an account security measure. Refresh tokens that already exist are unaffected, so the requirement lands on new authorizations rather than on integrations that are already running.
Key takeaways
- From August 5, generating a new OAuth 2.0 refresh token for the Google Ads API requires a passkey on the authenticating Google Account.
- Existing refresh tokens are unaffected and keep working.
- Anyone authenticating for the first time — or re-authenticating — needs a passkey in place first to avoid an interruption.
- A newly created passkey may carry a seven-day trust period, which makes this a task to finish before the deadline rather than at the point of failure.
- Developers, agencies, and SaaS platforms connecting to Google Ads accounts carry the practical work.
What changes on August 5
The Google Ads API adds a passkey requirement to the step where a new OAuth 2.0 refresh token is issued. A passkey is a device-bound credential — a fingerprint, face unlock, screen lock, or hardware security key — that stands in for a password at sign-in. From August 5, the Google Account being used to authorize API access needs one before that token can be generated.
For anyone running Google Ads campaigns through the web interface alone, nothing changes. The requirement applies to programmatic access, not to logging in and managing campaigns by hand.
What is not changing
Existing refresh tokens are unaffected. An integration holding a valid token keeps calling the API on the credential it already has. That single detail is why this reads as a quiet change for most accounts and a hard deadline for a specific few.
It also carries a warning worth stating plainly: a working token is worth protecting. Revoking or resetting one before a passkey is in place creates exactly the outage the deadline was meant to prevent.
Where the friction actually sits
The friction is on new authorizations. That covers a new client being onboarded, a new tool being connected, a developer setting up a fresh environment, and any existing connection that has to be re-authorized because a token was revoked or access was reset.
In each of those cases the passkey has to exist on the authenticating account before the authorization flow will complete. Notably, that account is often a developer or service account rather than the business owner’s day-to-day login — which is the part most likely to be checked last.
The seven-day detail
Search Engine Land notes a potential seven-day trust period on newly created passkeys. If that period applies, creating a passkey at the moment authentication fails does not solve the problem that day.
That turns a two-minute setup task into a one-week delay for anyone who leaves it until something breaks. It is the single reason to handle this before August 5 rather than treat it as a problem to debug when it surfaces.
What it means for smaller advertisers
Most small businesses in London, Ontario are not calling the Google Ads API directly. They are, however, usually on the receiving end of something that does — a reporting dashboard, a bid management tool, a connector feeding a spreadsheet, or an agency script.
The failure mode there is quiet. A broken authorization does not post a banner on a dashboard; it shows up as a data pull that stops returning rows, and the chart keeps rendering with whatever it last had. Clean reporting and attribution depends on noticing that gap in days rather than at the end of the month.
The practical version of this for a business owner is one question to whoever manages the account: which tools authenticate to our Google Ads account, and is the passkey set up on whatever account authorizes them?
The ONmetrics Take
This is a small administrative task with an unusually sharp deadline attached, and the seven-day trust period is what makes procrastination expensive.
Start by checking the authenticating account rather than the ad account — the passkey belongs to whichever Google Account authorizes API access, and that is frequently not the login people assume. Then inventory what actually touches the API. Reporting dashboards, bid management tools, connectors, and internal scripts all authenticate somewhere, and the real list is usually longer than the remembered one.
Leave working tokens alone in the meantime. There is no benefit to re-authorizing an integration that is running fine, and doing it before the passkey is ready is the one way to turn a non-event into an outage.
Get a free digital marketing audit and we will check which tools are connected to your Google Ads account, whether your reporting depends on them, and where a broken authorization would go unnoticed.
Source
Original reporting: Search Engine Land — “Google makes passkeys mandatory for Google Ads API users.” https://searchengineland.com/google-makes-passkeys-mandatory-for-google-ads-api-users-483617