How to Enforce MFA Across Your Google Workspace Organization

Multi-factor authentication is the highest-return security control most organizations can deploy, and in Google Workspace it is called 2-Step Verification (2SV). The catch is the word *enforce*. Making MFA available is easy and largely useless — the accounts most likely to be attacked are the least likely to opt in. Real protection comes from enforcement: requiring it, organization-wide, with the right factors and a rollout that does not lock anyone out. This article is that rollout plan.

Why "available" is not "enforced"

If 2SV is optional, adoption follows the path of least resistance: technical and security-aware staff enroll; busy executives and service-adjacent accounts do not. Attackers know this. Credential-phishing and password-reuse attacks target exactly the accounts that skipped enrollment. An optional control protects the people who needed it least.

Enforcement flips that. When 2SV is required, a stolen password is no longer enough to take over an account — which neutralizes the most common account-compromise path in one move.

Choose your factors deliberately

Not all second factors are equal. From strongest to weakest:

• Passkeys and hardware security keys (FIDO2). Phishing-resistant: they cryptographically bind to the legitimate site, so a phishing page cannot relay them. The gold standard, and strongly recommended for administrators and other high-value accounts.
• Google prompt / authenticator app (TOTP). A solid improvement over passwords, but a determined real-time phishing kit can relay a one-time code. Good for the general population.
• SMS codes. Better than nothing, but vulnerable to SIM-swapping and interception. Acceptable as a fallback, not as your primary factor.

A sound policy: require strong, phishing-resistant factors for admins and sensitive groups, allow app-based codes for everyone else, and minimize SMS.

A staged rollout that avoids lockouts

The fear that stalls MFA enforcement is locking people out. Stage the rollout to remove that risk:

1. Communicate first. Tell the organization what is changing, why, and by when. Provide enrollment instructions. Surprise enforcement generates help-desk tickets and resentment.
2. Open an enrollment window. Turn on 2SV as available and set a deadline. Track enrollment progress so you can see who has not enrolled.
3. Nudge the stragglers. As the deadline nears, remind the accounts that have not enrolled. This is where most of the long tail enrolls.
4. Enforce with a new-user grace period. Turn on enforcement, but configure a grace period for newly created accounts so onboarding is not blocked at first login.
5. Distribute backup options. Ensure users have backup codes or a second factor registered, so a lost phone is a minor inconvenience, not a lockout.
6. Handle exceptions narrowly. Some service or shared accounts may genuinely struggle with interactive 2SV. Move those to a more appropriate authentication model (service-account keys, dedicated handling) rather than carving broad exemptions into your user policy.

The Admin console supports enforcement at the organizational-unit level, so you can pilot with IT, then a department, then the whole org — de-risking the rollout further.

Common pitfalls

• Exempting executives "for convenience." The highest-value accounts are the worst ones to exempt. If anything, hold them to the *strongest* factors.
• Allowing only SMS. It satisfies the checkbox while leaving the SIM-swap door open. Push for app-based or hardware factors.
• Forgetting service and shared accounts. These often hold significant access and skip interactive auth. Govern them deliberately — see detecting risky AI agents and service accounts.
• Treating it as one-and-done. New accounts, new exceptions, and policy drift mean enforcement needs periodic verification, not a single switch.

Verify enforcement — do not assume it

Turning on the policy and confirming it is *actually applied to every account* are two different things. Accounts created before the policy, ones in an exempted org unit, or ones caught in a grace period can quietly fall outside enforcement. Part of a healthy Google Workspace security posture — and a control SOC 2 auditors specifically examine under CC6.1 — is checking that MFA enforcement holds across the whole organization, not just that the toggle is on.

This is exactly the kind of configuration that drifts and the kind auditors ask you to evidence. A posture tool that checks org-wide settings will flag where 2SV is not enforced (when the relevant admin visibility is available), so "we enforce MFA" is a verified fact rather than an assumption.

Handling the hard cases

Most accounts enroll without drama. A few categories need deliberate handling, and how you treat them often determines whether enforcement actually holds:

• Executives and VIPs. They are the prime phishing targets and the most likely to request an exception. Hold them to the strongest factors rather than exempting them. A compromised executive account is among the worst outcomes; convenience is not worth that trade.
• Shared mailboxes and role accounts. Interactive 2SV fits an individual, not a mailbox five people use. Re-model these as delegated access to individually-protected accounts, so the protection follows real people.
• Service and automation accounts. These should not be doing interactive logins at all. Authenticate them with service-account credentials managed separately, and govern them like the non-human identities they are.
• Field staff and frontline workers. People without a smartphone or with limited connectivity need a workable factor — hardware keys or backup codes — planned before enforcement day, not improvised at the help desk.

The principle across all of them: do not carve broad exemptions into your user policy to accommodate a few edge cases. Solve each case with the right mechanism so the baseline stays intact.

After rollout: keep it enforced

Enforcement is not a finish line. New accounts, newly-created organizational units, and one-off exceptions all create paths for coverage to slip. Bake a recurring check into your routine: confirm that 2SV remains enforced across every organizational unit, that no exemption has quietly become permanent, and that strong factors are still required where you required them. The strongest control in the world decays if nobody confirms it is still on — and "we enforce MFA" should be a statement you can prove, not one you hope is still true.

8200.dev audits your Google Workspace admin configuration — including 2-Step Verification enforcement, sharing controls, and email authentication — and flags drift with links straight to the setting. See how it works.

Want to confirm MFA is actually enforced everywhere? Start your free security audit and get a read on your Google Workspace identity and configuration posture.