Google Ads Requires a Passkey From August 5. The Setup Takes Up to Nine Days

Create your Google Ads passkey today, before you read the rest of this. From 5 August 2026, generating a new OAuth 2.0 refresh token for the Google Ads API requires one, and a new passkey needs one to two days to pair with Ads plus a possible seven-day security delay before it is fully trusted. Nine days of setup against a deadline eight days away is the whole story. A passkey created on 28 July clears both waits by 6 August. Create it now and the deadline is a non-event; create it on 4 August and you may spend the first week of the month unable to reconnect a reporting tool.

What changes on 5 August, and what does not

Google's Ads Developer Blog announced the requirement on 27 July 2026. Per Search Engine Land's report of it (opened 28 July 2026), the rollout starts on 5 August for Google Ads API users and expands to all users over the following weeks. The trigger is narrow and important: it applies when a new OAuth 2.0 refresh token is generated. Existing refresh tokens keep working, and no reauthorisation is required for them.

So nothing breaks on 5 August. Things break the next time something needs to reconnect, which in most accounts is a random Tuesday when someone adds a client, resets a connection, or moves a dashboard to a new user.

That last row is the escape hatch worth knowing about before you need it. Automated workflows built on service accounts sit outside this change entirely, which is an argument for moving scheduled jobs off a human's OAuth token that was already true for other reasons.

Setting it up, in order

The requirements come from Google's own help pages on using a passkey to log in and using one for sensitive actions, both opened 28 July 2026.

1. Check the device you will actually use. Windows 10 or later, macOS Ventura or later, ChromeOS 109 or later, Android 9.0 or later, iOS 16 or later, or a FIDO2 hardware security key. The device needs a screen lock: Face ID, Touch ID or a PIN. Apple users need iCloud Keychain switched on; Windows users need Windows Hello.
2. Check the browser. Chrome 109+, Safari 16+, Edge 109+ or Firefox 122+, and not in Incognito or private browsing, which can block the creation of a new passkey outright.
3. Create the passkey on your Google Account. Open the passkeys and security keys page at myaccount.google.com/signinoptions/passkeys, select Create a passkey, and follow the device prompts. This is an account-level credential, not an Ads-level one.
4. Start the clock and note the date. Google states that new passkeys "take about one to 2 days to pair with Ads" and "may be subject to a 7-day security delay" before they can complete certain sensitive actions. Neither wait is something you can shorten by asking.
5. Create a second one on a second device. A passkey is bound to a device. One device means one lost phone stands between you and your billing settings. If a hardware key is in the budget, that is the cleanest backup because it does not depend on anyone's phone.
6. Test cross-device before you need it. Signing in from a desktop using a passkey held on your phone uses the "Use another device" option and a QR code, and it requires Bluetooth on both, within roughly one to two metres. Find out now that Bluetooth is disabled on your work laptop, not during a client call.

If the passkey does not appear at sign-in, Google's troubleshooting points at two things: the screen lock, and the "Skip password when possible" setting in your Google Account. And if a device is lost, revoke its passkey through account security settings immediately, which is the one step in this whole process that is genuinely urgent when it happens.

Agencies: this is per person, not per account

Passkeys attach to Google Accounts, and the token is generated by whoever is signed in. So the question for an agency is not whether the agency has a passkey, it is whether every person who might reconnect a client account has one, on a device they will still have in November. Make a list of everyone with access that can generate tokens, confirm each has created a passkey, and record the date, because the seven-day delay applies per passkey rather than per organisation.

Worth pausing on what this is defending. The attack it addresses is account takeover through a convincing fake login page, where the victim approves a two-factor prompt for someone else and the attacker drains the campaign budget. A passkey is bound to the origin it was created for, so a lookalike domain cannot use it. That is a real improvement over codes and prompts, and it is unusual among platform security mandates in that it costs you nothing except the setup time. Compare it with the credential hygiene questions we ran through in the endpoint audit: the same principle, applied to the one account where spending happens automatically.

While you are in there: the EEA financial services check

Unrelated mechanism, same window, easy to miss. Google's new verification requirements for certain financial services advertisers (opened 28 July 2026) began rolling enforcement on 23 July 2026 across 24 markets: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, Greece, Hungary, Iceland, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Romania, Slovakia, Slovenia and Sweden. Advertisers must show that "the relevant financial services regulator directly authorizes them to undertake financial services activities or that they are exempt from that requirement", certified through Google's external partner G2, which opened applications on 23 June 2026.

In-scope categories are broader than banks: banking, credit cards, loans, investment services, brokerages, bonds trading and insurance. If you are notified and do not complete it by your enforcement date, you "will not be allowed to show financial services ads in the relevant targeted locations". Fintech products with an EEA audience should check their account notifications today rather than after the ads stop.

If 5 August arrives and you are stuck

Two facts decide your options. Existing refresh tokens keep working, so a connection that is currently live is not the emergency; do not delete it to "refresh" things while you wait. And service accounts are exempt, so a scheduled export that has to keep running can be moved onto one. Everything else waits out the delay. That is an unusually clean set of instructions for a platform deadline, which is exactly why it is worth spending five minutes on it today: this is one of the rare compliance chores where doing it early costs nothing and doing it late costs a week of access. Google's other current deadline for small teams, developer verification for Android apps, is a bigger job on a longer clock. This one is a five-minute task with a nine-day tail.

One caveat on scope, stated plainly because Google has not: the help page lists examples of sensitive actions, "account linking updates or user access changes" and adding users or changing billing information, but does not publish a complete list. Assume any action that changes who can see or spend money in the account is on it.