Google is making passkeys mandatory when users generate new OAuth 2.0 refresh tokens through the Google Ads API. The rollout starts on August 5 and expands over the following weeks. Existing refresh tokens continue to work, and service accounts are not affected, but that reassurance can hide the operational risk: the first time an agency adds a new user, replaces a credential or reconnects an integration, an unprepared access model can become a delivery delay.
This is not mainly a developer update. It is an account-governance test for agencies, in-house teams and SaaS vendors. Passkeys are personal credentials tied to a device and cannot be passed around like a password or one-time code. That is the security benefit, but it also exposes every workflow that still depends on a shared Google identity, an undocumented former employee or one person’s phone.
What changes and what does not
Users following the Google Ads API user-authentication flow will need a passkey when creating a new refresh token. Google says password-only authentication, SMS codes and time-based one-time passwords will no longer be sufficient for that step. A user without a passkey will be prompted to create one.
Current refresh tokens should keep working, so teams do not need to reconnect every account immediately. Applications using service accounts are outside this change. However, Google also notes that a newly created passkey may face a security delay before it is fully trusted. Depending on the workflow, the delay may last several days. That turns last-minute onboarding into a project risk.
Why shared agency logins are now an operational liability
A shared login obscures who approved access, who generated a token and whose device controls recovery. Passkeys deliberately make that model harder because each credential belongs to an individual. Agencies should interpret this as a prompt to assign every operator a named account, use manager-account permissions and document who owns each integration.
The immediate temptation will be to place a passkey on a communal device. That preserves the old problem under a new label. A better design separates personal authentication from organizational continuity: named users authenticate, the agency controls role assignments, and at least two trained administrators can restore access without borrowing another person’s identity.
A five-part readiness checklist
1. Inventory every token-producing workflow
List the tools that create or refresh OAuth credentials: internal scripts, reporting pipelines, bid-management platforms, data warehouses, Google Ads Editor, Ads Scripts, Looker Studio and BigQuery transfers. Record the owning Google identity, the business owner, the technical owner and the consequence of failure.
2. Replace shared identities with named users
Invite employees through their own work accounts and give them the minimum required role. Remove obsolete users only after confirming that no integration depends on them. Keep two administrators for continuity, but do not give broad access simply because it is convenient.
3. Create passkeys before the urgent moment
Each person likely to authorize a new token should create a passkey on an eligible device and test the cross-device flow. Google supports modern Windows, macOS, ChromeOS, Android and iOS devices as well as FIDO2 hardware keys. Teams using managed devices should confirm browser, Bluetooth and device-policy compatibility with IT.
4. Design recovery and employee-exit procedures
Document what happens when a phone is lost, an employee leaves or a passkey stops working. The answer should not be “ask the person who set it up.” Store ownership records in the integration register, keep backup administrators and include token dependencies in offboarding.
5. Test onboarding with a low-risk account
Run the complete authorization process before August 5 using a test or low-risk account. Measure how long passkey creation, trust delays, approval and application connection take. A successful login is not enough; confirm that the application receives the expected account scope and that audit records identify the correct person.
Questions to ask every martech vendor
- Does the connection use user OAuth or a service account?
- Which person must generate the refresh token, and what permissions are requested?
- Can a second administrator restore the integration without the original user?
- Where is the token stored, encrypted and rotated?
- What alert appears when authorization fails?
- How quickly can historical data collection resume after reconnection?
Vendors should be able to answer without asking customers to share passwords or impersonate colleagues. If the support procedure begins with a generic agency login, the product has not adapted to the security model.
The management takeaway
The passkey requirement will not improve campaign performance by itself. It will reduce a class of phishing and account-takeover risk while forcing teams to make access ownership visible. The most prepared organizations will treat August 5 as a deadline for cleaning the identity layer beneath their reporting and automation, not merely as another authentication prompt.
Do the inventory now, establish named access and test the recovery path. The cost is a few hours of operations work. The alternative is discovering during a launch, migration or client onboarding that the only person who can authorize the connection is unavailable and the new credential cannot yet be trusted.
Sources
- Search Engine Land: Google makes passkeys mandatory for Google Ads API users
- Google Ads Help: Use a passkey to complete sensitive actions
- Google Ads API: Security requirements
