Google Ads API passkey requirement changes how teams mint new OAuth refresh tokens. Prepare administrator verification, 2-step verification, and passkey enrollment before authorization fails.
Google Ads API Passkey Requirement: Why New OAuth Refresh Tokens Are Suddenly Blocked
An integration that has worked for months suddenly can't authorize a new client account. The OAuth flow that used to end in a refresh token now stops with an unfamiliar error, or asks for a form of login the account has never used before. This is not a bug in your code — it is Google Ads API's rolling security update, and it changes how every new refresh token gets generated from 2026 onward.
Google Ads API passkey requirement: what changed
2-Step Verification — enforced since April 21, 2026
- Applies to the user authentication OAuth workflow only
- New refresh tokens cannot be generated for an account without 2SV enabled
- Calls fail with a
TWO_STEP_VERIFICATION_NOT_ENROLLEDauthentication error until 2SV is turned on - Existing refresh tokens keep working — no reauthorization prompt for tokens issued before enforcement
Passkey requirement — rolling out since August 5, 2026
- Enforced users must complete a passkey challenge to generate a new refresh token
- Password-only login and app-based 2FA (TOTP or SMS codes) are no longer accepted for this specific step
- Rolling out account by account over several weeks — not every account is enforced on the same day
- Existing refresh tokens are unaffected by this change too
The 7-day trust delay is what actually breaks launch timelines
A freshly created passkey can take up to 7 days before Google treats it as fully trusted for this workflow. Agencies that wait until a client's token expires — then try to create a passkey and re-authorize the same day — are the ones who get stuck mid-migration or mid-onboarding.
What's Affected and What Isn't
| Scenario | Impact |
|---|---|
| Generating a brand-new OAuth refresh token via the user authentication workflow | Blocked without 2SV + passkey |
| Refresh tokens already issued before enforcement | Unaffected, no reauth prompt |
| Service account workflows (server-to-server, no end-user login) | Outside the requirement entirely |
| Google Ads Editor, Google Ads scripts, BigQuery Data Transfer Service, Data Studio connections built on the API | Same passkey requirement applies |
| Multi-client agency setups with several manager-account logins | Each authorizing account needs its own compliant setup |
Where Agencies and SaaS Integrations Get Stuck
- Onboarding a new client whose Google account has never had 2-step verification enabled, discovered only when the OAuth call fails
- Assuming an authenticator app (TOTP) or SMS code satisfies the requirement — it satisfies 2SV, but not the separate passkey step enforced users now face
- Creating a passkey the same day a token needs to be minted, then hitting failures during the 7-day trust window
- Managing dozens of client refresh tokens under one MCC and discovering the rollout enforces different accounts on different weeks, with no single cutover date to plan around
- Confusing the account-level "passkey to log into Google Ads" feature with the API-specific passkey requirement for minting new OAuth tokens — they are related but not the same setting
- A staging or test environment that re-authorizes frequently, and now needs a compliant device and passkey on every environment that generates fresh tokens
The High-Level Path to a Compliant Re-Authorization
Map every authorizing account
Identify which Google accounts across your client base actually run the user authentication workflow, versus which integrations already use service accounts and sit outside this requirement.
Enable 2-Step Verification first
No new token can be minted at all without it — this has to happen before anything else, on the specific Google account used for authorization.
Register a passkey and wait out the trust delay
Create the passkey early, not on the day a token is needed, so the up-to-7-day trust window has already passed before it's relied on.
Re-run the OAuth consent flow correctly
Generating the new refresh token through the passkey-authenticated flow, without breaking any client accounts still running on valid existing tokens.
Verify and rotate credentials safely
Confirming the new token actually authorizes live API calls before retiring the old one, so a client's reporting or campaign automation never goes dark mid-swap.
Common Mistakes That Cause Repeat Failures
- Waiting until an existing integration breaks instead of proactively auditing which accounts will be enforced next
- Treating this as a one-time fix, when the rollout enforces different accounts on a rolling schedule over several weeks
- Not accounting for the 7-day passkey trust delay when a client launch date is already fixed
- Assuming the fix is the same across every client account, when MCC structures and per-account 2SV status vary widely
- Overlooking that Google Ads Editor, scripts, and BigQuery Data Transfer Service connections built on the same API are affected the same way as direct API calls
Managing this across client accounts adds up fast
The individual fix is simple to describe. Doing it correctly across a real client base — without breaking a working campaign or losing access mid-audit — is where this becomes a project instead of a checkbox. We handle Google OAuth setup and API verification support end to end; see the Google API Verification Service page, and the related breakdown of when a Google OAuth scope triggers Google's verification requirement for the wider picture.
Requirements described here reflect Google's official Google Ads API "Security requirements" documentation (2-step verification and passkey sections), reviewed August 2026. Google enforces its own rollout schedule and this cannot be promised or predicted for any individual account. This page provides general technical information only, is not official Google documentation, and singhamandeep.com is not affiliated with or endorsed by Google LLC.
Check Google's official Google Ads API OAuth documentation before changing the authorization flow.
The Google Ads API passkey requirement affects new refresh-token issuance, not every existing token at the same moment.
For the Google Ads API passkey requirement, verify the administrator account, 2-step verification, and passkey enrollment before requesting consent.
A reliable Google Ads API passkey requirement rollout separates developer-console settings from the Google account security checks that authorize users.
Test the Google Ads API passkey requirement with a new OAuth flow and record the exact error returned when security prerequisites are missing.
Document Google Ads API passkey requirement steps for agencies so onboarding does not depend on one administrator's device.
Pair Google Ads API passkey requirement planning with token rotation and secure credential storage before production migration.
Need Us to Get Your Google / YouTube API 100% Approved?
Stop losing weeks to OAuth verification back-and-forth and quota audits. With 500+ apps approved, we handle your entire submission from start to finish. You get 100% Approval or a 100% Refund — and for your complete safety, you can hire us directly through Upwork or Fiverr Escrow (or use the WhatsApp / Calendar buttons in the header & footer).
Chat on WhatsAppFrequently Asked Questions about Google Ads API access
Why do Google Ads API access requests get rejected?
Common reasons are a developer token application that doesn't clearly describe the tool, a website that doesn't match the application, missing design documentation, and OAuth setup issues that stop the app from working reliably.
How long does it take if you handle it?
It usually takes ~2–3 days for preparation and submission, followed by the platform's review queue — typically 7–15 days (often faster on platforms like X, or longer depending on platform review volume and any follow-up rounds).
What if it still isn't approved?
We work on a 100% Approval or 100% Refund basis: if we can't get your valid use case approved, you get a full refund.
Is it safe to hire you?
Yes. You can hire us through Upwork or Fiverr, so your payment stays in Escrow and is only released when the work is delivered. We've been doing this for 10+ years, with 500+ apps approved and 10,000+ permissions granted.