Google's 7-Day Passkey Delay Quietly Moves the July 15 Deadline to July 8
Google Ads will require a passkey to confirm sensitive actions starting July 15, 2026, including account linking changes, user access edits, billing updates, and unusual bulk operations. New passkeys carry a seven-day security delay before they can authorize those actions, which means an agency that waits until July 14 to enroll loses that credential for the first week of enforcement. The functional deadline for any agency running shared MCC access is July 8.
The list of "sensitive actions" is wider than the headline coverage made it sound
Most of the early write-ups frame this as account linking and user access edits. The actual list, pulled from Google's help doc and the in-product challenge logic, covers more ground. It includes inviting standard or admin users, making unusual budget or bulk changes, creating ads with URL domains the account has never used before, and creating campaigns tied to apps the account has never touched. Both billing edits and permission changes trigger it. So does almost anything that, if a hijacker performed it, would push budget toward an unfamiliar destination.
That last category is the one to watch. Agencies onboarding a new client in the second half of July will hit the new-domain trigger on the very first campaign push. From what I've seen in pilot-account threads, that's the unannounced operational tax: every fresh client onboard is now a passkey event, not just the legacy MCC linkage everyone was preparing for.
The seven-day delay is the actual trap, not the cutover date
This is the part most people are missing. A newly created passkey is not immediately trusted for sensitive actions. Google's own documentation says newly created passkeys "may be subject to a 7-day security delay" before they can authorize sensitive tasks. The reasoning is reasonable enough: if an attacker creates a passkey after stealing a session, you don't want it instantly unlocking billing changes. But the practical effect is that you cannot wait until the week of July 15 to set this up. Enroll on the morning of July 15, and the passkey doesn't clear until July 22.
Run the math against any agency-ops calendar and the real deadline is July 8 for anyone who wants every seat to be functional from the moment enforcement begins. That's roughly nine weeks from today, which sounds long until you remember that this requires getting every billing admin, account linker, and senior user team member to enroll a credential on a supported device. Cross-team rollouts of this kind tend to take longer than they should, especially when the people who need it are also the people taking PTO over July 4.
There's a smaller wrinkle in the docs. A separate troubleshooting note tells users to "wait 48 hours before using your new passkey to authorize sensitive tasks." Two different timeframes (48 hours and 7 days) appear in Google's own published material, and from what I've seen in threads from advertisers in pilot accounts, the seven-day version is the one that actually plays out in production. Plan for seven, hope for two.
The shared-login era for client accounts is over (and the cleanup is bigger than passkeys)
Passkey verification is per user, on a physical device the user controls. That breaks every workflow built on the convention of one shared login that gets passed around the team. If the "campaign manager" Google account is used by three people on rotation, exactly one of them can register a passkey to it, and that one becomes the only person who can perform sensitive actions on that account. Everyone else's screen will sit on a verification prompt they cannot satisfy.
Most agencies already know they shouldn't use shared logins, but plenty still do for legacy reasons (the original audit was set up on one Google account, the billing email is on one Google account, the freelancer who built the MCC three years ago is still nominally the owner). Search Engine Roundtable's coverage of the rollout suggests Google's clear intent is to push every agency toward proper user-level access, with named seats, owner-level admins, and revocable permissions.
Calling the work ahead "set up passkeys" undersells it. The actual scope is: audit every account, document who really needs which permission level, archive the people who left the agency or client months ago, then assign one passkey per real human. That's an agency-ops project, not an IT one. Most agencies haven't scoped it. If you've already lived through Google's other 2026 compliance whiplash (the July 1 call recording flip that handed wiretap liability to 12 states is the one most agency ops leads are still cleaning up), you know how this lands.
What the next nine weeks actually look like for an agency-ops lead
Three concrete pieces, in order. First, pull a list of every Google account that has any access to any client MCC, sub-account, or billing profile. This is the part most agencies skip. Use the User Access page on each MCC and a spreadsheet, not a script. Note who's an admin, who's a standard user, who has billing rights, and who shouldn't be there anymore.
Second, map each row to a real human at the agency, with their preferred device for passkey enrollment. Devices that work for sensitive-action verification are Windows 10 or later, macOS Ventura, ChromeOS 109, Android 9, and iOS 16. One quirk worth knowing: autogenerated Android passkeys don't qualify for sensitive-action verification, only manually created ones do, which is a footnote that's already burned a few pilot accounts. So if you're standardizing on Android, walk people through the manual enrollment rather than letting Google Password Manager create the credential silently.
Third, set the enrollment deadline at June 30, not July 8. That gives a week of buffer for the seven-day delay and another week for the inevitable "I lost my phone" tickets. Anyone not enrolled by June 30 doesn't perform sensitive actions on July 15. Communicate the deadline now, not in late June.
The opinion on why Google is doing this now
PPC News Feed's coverage frames the passkey rollout as part of a broader push that includes the scam-warning emails Google has been sending advertisers in 2026. From what I've seen, that read is roughly right. The MCC hijack threat is real (search the r/PPC subreddit and you'll find quarterly threads from agencies whose accounts were taken over and whose client budgets were drained before Google's automated systems noticed). Passkeys break the most common attack vector, which is reused or phished passwords. They also conveniently push the marketing platform toward the same identity model Google uses internally.
Whether this lands well or poorly for advertisers depends almost entirely on how each agency runs its current access model. Agencies that already operate with named user seats, MFA enforced, and a quarterly access audit will barely notice. Agencies still running on shared inboxes and forwarded password reset emails are about to have a difficult quarter. Search Engine Land's read on the new help doc arrives at roughly the same conclusion, though more politely.
Personally, I think the seven-day delay is the part Google has under-communicated, and the part that will catch the most agencies off guard. Plenty of teams will read "July 15" and pencil in the second week of July for setup, then discover on the 16th that nothing works. The deadline I'd write in any agency-ops calendar is June 30. The official one is for everyone else.
Notice Me Senpai Editorial
