Google Is Closing the Ads API Hijack Loophole With Mandatory MFA on April 21

Google is making multi-factor authentication mandatory for new Google Ads API OAuth 2.0 refresh tokens starting April 21, 2026. Existing tokens keep working, but the second credentials need re-auth, the TWO_STEP_VERIFICATION_NOT_ENROLLED error stops the job cold. Agencies running Google Ads Scripts, Editor, BigQuery Data Transfer, or custom bidders have four business days to audit which accounts hold those tokens and enable 2-Step Verification on every one.

What actually changes on April 21

The mandate lives on the Google Ads Developer Blog and it is narrower than the headlines suggest. Enforcement starts April 21 and rolls out over the following weeks, not all at once. The trigger is new refresh token generation. If the Google account behind your API integration does not have 2SV enabled when a developer hits the consent screen to refresh access, the token request fails and the docs surface a TWO_STEP_VERIFICATION_NOT_ENROLLED error.

Tokens already in your vault will keep working. That's the good news and the bad news. The good news: nothing breaks on the 21st for an agency whose automation quietly refreshes an existing long-lived token. The bad news: most agencies do not know exactly which human's Google account is attached to each of those tokens. When the day comes to re-auth (developer leaves, token gets revoked, OAuth scope changes), you find out the hard way.

One other thing worth noting. The policy extends past the API proper. Google Ads Editor, Scripts, BigQuery Data Transfer, and Looker Studio all sit under the same auth umbrella. If your reporting stack pipes Ads data to BigQuery on a schedule, that connector re-auths periodically. Same exposure.

The MCC hijack backstory Google isn't saying out loud

Google is not framing this as a security fix, but that's what it is. We covered the MCC hijack wave in detail. Short version: throughout 2025 and into early 2026, attackers used near-perfect phishing emails disguised as Google account-access invitations, routed victims to fake login pages hosted on Google Sites, and collected credentials plus 2SV codes in real time. From there, they would add themselves as admins, link their own MCC, and run fraudulent high-budget campaigns on the victim's credit line.

One r/googleads agency reported their MCC was hijacked with 5,000 sub-accounts attached, credit limits maxed, and Google support unresponsive for days. Barry Schwartz covered the surge pattern over at Search Engine Roundtable. Search Engine Land documented the bypass mechanism back in August 2025.

If you stack Google's security moves up, you can see the ladder it's climbing. February 2026: Multi-Party Approval rolls out for sensitive MCC changes. March 2026: proactive scam warning emails to advertisers. April 17: MFA mandate for new API tokens. The MFA mandate is the one that hits developers, but it's the third step in a pattern, not a one-off.

April 21 is the forcing function.

Why service accounts are the real answer

Here is the part most agencies will miss. The MFA requirement applies to user-based OAuth flows. Service accounts are exempt. Google is quietly recommending them for any automated or offline workload, and from what I've seen, that's the right call for roughly 80% of agency use cases.

A service account has no human attached, no 2SV prompt, no risk that the developer who set it up leaves and takes the only working token with them. The setup is fussier (domain-wide delegation, P12 or JSON key management, customer ID impersonation), but once it's running, it's the most boring part of the stack. On paper, that sounds like a clear upgrade. And for most teams, it is.

The catch: service account auth is one of those topics where the docs feel deliberately underwritten. You'll spend a Saturday figuring out delegation settings for the first client. After that it's rote. Most agencies skip this migration not because it's hard but because user-based OAuth has always "just worked," and there was never a forcing function to touch it. Until now.

For a grounded sense of how messy this is in practice, the r/PPC thread on how agencies handle 2-step is worth a read. Common patterns: shared phone numbers, a single dev account that becomes the bus factor, and a lot of "whoever originally linked that client left two years ago." None of that survives an audit. The MFA mandate is forcing the documentation that probably should have happened the day the integration went live.

The 4-day audit checklist

If you manage client Google Ads accounts through any kind of automation, this is the list for this week.

1. Inventory every integration. Pull the list of everything that generates refresh tokens against the Ads API. Editor seats, Scripts across all linked MCCs, BigQuery Data Transfer configs, Looker Studio connectors, custom dashboards, bid automation, feed management tools. Yes, all of them.
2. Map each token to a human. Which Google account granted the token? For most agencies this is one or two developers, but it might also be a former employee whose account still has residual access.
3. Enable 2SV on every one. If a Google account attached to an API integration doesn't already have 2-Step Verification turned on, switch it on today. Do this before the token needs to be refreshed, not after it fails.
4. Identify automation candidates for service accounts. Any long-running job that doesn't need a specific human identity should migrate. Reporting pipelines, scheduled uploads, rule-based bidding. Plan the migration now even if you don't execute it this week.
5. Document the ownership. Write down which account owns which token. This is unsexy and the thing agencies consistently skip. It is also what prevents the 3am scramble when a developer quits and three client integrations go dark.

If all you do before April 21 is step 3, you're covered for now. Steps 1, 2, and 4 are what prevent the next incident.

What MFA still doesn't fix

Worth being honest. MFA on the API does not stop the phishing attack that caused the hijack wave in the first place. An attacker who gets a victim onto a fake Google Sites login page is still collecting the 2SV code along with the password in real time. Account-level MFA is necessary and insufficient. The thing that would actually shut this attack down is a phishing-resistant factor: hardware security key or passkey. Google offers both. Almost nobody at the agency level is using them.

My prediction, with appropriate hedging: something like 60 to 70% of agencies enabling 2SV this week will still get phished within the next 12 months, because SMS codes and authenticator codes both leak through Sites-hosted replay pages the same way they did all of 2025. Passkeys would fix it. The rollout for passkey enforcement isn't on Google's public roadmap for 2026, which means the next security mandate is probably 12 to 18 months out.

The audit that nobody runs until it breaks

Most agencies treat API credentials the same way they treat DNS. Boring, set up once, assumed fine. Then a token expires at 2am, a client's campaigns stop getting updated, and somebody spends a weekend rebuilding the integration while trying to explain to the account director why nobody knew who owned the automation. April 21 is the moment that invoice comes due for anyone who never wrote it down.

Notice Me Senpai Editorial