Google Ads Passkeys: The API Deadline Already Passed. The Account Deadline Isn't in Writing.
The short version
There are two passkey requirements and only one of them has a date you can verify. Since August 5, 2026, the Google Ads API requires a passkey to generate a new OAuth refresh token, which reaches Google Ads Editor, Ads scripts, BigQuery Data Transfer and every third-party tool that eventually re-authorizes. That one is confirmed on Google's developer blog and is already live. The account-level requirement, a passkey for sensitive actions like user changes and account linking, is widely reported as August 19, but that date is not on any Google page, and Google's own advertiser email said July 15. Either way the same clock runs: Google documents an activation delay of up to seven days, so a key created after August 12 may not work when you need it. High signal if you administer accounts. If every admin is already on a corporate domain with a tested passkey, you are done, close the tab.
What Google announced
The confirmed one. On July 27, 2026, Google announced on the Google Ads developer blog that the Google Ads API would require a passkey to generate new OAuth 2.0 refresh tokens, effective August 5, 2026 and rolling out over the following weeks. Password-only sign-in and 2FA methods such as authenticator apps or SMS codes are not accepted for that workflow. Existing refresh tokens keep working and nobody gets a reauthorization prompt for a live connection. Service accounts are exempt. Per Search Engine Land's coverage, the surfaces affected include Google Ads Editor, Ads scripts, BigQuery Data Transfer Service and Data Studio.
The unconfirmed one. Google's help article "Use a passkey to complete sensitive actions" describes a requirement covering adding a new user, removing an existing user, changing user roles and permissions, account linking updates, linking to a manager account, and editing payment or billing details. What that article does not contain is a date. The advertiser email Google sent in May, reproduced by Search Engine Roundtable, said "Starting July 15." Trade coverage now reports August 19. Both cannot be right, and Google has not published either.
Around those two sit the rest of the access lockdown. Multi-party approval went live on July 27, requiring a second administrator to approve user and permission changes on accounts with more than three admins. A new help doc surfaced on August 6 describing a pilot that blocks free email domains such as @gmail.com from completing sensitive actions. Behind those, the Security Agent for account hygiene shipped in April and a Security Tasks Summary tab appeared in Access and Security on June 17.
What it actually means
Start with the date, because the reporting has gone sloppy and you are entitled to know what is actually established. Google's May email said July 15. That date passed without the requirement landing for most advertisers. The August 19 date now circulating traces back to trade write-ups, not to a Google page, and the passkey help article still names no date at all. So the honest statement is this: the account-level requirement is real, its date has already moved once, and Google will not put the new one in writing. Do not calendar this off a blog post, this one included. Open your account and read the notification Google shows you, because Google's own doc says you get an email and an in-product notice when the requirement applies to your account. That notice is the only date that governs you.
Now the arithmetic, which holds no matter which date lands. The setup section of the passkey doc says new passkeys "take about one to 2 days to pair with Ads." The troubleshooting table says "wait 48 hours." The FAQ says "new passkeys may be subject to a 7-day security delay." Three different numbers in one document, with no published rule for which applies to you. You cannot control which path you get, so you plan against the worst case. Seven days before August 19 is August 12, which is next Wednesday. If the date slips again, you have lost nothing by being early.
Now the part that makes this an account-operations story rather than an IT story. Account linking is a sensitive action. An admin who cannot pass the passkey challenge cannot attach a new Merchant Center feed, cannot repoint a conversion import feeding your bidding, and cannot complete a GA4 or tagging link. This does not change a single bid. It changes whether you can change anything structural, at exactly the moment two September deadlines are landing.
The API half has a sharper edge than the developer framing suggests. Nothing breaks today, because live tokens keep working. The failure is deferred and it is personal: a refresh token is tied to the individual who authorized it, so whenever that connection is rebuilt, Google asks that person for a passkey. If they have left the company, the connection cannot be restored by anyone else, and you find out when a reporting dashboard goes dark or a bid script stops running. The fix is structural, not urgent: ask every vendor wired into your account whether they connect through a service account, which is exempt, or through one person's authorization, which is not.
Then the interlock. Multi-party approval sends a request to all administrators in the hierarchy, and any user with Admin access can approve, including admins on a linked manager account. That last part is genuine good news for agencies: your MCC admins are eligible approvers for child accounts. But read the rest of Google's doc carefully, because three details compound badly. No emails are sent for approval requests. Google's wording is blunt: "Since emails aren't sent for these approvals, it's important to check your in-product notifications regularly." Requests expire after 20 days with no action. And Google Ads support cannot approve or deny on your behalf, stated explicitly in the same article. So an access change can sit in an unread in-product notification for twenty days and then quietly die, and the only people who can rescue it are admins who now also need working passkeys.
One thing to say accurately, because the alarmist version is wrong: if an account drops from multiple admins to a single admin, Google pauses multi-party approval and cancels pending requests. So the sole-admin nightmare is not a deadlock. It is worse in a quieter way. A single-admin account has no approval friction and no second pair of hands either, so if that one person's passkey fails the challenge on August 20, there is nobody to escalate to and support cannot override it. The deadlock risk lives at the other end: accounts with four or more admins where fewer than two can actually complete a challenge.
Finally, the trap nobody will see coming. Google states that passkeys on Android browsers cannot complete sensitive challenges in Google Ads, and separately that autogenerated Android passkeys are not accepted for sensitive actions either. Meanwhile Google Ads gives you a Passkey status column in Admin, Access and security, which will happily report Enabled for those users. The column tells you a passkey exists. It does not tell you the passkey can pass a challenge. Anyone auditing off that column alone will believe they are covered and find out on August 20 that they are not.
Two more facts worth having before you audit. SSO does not substitute: Google's FAQ says that if you use Okta or similar, you still need a Google Ads passkey, because only Google Ads passkeys are accepted for sensitive challenges. And shared agency logins are finished. Google's own words: "A passkey is always personal." It is a credential bound to an individual's device and biometric profile, and Google's stated guidance is that agencies should move to individual user access with unique email addresses per employee. If your team has been sharing one login for a client account, that arrangement stops working in twelve days, and the fix, inviting new users, is itself a sensitive action.
Google moved the date once and will not publish the new one. When the deadline is unverifiable but the seven-day delay is documented, the only safe move is to be early.
Signal or noise: High (if you administer accounts)
High signal for anyone with admin rights on Google Ads accounts, and the rating is driven entirely by what is verifiably in force: the API passkey requirement since August 5, and multi-party approval since July 27. The account-level sensitive-action requirement is coming and its date is not, which raises the value of acting early rather than lowering it. The free-domain restriction is a pilot Google describes as running for "a subset of advertisers," so it does not carry the rating and you should not panic-migrate your whole book over it. Highest urgency for agencies, MCC operators, and anyone still using a shared login. Low signal, genuinely nothing to do, if every admin across your accounts is on a corporate domain with a passkey they have already used successfully on a desktop browser.
The Monday-morning playbook
Ordered by blast radius, not by Google's doc order. Treat Wednesday, August 12 as the working deadline for steps 1 through 5: it is seven days ahead of the date currently being reported, and being early costs nothing if the date moves again.
- Inventory in four minutes. Admin → Access and security → the Passkey status column. Select Filter → Passkey Status → Disabled, then tick Show users in full hierarchy to sweep the entire MCC tree in one pass. Export the list.
- Single-admin accounts first. Any account where one person holds sole admin has no escalation path and no support override. Add and verify a second admin now, while adding a user is still something you can do.
- Accounts with four or more admins next. These are the ones multi-party approval actually governs. Confirm at least two admins are passkey-ready and reachable, and tell them approvals arrive as in-product notifications only, no email, expiring after 20 days.
- Test the challenge, do not just set the key. Have each admin attempt one real sensitive action on a desktop browser before August 12. Setting a passkey and passing a challenge are separate events, and only the second one proves coverage. If it fails, they still have days rather than hours.
- Check for the Android trap. Any admin whose only device is an Android phone using a mobile browser is not covered regardless of what the status column says. Get them onto a supported desktop browser (Chrome 109+, Safari 16+, Edge 109+, Firefox 122+) or a FIDO2 hardware key, and confirm Bluetooth is on for cross-device verification, which needs both devices within a couple of meters.
- Retire every shared login. List them, invite each person individually with their own address, then remove the shared account. Do this now, because once the requirement lands the invitation itself needs a passkey behind it.
- Audit your API connections. List every tool wired into the account: reporting dashboards, bid scripts, feed managers, BigQuery transfers, Ads Editor users. For each, ask the vendor whether the connection runs on a service account, which is exempt, or on one person's OAuth authorization, which is not. Flag any authorized by someone who has left.
- Note the free-domain exposure without overreacting. List admins on @gmail.com or similar. It is a pilot, so triage rather than migrate: start the business-email switch on the accounts you cannot afford to lose access to, and leave the rest on a watch list.
- Agency ops line item. Name a second verified admin on every client account and record who it is in your account documentation. Then add this whole audit to the quarterly hygiene checklist. Access decays every time somebody leaves, and this is now the check that catches it.
This is one of several dated Google changes landing between now and February 2027. The rest are in the deadline calendar.
The bottom line
Nothing here changes a bid, a target, or a match type, which is exactly why it will get skipped. The cost of skipping it never shows up on the deadline. It shows up weeks later, when someone needs to link a Merchant Center feed or repoint a conversion import and discovers the approver is a shared login nobody has the phone for, or when a reporting dashboard quietly stops refreshing because the person who authorized it left in June. The date is genuinely unsettled, and that is an argument for moving sooner rather than an excuse to wait. Run the Passkey status filter across your hierarchy on Monday, have every admin test one real sensitive action before Wednesday, ask your vendors whether they run on service accounts, and put a second verified admin on every client account. Twenty minutes, and none of it is wasted whenever Google finally names the day.
Frequently asked
When do Google Ads passkeys become required?
There are two separate requirements. The Google Ads API requirement is confirmed and already in force: since August 5, 2026, generating a new OAuth refresh token requires a passkey, announced on the Google Ads developer blog on July 27, 2026. The account-level requirement, covering sensitive actions such as adding or removing users, changing permissions, account linking and billing edits, is widely reported as August 19, 2026, but that date comes from trade coverage rather than a Google page. Google's own advertiser email, sent in May 2026, stated July 15, 2026. Because Google documents that new passkeys may be subject to a 7-day security delay, a passkey created after August 12, 2026 may not work when the requirement lands. Check the notification in your own account for the date that applies to you.
Why did my Google Ads sensitive action fail if I already have a passkey?
Having a passkey and being able to pass the sensitive-action challenge are two different things. The most common causes are: the passkey is newly created and still inside its activation delay, which Google documents as up to 7 days; you are using an Android browser, which Google states cannot complete sensitive challenges in Google Ads; your passkey was autogenerated on Android, which is not accepted for sensitive actions; Bluetooth is off on either device during a cross-device verification; or the passkey lives on a different device than the one you are using. The Passkey status column in Google Ads reports that a passkey exists, not that it can complete a challenge.
Can agencies share a passkey for a client's Google Ads account?
No. Google states that a passkey is always personal: it is a cryptographic credential bound to an individual's device and biometric profile and cannot be shared among a group. Google's guidance is that agencies should transition to individual user access, inviting each employee with their own unique email address. An SSO platform such as Okta does not substitute, because only Google Ads passkeys are accepted for sensitive challenges in Google Ads. Any shared agency login is a dead end for sensitive actions from August 19, 2026.
Get the next brief in your inbox
When Google ships something that matters, you'll get the decode: what changed, whether it's signal or noise, and the move worth making this week. Free, no firehose, unsubscribe any time.