Google Ads Access and Compliance Controls: A Practical Runbook

If you manage Google Ads through an API, an agency workflow, or connected reporting tools, your next access failure may not be a broken integration. It could be a human user who cannot complete a new authorization because no trusted passkey is ready. A campaign approval can stall for a separate reason: the account has not completed the certification required for a particular use.

You need to manage those as two control planes. Authentication determines who or what can connect to Google Ads. Certification determines whether an account has completed a policy approval for a particular advertising activity. Keeping separate owners and status records for each makes both problems easier to prevent and diagnose.

Key takeaways

• A passkey is required when a user generates a new OAuth 2.0 refresh token through the Google Ads API user-authentication workflow. This is not a blanket invalidation of every existing connection.
• Existing OAuth refresh tokens continue working and do not need reauthorization solely because of this change.
• A newly created passkey may face a seven-day security delay before it becomes fully trusted. Prepare it before a scheduled onboarding or authorization event.
• Service-account automation is not affected, but Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are included in the broader passkey rollout.
• Some certification applications are moving into Admin > Policy > Account. Availability varies, and the Help Center remains the fallback when the in-account workflow is absent.

Treat authentication and certification as separate controls

An OAuth refresh token is a credential that lets an application obtain new access tokens without asking the user to sign in for every request. A certification is an account-level policy approval for a defined advertising use. Both can block work, but they answer different questions.

A passkey cannot establish that you have the right to use copyrighted material. A Social Casino Games certification cannot restore an invalid OAuth credential. When a team tracks both under a vague label such as “Google access,” the wrong person receives the incident and the actual blocker remains untouched.

Assign an access owner and a policy owner for each account. They can be the same person in a small organization, but the responsibilities should remain distinct. The access owner manages identities, credentials, connected products, and authorization events. The policy owner confirms the intended ad use, controls certification submissions, and keeps the supporting internal approval trail.

Prepare new OAuth authorizations before they become urgent

The passkey requirement has a narrow but important scope. Under the announced rollout, which begins Aug. 5 and expands over the following weeks, a human following the Google Ads API user-authentication flow must use a passkey to generate a new OAuth 2.0 refresh token. Password-only authentication and familiar second-factor routes such as SMS codes and time-based one-time passwords no longer satisfy this particular workflow. A user without a passkey is prompted to create one.

Do not interpret that as an instruction to rotate every refresh token. Existing refresh tokens remain valid without reauthorization. Revoking a working credential merely to “comply” can create the exact new-token event for which your team is not yet prepared. Rotate or revoke a token when your normal security process requires it, but do not manufacture a migration that Google does not require.

The planning risk sits at the next authorization event. A newly created passkey may be subject to a seven-day security delay before Google fully trusts it. That means a user who creates a passkey when onboarding begins may not be able to finish the workflow on the date you promised.

• Identify the human Google accounts expected to authorize new integrations or reconnect deliberately.
• Have those users create their passkeys before the authorization window, not during it.
• Put the possible seven-day delay into onboarding plans and change windows that depend on a new refresh token.
• Keep existing refresh tokens in place while they remain valid and authorized.
• Never paste a refresh token, passkey material, or other secret into a ticket, spreadsheet, or certification record. Track status and ownership, not secret values.

Also distinguish an expiring access token from a request for a new refresh token. A healthy OAuth integration normally uses its existing refresh token to obtain new access tokens. The passkey change does not mean a person must intervene every time a short-lived access token expires.

Build the runbook around the credential type

A single instruction that says “set up a passkey for Google Ads” is too broad to be operationally useful. Start by classifying every connection according to how it authenticates and who owns the authorization.

1. Create an inventory with the Google Ads customer or manager account, connected application, environment, credential type, human or service owner, and business purpose.
2. Mark each connection as user-authorized OAuth or service-account automation. Applications that use service accounts for automated workflows are not affected by the new user passkey requirement.
3. For user-authorized OAuth, record whether the current refresh token is working and whether the authorizing user has a passkey ready for a future authorization.
4. List connected Google Ads products separately. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are also affected; a user accessing them without a passkey can be prompted to create one.
5. Add a named backup owner for the process, but do not create shared human accounts or copy credentials between people. The backup should know the recovery and reauthorization procedure, not possess another user’s secret.
6. Review the inventory before onboarding a client, changing the authorizing identity, or intentionally replacing a refresh token.

This classification also shortens incident triage. If a previously healthy API sync fails while using an existing refresh token, do not assume the passkey rollout invalidated it; existing tokens were explicitly left in place. Investigate the normal credential, permission, application, and account conditions. If a new user-consent flow cannot complete, check passkey readiness and the possible trust delay first. If service-account automation fails, the new user passkey rule is unlikely to be the cause.

Connected products deserve named owners even when the API integration itself is stable. A reporting team may meet the prompt in Looker Studio or BigQuery Data Transfer Service while the central API pipeline continues normally. Without a product-level inventory, that prompt can be misreported as an account-wide outage.

Turn in-account certifications into a controlled workflow

Google is gradually placing some certification applications inside Google Ads. Eligible advertisers may see the Social Casino Games workflow under Admin > Policy > Account. Not every account receives the option at the same time, so a missing menu is not evidence that an application was denied. Advertisers without the in-account option can continue using the existing Help Center process.

The interface rollout does not change the underlying advertising policy. It changes where some advertisers submit and manage the application. Existing Social Casino Games certifications remain valid, and pending applications are not affected. Do not submit a replacement merely because another account has gained the new interface.

A copyright-certification beta has also appeared as an account-level notice in Google Ads Manager. It opens a form that asks the advertiser to certify the right to use copyrighted content. Treat that availability as account-specific rather than universal.

1. Check Admin > Policy > Account in the exact customer or manager account involved.
2. If the appropriate certification workflow is present, record that the in-account route is available before submitting.
3. If it is absent, use the existing Help Center route instead of waiting indefinitely for the gradual rollout.
4. Check your internal register for a valid certification or pending application before creating another submission. Existing and pending Social Casino Games cases do not need to be restarted because of the interface change.
5. Record the account, certification type, submission route, submission date, accountable person, current status, and decision in a system your policy owner can review.
6. For a copyright attestation, route the submission to someone authorized to confirm ownership or licensing. The form records a certification; it does not create rights that the advertiser does not already hold. If the rights are unclear, pause the submission and have the appropriate rights or legal owner verify them.

Do not let the easier placement reduce the quality of your review. An in-account button makes submission more convenient, but convenience is not evidence. The person submitting should still be able to identify the account, the intended use, the authority for the claim, and the internal owner who approved it.

Before your next onboarding or certification deadline, create the two registers, classify every credential, and assign the two owners. Then have affected human users prepare passkeys early and check the exact account for its available certification route. The immediate job is not to reauthorize everything. It is to remove uncertainty about who can authorize access, who can certify compliance, and what happens when either control changes.

References

• Search Engine Land – Google makes passkeys mandatory for Google Ads API users
• Search Engine Land – Google begins rolling out in-account certification applications