Google Ads Multi-Party Approval: A Second-Admin Lock on Sensitive Actions

What MPA actually gates and how it works

Multi-party approval is a dual-authorization control for user-management actions inside a Google Ads account or manager (MCC) hierarchy. Compromising a single admin credential - the typical outcome of phishing - is no longer sufficient to add a backdoor user, remove a legitimate admin, or escalate privileges.

Multi-party approval (MPA) is a security feature for Google Ads designed to protect your account from unauthorized activity by requiring a second account administrator to verify sensitive changes. Sensitive actions like adding users or changing user roles will prompt other administrators of your account to approve these changes. Google Ads Help - support.google.com/google-ads/answer/16891189

The covered surface is narrow and explicit. Three actions trigger an approval request: adding a new user to the account, removing an existing user, and changing user roles or permissions. Nothing else. Bidding, budget, campaign edits, billing changes, and reporting access remain reachable by any admin holding valid credentials. MPA is a hijack-resistance layer, not a comprehensive account-fraud control.

The workflow has four moving parts. First, an admin initiates a sensitive change through the standard interface. Second, Google Ads automatically generates a pending approval request and pushes in-product notifications to eligible admins in the hierarchy - direct administrators and owner managers of the requester receive individual notifications, while others get a combined digest. Third, a second admin reviews and either approves or denies the request from the Access and security menu. Fourth, the request resolves in one of three ways: complete (approved and applied), denied (blocked), or expired (no action taken within 20 days, auto-rejected).

Two operational details practitioners should internalize now. Emails are not sent for MPA requests - notifications surface only inside the Google Ads UI, which means teams that work primarily from inbox or chat will miss them. And if your other admins are unresponsive, Google Ads support cannot approve or deny a request on your behalf. There is no escalation path. Internal communication discipline becomes the dependency.

When it took effect and how activation works

Google launched MPA in early February 2026, in direct response to the 2025 surge in MCC takeovers. The most important detail many writeups miss: activation is automatic. There is no admin switch. The feature turns on the moment your account has at least two administrators.

• Announced: Early February 2026, via Google Ads Help and confirmed in industry coverage on February 5, 2026.
• Rollout begins: Live for all Google Ads accounts globally on launch; no regional staging.
• Activation threshold: Automatic for any account with two or more administrators. Solo-admin accounts have no MPA protection.
• Expiration window: Pending requests auto-reject after 20 days of inaction.
• Future scope: Google has signaled additional actions may require approval as security needs evolve, but the current list is fixed.

That means the most important configuration step is not flipping a switch - it is auditing your admin count on every account you manage. If you are the only admin on a client account, MPA is inert there and the account is fully exposed to single-point-of-compromise attacks. Adding a second trusted admin is what activates the protection.

Who this changes the calculus for

MPA's leverage scales with the size of the access surface you manage. Agency MCC operators get the most direct value; single-account in-house teams get less mechanically but still benefit. Solo-admin accounts get nothing until a second admin is added.

One nuance worth flagging: MPA is also an operational safeguard against internal errors, not just external attackers. Accidentally removing a critical user or granting excessive permissions to a contractor triggers the same review workflow - errors get caught before they create access problems. For agencies with junior staff doing provisioning, this is meaningful.

What to do this week

Priority order: audit admin counts across every account you touch, fix the solo-admin gaps first, then put a notification-monitoring routine in place so pending requests do not rot for 20 days.

1. Audit your admin count on every account. Pull a list of every Google Ads account you have access to. For each, check the administrator count. Any account with fewer than two admins gets a second trusted admin added today - that is what activates MPA. Google's own short on MPA recommends three administrators rather than two, so that a single admin's absence does not block legitimate changes.
2. Build a notification-monitoring routine. Since emails are not sent for MPA approvals, assign at least one person per workday to check in-product notifications in the Google Ads UI. Build it into the daily ops checklist. Go to Access and security in the Admin menu, then Pending invitations, then Review request - that is where pending, completed, denied, and expired requests live.
3. Designate MPA responders across time zones. If your agency operates across regions, distribute admin roles so an approval request never sits pending because the only other admin is asleep. Document who covers which window.
4. Document the approval chain in your SOPs. When a new client onboards or a new hire needs account access, who initiates the request? Who approves it? Write it down before someone gets stuck. New hires should know the process before they touch a single account.
5. Set an internal SLA for approval turnaround. The 20-day window is generous, but it is not a target. Aim for same-business-day review during business hours. Treat the in-product notification as the formal record, but use Slack or a direct message to flag urgent requests - do not rely on the notification alone for time-sensitive changes.

What to do this quarter

The strategic point: MPA is one ring of defense, not the perimeter. It blocks the specific actions that enable long-term account takeover - adding backdoor users, removing legitimate admins, escalating roles. It does not prevent an attacker with valid admin credentials from launching fraudulent campaigns, modifying bidding, changing billing, or burning budget within a single session. Build the rest of the stack.

Layer MPA into a multi-ring defense

Five concentric controls Google already provides should now be reviewed in sequence. Ring one is identity verification: enforce 2-Step Verification across every user, not just admins, and migrate to passkeys or hardware security keys where possible since SMS-based 2FA is now bypassable through near-perfect phishing. Ring two is domain restrictions: the Allowed Email Domains setting blocks the common attack pattern of hijackers inviting random Gmail addresses as admins. Ring three is manager account security mandates: cascade 2FA and domain rules across every sub-account from the MCC level. Ring four is access hygiene: quarterly access reviews to remove inactive users and revoke admin rights from anyone who has changed role or left. Ring five is phishing-resistant authentication: passkeys are Google's central recommendation and they eliminate the credential-harvesting vulnerability that drives most account takeovers.

Adjust hiring, offboarding, and revocation workflows

Every employee with admin access now affects two processes - the work they do and the approvals they give. When someone leaves, you are not just removing one user; you are potentially dropping below the two-admin threshold on certain accounts, which silently disables MPA. Offboarding checklists need to verify admin count after removal. On the revocation side: if you initiate a request in error, you can only revoke it if the other admin has not yet approved or denied it - so document the revocation path and use it immediately rather than hoping the second admin will catch the mistake.

Plan for the single-admin client onboarding case

Some client accounts arrive with only one admin. Before strategy, before campaign builds, before anything else, add a second admin. Without that step MPA is inert and the account remains fully vulnerable to the same single-point-of-compromise attacks that defined 2025. This is the cheapest, highest-leverage security action available right now.

What we're seeing in real accounts

The 2025 hijack wave is the context for everything in this dispatch. Coverage tracked sophisticated phishing campaigns that mimicked Google's account-access invitations near-perfectly, including the "great Google Ads heist" cluster reported by security researchers in early 2025. The pattern was consistent: attackers impersonated Google Ads, harvested credentials from fake login pages, added themselves as admins to MCCs, and either resold the access on black-hat forums or launched fraudulent high-budget campaigns. Two-step verification did not stop the wave on its own - one agency owner reported on LinkedIn that his entire MCC was hijacked at 12:30 a.m. with 2FA enabled.

Counterpoint worth noting: MPA does not address the immediate-damage scenario. Reports from 2025 included a performance-advertising agency that saw $180,000 in overspend overnight from a single compromised credential, and other agencies that racked up "tens of thousands" within 24 hours. An attacker with valid admin credentials can still launch fraudulent campaigns, change bidding, and modify billing inside a single session - MPA does not gate any of that. The deterrent is structural over time, not immediate. That is why the multi-ring defense matters more than the single feature.

What we're still watching

Four open questions are driving how we sequence Google Ads security audit work for the next two quarters.

• Email or webhook notifications for MPA: The exclusive reliance on in-product notifications is the biggest adoption friction point. Teams that operate from inbox and chat tools will miss requests. Whether Google adds an email channel, a webhook, or a third-party integration would change the operational calculus significantly.
• Scope expansion to budget and billing changes: Google has signaled that additional actions may require approval as security needs evolve. The most useful expansion would be billing-payment-method changes and large daily budget edits - the actions an attacker with valid credentials uses to cause immediate financial damage. Whether Google extends MPA to those actions is the most important question for the next iteration.
• API user gating: API users are currently exempt from the approval process. For teams using automation scripts with admin-equivalent permissions, this is a separate attack surface. Whether Google adds an MPA-equivalent for sensitive API actions, or whether the burden shifts to OAuth scope review and credential management, is still unresolved.
• Support escalation for unresponsive co-admins: The current rule is that Google support cannot approve or deny a request on behalf of an unresponsive admin. For agencies where a co-admin departs unexpectedly, this creates a 20-day lockout on legitimate provisioning. Whether Google introduces a verified support-escalation path is worth tracking.