fixmation.Get my quote
Integrations14 min readPublished September 2026

Google Ads wants a passkey before it mints a new refresh token, and a new passkey is not ready today

Existing tokens keep working, so nothing breaks until the day you reconnect - and that is the day you find out the passkey the flow now demands may take days to become usable. What Google documents, which numbers disagree, and who can still avoid the flow entirely.

What changed, in Google's own words

On 27 July 2026 the Google Ads developer blog announced that minting a new OAuth refresh token for the Google Ads API requires a passkey.

As part of improving security for Google Ads accounts, the Google Ads API will start requiring passkeys for Google Ads API users. This is part of a broader change in Google Ads that requires passkeys to authorize sensitive actions in your Google Ads account. These important security updates will start rolling out from August 5, 2026, and will be enabled for all users over the next few weeks.

What that means at the authorisation screen is spelled out, and it removes the fallbacks most teams are actually using:

Once this change goes live, users following the user authentication workflow to generate new OAuth 2.0 refresh tokens for Google Ads API will always be required to authenticate using a passkey. If you haven't created a passkey, you will be asked to create one, and use it to complete the authentication workflow. Other forms of authentication that use password alone, or 2-factor authentication (2FA) mechanisms such as Time-based One-Time Password (TOTP) or SMS-based codes will be disallowed.

The rollout started on 5 August and was described as reaching all users over the following weeks, so by the time you are reading this it is live on most accounts.

Nothing breaks while it runs

This is the sentence that decides how the change will actually reach you:

Existing OAuth refresh tokens are not affected by this change. They will continue to work as usual, and you won't be prompted for reauthorization when obtaining OAuth access tokens.

So every Ads automation running today keeps running. Nothing turns amber, no run fails, no notification arrives. The change has no symptom at all until somebody mints a new refresh token, and the list of moments when that happens is short and predictable:

  • Onboarding a new client, or a new account for an existing one.
  • A token that died on its own. Google publishes the reasons, and they include a token unused for six months and a rebuild that pushes an older token past the per-client ceiling - the mechanics are in reconnect this account, and the reconnect button is greyed out.
  • Someone revoked access, deliberately or while tidying up third-party apps.
  • Moving the automation: a new n8n instance, a migrated Zapier account, a rebuilt scenario, a staging environment that needs its own connection.
  • Staff turnover, when the connection was authorised by a person who left.

A change with no symptom cannot be scheduled. It waits inside the one procedure you only ever run under pressure.

Every one of those is an unplanned event that somebody wants finished in the next twenty minutes. That is the collision.

The delay is the change

The blog post buries the operationally important sentence in the section about new users:

New users will be challenged to authorize with a passkey. A 7-day security delay may apply before a new passkey becomes trusted and operational. To ensure it's ready for use when you need it, create your passkey at your earliest convenience.

"May apply" is doing a great deal of work there. Google does not say when the delay applies and when it does not, which makes it unplannable in both directions: you cannot promise a client it will be quick, and you cannot tell them it will definitely take a week.

The Ads Help Center, on the page about using a passkey for sensitive actions inside the Google Ads interface, gives a different number for a related step:

Note: New passkeys take about one to 2 days to pair with Ads. Try attempting this action again after this period.

Read those two pages precisely, because they are not describing the same action: the seven-day figure is on the developer blog, about the API's authentication workflow, and the one-to-two-day figure is on the help page, about completing sensitive actions in the Google Ads interface. What they agree on is the shape of the problem. A new passkey is not necessarily usable the moment it is created, and neither page gives a number you can hold Google to.

The planning consequence is the same either way, and it is the whole point of this article: creating the passkey is a prerequisite task, not a step inside the reconnect procedure. Google says as much - create your passkey at your earliest convenience.

If you run Ads accounts for other people, the passkeys you need are not yours. They belong to the Google Accounts your clients authorise with, and they have to exist before anything breaks. This is a one-message task today and a lost week in an emergency.

Whose passkey, and whose phone

A passkey is not an account-level setting somebody can arrange centrally on your behalf. Google's own FAQ, answering a user who has to move from a personal to a corporate address, is blunt about the scope:

You will need to set up a new passkey. Passkeys are specific to each individual Google Account/email address.

So the passkey has to exist on the Google Account that clicks through the authorisation screen. In agency work that is very often the client's account rather than yours, and that person has to create it on a device they own.

Then there is a physical constraint that catches remote work specifically:

Bluetooth must be turned on for both the device performing the action and the device holding the passkey. Passkeys use Bluetooth to verify that your devices are physically near each other.

The same page puts a number on "near": devices should be within 1-2 metres (3-7 feet) of each other. There is a documented way to complete an action on a different device from the one holding the passkey, and it is that same cross-device flow - so it does not rescue the case where the phone is in another country. If your reconnect ritual is a screen share with the client clicking through on their laptop while their phone sits on the desk, you are fine. If it is "send me the code and I'll do it", that ritual is over.

Two more details from the same help page, both cheaper to know beforehand:

  • Autogenerated passkeys on Android can't be used to verify sensitive actions on Google Ads at this time - so a passkey a phone created by itself may not be the one that counts.
  • "To protect your account, don't create a passkey on a shared device." Agencies running a shared login on a shared machine are being told, politely, that the shared login is the problem.

You can check who is ready without asking anyone. In each Google Ads account, Admin > Access and security lists the users, and Google documents a "Passkey status" column with a filter on it. That is the inventory worth running this week, across every account you touch.

The one workflow this does not touch

Google's recommendation is explicit, and worth taking seriously:

Service account workflows are not affected by this change, so no action is required. We strongly recommend using service account workflow for applications that require automated or offline workflows.

A service account belongs to the application rather than to a person, and for the Ads API the setup is unremarkable: create the service account, download its key, then add its email address as a user in the Google Ads account under Admin > Access and security with the access level it needs. The benefit Google states for it is exactly the failure mode agencies keep hitting:

Authorization for access to Google Ads accounts is not tied to individual user credentials, which may be useful in cases such authorization is expected to continue even if the employee who originally authorized the access leaves the team or the company.

Two limits from the same page, before anyone plans a migration around it: a single email address can be associated with up to 20 Google Ads accounts, manager accounts included, and by default you cannot grant administrator access to a service account, although the page documents how to upgrade it when your calls need it.

The catch is who can use this at all. A service account key is something you hand to code you control. If your Ads calls are made by a platform, you get the authentication workflow that platform implements, and that is the user one. n8n documents this in a table of its own: for the Google Ads node, OAuth is supported and Service Account is not, on a page that says plainly that support for service account authentication is limited.

The Google-branded tools are on the user side of the line too:

Google products that use Google Ads API, such as Google Ads Editor, Google Ads scripts, BigQuery Data Transfer Service or Data Studio to manage Google Ads will also start requiring a passkey-based authentication.

What makes the callsWhich workflowWhat it means now
Your own code with a service account keyService accountUnaffected: no human in the loop to challenge
Your own code using a refresh token you mintedUser authenticationPasskey required the next time you mint one
n8n Google Ads nodeUser authenticationn8n's docs list Service Account as unsupported for this node
Any connector you set up by clicking through a Google sign-in screenUser authenticationPasskey required at the next reconnect
Ads Editor, Ads scripts, BigQuery Data Transfer Service, Data StudioNamed by GoogleWill also start requiring passkey-based authentication

The pilot sitting next door

One more thing is moving at the same time, and it can turn a fifteen-minute reconnect into a new Google Account. It is a separate policy - it governs actions inside the Google Ads interface, not the API's token flow - but it lands on the same people:

Users accessing Google Ads via free domain email addresses (such as @gmail.com or @yahoo.com) will be blocked from completing sensitive actions and must transition to a corporate email domain.

Pilot Notice: This update is currently being piloted for a subset of advertisers. You will receive an email notification if your account is enrolled in this updated security requirement.

Note the pilot qualifier: this is not universal today, and Google says enrolled accounts are notified by email. Note also what counts as a sensitive action - the page lists account linking updates and user access changes, then adds that the list is non-exhaustive and subject to change without prior notice.

It belongs in this article because of the chain it creates for a small client whose Ads account lives on a Gmail address. Moving to a corporate address means a new Google Account, which needs its own new passkey, which restarts whatever delay applies. And the same FAQ adds a second gate: if the account has three or more active administrators, inviting a new user or modifying administrator privileges triggers Multi-Party Approval, and another existing administrator has to approve the request before the new user exists.

Before
  • Nothing visibly wrong; every Ads automation runs on tokens minted months ago
  • A token dies on a Tuesday, or a new client signs
  • The reconnect stops at a passkey nobody has, on an account nobody in the room controls
  • Best case a day or two, worst case a week, with campaigns unmanaged in between
After
  • Every Ads connection is listed against the Google Account that authorised it
  • That account has a passkey, created before anything broke and visible in the Passkey status column
  • Unattended integrations you control run on a service account key instead of on a person
  • The reconnect takes ten minutes, because the slow part was done in advance

What we would do this week

  • List every automation, script or report that calls the Google Ads API, and write down which Google Account authorised each one: the client's, an agency shared login, or a person who may have left
  • Open Admin > Access and security in each Ads account and read the "Passkey status" column; filter by status to find the users without one
  • Get a passkey created now on every account you might need to re-authorise, on a device that person owns, and never on a shared machine
  • Check it is a real passkey rather than an autogenerated Android one, which Google says cannot verify sensitive actions on Google Ads at this time
  • For unattended integrations running on code you control, move to the service account workflow: create the account, add its email as a user in Google Ads, then retire the human token
  • Accept that platform connectors stay on the user workflow, and book reconnects as scheduled work with the client present rather than as emergency work
  • Note which clients are on free-domain email addresses, so the corporate-domain pilot does not arrive as a surprise in the middle of an outage
  • Schedule those reconnects with the client's phone in the room: the check needs Bluetooth on both devices, within a couple of metres

None of this is hard. All of it is slow, and the slowness lands at the exact moment you have least of it. That is the shape of this change: not a break, but a delay attached to the one procedure you only run when something is already broken.

Sources

  • Passkey authentication requirement for the Google Ads API - Google Ads Developer Blog, post dated 27 July 2026, read 25 August 2026. The rollout from 5 August, the passkey requirement on the user authentication workflow for new refresh tokens, password-only and TOTP/SMS being disallowed, existing tokens continuing to work, the 7-day security delay that "may apply", the service account exemption and recommendation, and the list of Google products that will also require passkeys.
  • Use a passkey to complete sensitive actions - Google Ads Help, read 25 August 2026. New passkeys taking about one to 2 days to pair with Ads, the Bluetooth requirement and the 1-2 metre range, autogenerated Android passkeys not being usable for sensitive actions, the warning against creating a passkey on a shared device, and the "Passkey status" column with its filter.
  • About email domain requirements for performing sensitive actions in Google Ads - Google Ads Help, read 25 August 2026. The free-domain restriction and its pilot notice, the non-exhaustive list of sensitive actions, passkeys being specific to each Google Account, and Multi-Party Approval on accounts with three or more administrators.
  • Service Account Workflow - Google Ads API documentation, read 25 August 2026. Setting up a service account by adding its email as a user in the Ads account, authorisation surviving the departure of the person who granted it, the 20-account association limit, and administrator access not being grantable by default.
  • Using OAuth 2.0 to Access Google APIs - Google Identity documentation, read 25 August 2026. The published reasons a refresh token stops working, including one unused for six months, and the per-client-ID ceiling that invalidates the oldest token without warning.
  • Google credentials - n8n documentation, read 25 August 2026. The compatible-nodes table showing the Google Ads node as OAuth-only with Service Account unsupported, and the note that support for service account authentication is limited.

Integration dropping data between systems? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.