How do you detect MFA being disabled in Google Workspace?

What to watch in Google Workspace when MFA settings change

Detection starts with the admin surface, not the user side. The key signal is a change to 2-Step Verification policy, enforcement scope, recovery settings, or exceptions for groups and privileged users. If MFA is disabled centrally, the risk is immediate because the change can affect many accounts at once and may not be obvious from a single login event.

Focus on events that show policy drift: a rule switched from enforced to optional, an exemption added for admins, or a security setting relaxed outside the usual review cycle. In Google Workspace, those changes are often more important than a direct sign-in failure because they indicate the control itself has been weakened.

Use the Google Workspace Security Guide as the broader admin reference for 2SV, super admin hardening, and audit log review, because MFA detection is most reliable when it is tied to the surrounding identity and admin control model.

Which logs and admin actions matter most?

The most useful telemetry is the admin audit trail for security policy changes, not just sign-in logs. Look for edits to 2-Step Verification, changes to enforcement by organisational unit or group, newly created exemptions, and changes to settings for super admins or delegated administrators. Those events show who changed the control, when it happened, and whether the action fits an approved change window.

Pair those audit events with admin session context. An unusual location, unfamiliar device, sudden burst of policy edits, or a sequence of changes made by a rarely used admin account should raise the priority of the alert. Where possible, correlate the change with change-management tickets so you can separate expected hardening work from suspicious weakening of the policy.

For investigation paths that connect admin compromise to downstream abuse, review the attack patterns in Microsoft Midnight Blizzard breach and Uber breach 2022, which show how attackers exploit weak or bypassed authentication once they reach privileged tooling.

How to confirm whether MFA was actually weakened

Not every security-setting change means MFA was disabled in practice. Confirm the effective state for the affected users and groups, then compare it with the expected baseline. A policy may still exist while exceptions, legacy rules, or admin overrides create a practical bypass. That is why the right question is not only “was the setting changed?” but also “who can now sign in without the protection we expected?”

Check whether the change was limited to a test group, whether a break-glass account was involved, or whether privileged accounts were exempted. Privileged exemptions are especially important because they often create the highest blast radius while looking like a narrow configuration change. If the change is authorised, document the business reason, scope, and expiry date so the exception does not become permanent by accident.

For users who still need stronger sign-in protection, compare the new policy state against the rollout guidance in the Passwordless and Passkeys Guide and the NIST SP 800-63 Digital Identity Guidelines, which help distinguish weak fallback paths from stronger authentication expectations.

Risk and Threat Considerations

Disabling MFA in Google Workspace matters because an administrative change can remove the last effective barrier between a stolen password and account takeover. The highest risk is not the setting itself, but the fact that attackers often target admin accounts, policy editors, and privileged exceptions to reduce the protection for many users at once.

Failure mechanism: An attacker or malicious insider changes security policy, creates an exception, or abuses delegated admin access so that accounts can authenticate without the expected second factor.

Impact: Once MFA is weakened, password reuse, phishing, token theft, and admin-session compromise become much more likely to succeed across mail, Drive, and other Workspace services.

Practitioner Guidance

What to verify: Treat every MFA-related admin edit as a control event, not just a configuration update. Verify who made the change, whether the account was privileged, whether the action aligned with a ticket, and whether any exempted users can reach high-value apps or admin panels.

Escalation / exception: If the change affects super admins, broad organisational units, or multiple users at once, escalate immediately and assess whether you need to rotate sessions or review recent sign-ins for the affected population. Temporary exceptions should carry an owner and expiry, otherwise they become a standing bypass.

Practitioner takeaway: The real detection target is policy weakening with privileged impact, because that is what turns a single admin action into an enterprise-wide authentication gap.

Related resources from NHI Mgmt Group

• How do you detect MFA being disabled for user accounts in Microsoft Entra ID?
• What breaks when Google Workspace MFA is allowed but not enforced for every user?
• What happens when a phishing kit captures Google Workspace access through an MFA-authenticated session instead of collecting passwords alone?
• How do you know if Google Workspace automation is actually working?