Google this month sent email notifications to advertisers informing them that starting July 15, 2026, the Google Ads platform will require a passkey to complete certain sensitive account actions. The requirement does not apply to every login - it targets specific high-risk operations such as account linking updates and user access changes, where the consequences of unauthorised access are most severe.

The announcement, initially spotted by Vivek Gupta and circulated on LinkedIn, contains a direct message from Google: "Google is transitioning to a more secure, password-free future. Set up a Google passkey today to keep your account secure and avoid any disruptions to your Google Ads account. Starting July 15, a Google passkey will be required for performing certain sensitive actions in your account."

The deadline is six weeks away, and Google's own documentation advises that a newly created passkey can take between one and two days to pair with the Ads system before it becomes available for authorising sensitive tasks.

What passkeys are and how they differ from passwords

A passkey is a cryptographic credential stored on a user's personal device. Unlike a password, it cannot be shared, copied, written down, or accidentally disclosed to another person. According to Google, "Passkeys are a simple and secure alternative to passwords that can't be shared, guessed, copied, written down, or accidentally given to someone else. Using a passkey helps your most critical account settings remain secure, reducing the risk of phishing and unauthorized access."

Authentication works through the device itself. A fingerprint sensor, facial recognition system, or screen lock PIN verifies the user's identity locally. The biometric data never leaves the device and is never transmitted to Google. What gets transmitted instead is a cryptographic proof that the user has physical possession of the registered device and is able to unlock it - a combination that is resistant to remote phishing attacks.

This is technically distinct from two-factor authentication via SMS one-time codes or authenticator apps, a distinction that generated questions in the LinkedIn thread where the announcement circulated. Passkeys satisfy both the "something you have" (the registered device) and "something you are or know" (the biometric or PIN) requirements simultaneously, within a single authentication step. Unlike SMS codes, which can be intercepted or transferred to a different device, passkeys are cryptographically bound to the specific hardware on which they were created.

Passkeys are end-to-end encrypted. According to Google's own documentation, "even Google or Apple can't access your passkey." For Apple devices, passkeys sync across devices through iCloud Keychain, which means a passkey created on an iPhone is also available on an associated Mac without requiring a separate setup process. On Android, passkeys are backed up securely in the cloud through the Google Password Manager.

The technical requirements

Not every device or browser supports passkeys. According to Google's help documentation, supported operating systems include Windows 10 or later, macOS Ventura or later, ChromeOS 109 or later, Android 9.0 or later, and iOS 16 or later. On the browser side, Chrome 109 or later, Safari 16 or later, Edge 109 or later, and Firefox 122 or later are all compatible. Incognito or private browsing mode may block passkey setup on some operating systems and browsers, so standard browsing mode is required during initial configuration.

Hardware security keys that support the FIDO2 protocol are also eligible. Most security keys currently on the market support FIDO2, according to Google's documentation. A passkey can be created on a FIDO2 hardware security key that was added to a Google Account before May 2023, though the key may need to be removed from the account first.

Only one eligible device is required to become passkey-ready across the entire account. That said, Google recommends setting up a passkey on each device used to perform sensitive actions within Google Ads, since the verification process involves confirming that the authenticated user is physically near the device holding the passkey. Bluetooth must be active on both the device performing the action and the device holding the passkey, and the two must be within roughly 1 to 2 metres - or 3 to 7 feet - of each other. Pairing in the device settings is not required; simply having Bluetooth active on both devices is sufficient for them to recognise each other.

The 7-day and 48-hour delays

Two timing constraints matter for anyone setting up a passkey close to the deadline. Google's documentation notes that a newly created passkey may take up to seven days before it becomes available at sign-in. Separately, a specific 48-hour synchronisation period applies to authorising sensitive tasks - meaning advertisers who create a passkey cannot immediately use it to complete account linking updates or user permission changes. The practical implication is that anyone waiting until the week before July 15 to configure a passkey may find themselves unable to perform sensitive actions on the deadline date itself.

One LinkedIn commenter, Pradeep Singh Dasauni, highlighted a related security mechanism: "It also comes with a 7-day operational delay for certain sensitive actions, which is a great feature because it is designed to prevent an attackers who just hijacked an account from immediately making high-impact changes by creating new passkeys."

Cross-device workflows for agencies

The agency environment introduces complications that the documentation addresses directly. Sensitive actions on a desktop - where the passkey is stored on a separate mobile device - can be completed through a QR code workflow. When the "Confirm it's you" prompt appears, selecting "Use another device" or "A different phone/tablet" causes a QR code to appear on the desktop screen. Scanning that code with the phone's camera triggers a biometric prompt on the phone. Once the user completes the verification, the desktop browser automatically refreshes and the action is authorised.

The same workflow applies to hardware security keys. When the QR code is displayed, inserting the physical key allows the user to complete verification by following the on-screen prompts.

Autogenerated passkeys on Android - which some users may already have on their accounts without having set them up manually - cannot be used to verify sensitive actions on Google Ads at this time, according to Google's help centre. This is a meaningful distinction for Android users who may assume they are already covered.

The question of agency and multi-user account structures is addressed in the frequently asked questions section of Google's documentation. Passkeys are not compatible with shared agency logins, which the documentation confirms is a technical limitation rather than a policy choice. The inability to share a passkey is by design - it is what makes them more secure than passwords. Agencies that use shared login credentials will need to restructure their access model, assigning individual Google Accounts with their own passkeys to each person who needs to perform sensitive actions.

If an organisation uses a single sign-on platform such as Okta, a Google passkey is still required for sensitive actions within Google Ads. The SSO layer handles the initial login, but the passkey requirement applies specifically to the Google-level verification that governs access to high-risk account operations.

Checking the passkey status of team members

Account administrators can verify the passkey status of every user in a Google Ads account through the "Access and security" section of the Admin menu. A "Passkey status" column shows whether each user has a passkey enabled or disabled. Filtering by status - either "Enabled" or "Disabled" - lets administrators identify which team members still need to set up a passkey ahead of the July 15 deadline. For larger organisations managing multiple accounts, selecting "Show users in full hierarchy" provides a view across the entire account tree.

The security context: account hijacking in the advertising industry

The announcement does not appear in isolation. Account hijacking has become an escalating concern within the paid search industry. In April 2026, a coordinated fraud wave targeting digital advertising agencies was documented publicly after Pauline Jakober, Founder of Group Twenty Seven, described how a sophisticated scammer nearly infiltrated her agency through a fabricated client inquiry. The attack vector involved the account linking process itself - a sensitive action that will require passkey verification after July 15.

The pattern goes back further. In October 2024, a Google Ads representative made unauthorised changes to a client account, a case documented by Thomas Eccel, a former Google employee. That incident raised questions about internal access controls. In February 2026, a clause in Google's standard support contact form that allowed specialists to make direct changes to advertiser accounts without a separate confirmation step drew renewed attention from digital marketing professionals.

The passkey requirement can be understood as a technical response to one specific dimension of that problem: ensuring that whoever authorises sensitive account changes is physically present with a registered device, not a remote attacker who has obtained a password through phishing or credential stuffing.

Google's 2025 Ads Safety Report documented that the platform blocked or removed more than 8.3 billion ads during 2025 and suspended 24.9 million advertiser accounts. The scale of that enforcement effort reflects how actively the advertising infrastructure is targeted by bad actors. Passkeys address the specific threat of credential theft - where an attacker already possesses a valid username and password but lacks physical access to the device and biometric of the account owner.

Google announced passkeys for Google Accounts more broadly in April 2021, and the platform-wide rollout of passkey support began in May 2023. The extension of a mandatory passkey requirement to sensitive Google Ads actions in July 2026 represents the next stage of that transition for the advertising platform specifically.

The Google Ads API reflects this shift technically. Version 24.1 of the Google Ads API, released on May 13, 2026, introduced a new boolean field called passkey_enabled that indicates whether the authenticated user has a passkey configured. Developers building integrations that touch sensitive account operations can check this field programmatically before attempting those operations, enabling conditional handling when a user has not yet enrolled.

How to set up a passkey

According to Google's help documentation, setting up a passkey for a Google Ads account involves navigating to the Passkeys and security keys page within Google Account settings, selecting "Create a passkey," and following the steps provided by the device. For Windows users, this involves Windows Hello. For iPhone, iPad, and macOS users, iCloud Keychain must be active beforehand. The specific prompts and options vary by operating system and browser.

Google notes that creating a passkey opts the account into a passkey-first, password-less sign-in experience by default. Passwords remain available as a fallback, but the default sign-in flow will use the passkey where one exists. Users who want to retain password-first sign-in as the default can disable the "Skip password when possible" option in their account security settings, though doing so may result in continued prompts to use the passkey.

Passkeys should only be created on personally owned and managed devices. If a passkey is created on a shared or public device, anyone who can unlock that device gains the ability to access the associated Google Account. If a device with a passkey is lost or stolen, the passkey can be revoked immediately through the Google Account settings page, under "Passkeys and security keys."

What happens after July 15

According to Google's documentation, advertisers who do not have a passkey configured when they attempt to perform a sensitive action will be notified through email and in-product alerts. The documentation does not explicitly state that accounts will be locked out, but it does indicate that a passkey will be required to complete those specific operations. Alternatives such as the Google Authenticator app may be presented as a fallback for users who have not yet enrolled, but the documentation positions this as a transitional state rather than a permanent option for satisfying the requirement.

The sensitive actions that will require passkey verification include account linking updates and user access changes. These are among the highest-risk operations within a Google Ads account - the exact actions that a hijacker would prioritise after gaining initial access. Restricting them behind a device-bound cryptographic credential adds a layer of protection that is difficult to circumvent without physical access to the registered device.

Timeline

Summary

Who: Google Ads advertisers, agencies, and account managers globally - specifically those who perform sensitive account operations such as account linking updates or user access changes.

What: Starting July 15, 2026, Google Ads will require a passkey to authorise sensitive actions within an account. A passkey is a device-bound cryptographic credential verified through biometrics or a PIN, replacing password-based authentication for these operations. The requirement applies to accounts that are notified by email and in-product alert.

When: The mandatory deadline is July 15, 2026. Google sent email notifications to affected advertisers on May 8, 2026. Passkey setup can take 1 to 2 days to pair with the Ads system, and sensitive action authorisation may require an additional 48-hour synchronisation period after initial setup.

Where: The requirement applies across the Google Ads platform globally, affecting all account types notified by Google. Setup is managed through the Google Account settings page at myaccount.google.com/signinoptions/passkeys.

Why: The passkey requirement is a response to escalating account hijacking attempts within the advertising ecosystem. Passkeys cannot be phished, shared, or transferred remotely because they are cryptographically bound to a physical device. Restricting sensitive account operations behind this mechanism limits the damage an attacker can cause even after obtaining valid login credentials.

Share this article
The link has been copied!