Google Workspace: enforce 2-Step Verification for all users

Implementing multi-factor authentication (MFA) is a critical security measure for any organization, especially within cloud environments like Google…

Implementing multi-factor authentication (MFA) is a critical security measure for any organization, especially within cloud environments like Google Workspace. While Google Workspace offers various authentication mechanisms, 2-Step Verification (2SV) significantly reduces the risk of unauthorized access due to compromised credentials. This article details the process of enforcing 2SV for all users in Google Workspace, covering essential configuration steps, recommended practices, and considerations for administrators.

Understanding Google Workspace 2-Step Verification Options

Google Workspace provides several methods for 2SV, each with varying levels of security and convenience. Understanding these options is crucial for making informed policy decisions.

• Google Prompt (default): A push notification sent to a user's registered mobile device via the Google application. It's user-friendly but relies on the security of the mobile device and the Google app itself.
• Authenticator App (e.g., Google Authenticator, Authy): Generates time-based one-time passwords (TOTP) that users enter. More secure than SMS, as it doesn't rely on cellular networks, but requires manual entry.
• Security Keys (e.g., FIDO2/WebAuthn, U2F): Physical hardware devices that provide the strongest form of 2SV. They are resistant to phishing and man-in-the-middle attacks. Highly recommended for administrators and high-privilege accounts.
• SMS or Voice Call: A one-time code sent via text message or a robotic voice call. While widely available, it's considered less secure due to vulnerabilities like SIM swapping.
• Backup Codes: Single-use codes generated by Google, intended for use when other 2SV methods are unavailable. These should be stored securely offline.

Configuring 2-Step Verification Policies in the Admin Console

Enforcing 2SV across your Google Workspace organization involves navigating the Admin console to set policies that control user enrollment and enforcement schedules.

Initial Setup and Enabling User Choice

Before enforcing 2SV, it's often prudent to allow users a grace period to enroll themselves. This minimizes disruption when mandatory enforcement begins.

1. Navigate to the Google Admin console (admin.google.com).
2. Go to Security → Authentication → 2-step verification.
3. In the "Organization units" section on the left, select your top-level organizational unit (OU) to apply the policy to all users, or select specific OUs for phased rollout.
4. Under "Allow users to turn on 2-Step Verification", ensure this setting is enabled. This allows users to proactively enable 2SV using their preferred method before it becomes mandatory.
5. Optionally, set a "New user enrollment period" if you want new users to have a grace period before 2SV is enforced on them.

Scheduling 2SV Enforcement

The "Enforcement" section is where you define when 2SV becomes mandatory for users who haven't yet enrolled.

1. Within the same 2-step verification settings page, locate the "Enforcement" section.
2. Choose your enforcement state:
   • On: Enforces 2SV immediately for all users in the selected OU who haven't yet enrolled. This is typically used after a communication campaign.
   • On (from date): Allows you to set a future date from which 2SV will be enforced. This is the recommended approach, providing users with a deadline.
   • Off: Disables 2SV enforcement (not recommended for production environments).
3. If choosing "On (from date)", select a specific date and time. Provide ample time (e.g., 2-4 weeks) for users to register their 2SV methods.

Defining Allowed 2SV Methods

This setting determines which 2SV methods users can register and use. For the highest security, especially for administrators, prioritize security keys.

1. On the 2-step verification settings page, scroll down to "Allowed 2-Step Verification methods".
2. Select "Any method". This provides flexibility, allowing users to choose what's most convenient, but also allows less secure options like SMS.
3. For stricter control, or for specific OUs (e.g., administrators), you can select "Security key only" or "Security key or Google Prompt only".
4. Recommendation: For most users, "Any method" is acceptable. For administrators, IT staff, or executive OUs, configure a separate policy for "Security key only" or "Security key or Google Prompt only" to mandate stronger authentication. Create a separate OU for these high-privilege users if one doesn't exist.

# Example: Using the Google Admin SDK API (Python) for programmatic enforcement (Requires Admin SDK and directory API enabled)

# Install required library: pip install google-api-python-client google-auth-oauthlib

# This is a conceptual snippet. Full implementation requires OAuth2 authentication.
# Refer to Google Admin SDK documentation for detailed API calls and authentication flow.

from googleapiclient.discovery import build
from google.oauth2 import service_account

# --- Assume 'service' is an authenticated Google Admin SDK Directory API service object ---
# Example for a specific OU (replace 'ou_id' with actual OU ID)
# enforcement_settings = {
#     "kind": "admin#directory#orgUnit",
#     "twoStepVerification": {
#         "required": True,
#         "enableDate": "2024-03-15T00:00:00Z" # UTC time for enforcement
#     }
# }
# service.orgunits().patch(orgUnitPath='ou_id', body=enforcement_settings).execute()

# Example for updating user 2SV status (requires user consent or domain-wide delegation)
# This snippet helps identify users without 2SV, not directly enforce it via API.
# enforced 2SV is primarily an OU-level policy.

# List users and their 2SV status (conceptual)
# results = service.users().list(customer='my_customer', query='is2svEnforced=false').execute()
# for user in results.get('users', []):
#     print(f"User: {user['primaryEmail']}, 2SV Enforced: {user.get('isEnforcedTwoStepVerification', False)}")

# The primary method for enforcement is via the Admin Console OU policies.
# API is more for reporting or setting user-specific configurations if allowed.

Monitoring and User Communication

Effective communication and monitoring are crucial for a smooth 2SV rollout. Users need to understand why 2SV is being enforced and how to enroll.

Communication Strategy

• Pre-announcement: Inform users well in advance (e.g., 4-6 weeks) about the upcoming 2SV enforcement, its benefits, and the enforcement date.
• Enrollment instructions: Provide clear, step-by-step guides on how to set up various 2SV methods (Google Prompt, Authenticator app, Security Key). Include links to Google's official support documentation.
• Reminders: Send periodic reminders as the enforcement date approaches.
• Support channels: Clearly communicate who to contact (e.g., IT helpdesk) for assistance.

Monitoring User Enrollment

The Admin console provides reports to track 2SV enrollment status:

1. Go to Reports → User Reports → Security.
2. Look for the "2-Step verification enrollment" report. This report shows the percentage of users with 2SV enabled across your organization or specific OUs.
3. You can also download a CSV list of users and their 2SV status for more detailed analysis and targeted communication to non-compliant users.

Pairing 2SV with Context-Aware Access (CAA)

While 2SV is foundational, combining it with Context-Aware Access (part of Google Workspace Enterprise editions and Cloud Identity Premium) significantly enhances security posture. CAA allows you to define granular access policies based on user identity, device security status, IP address, and geographic location.

Example Use Case: Block sign-ins from unmanaged devices.

1. Navigate to Security → Access and data control → Context-Aware Access.
2. Under "Access levels", create a new access level.
3. Define conditions such as "Require approval (via Endpoint Verification)" or "Device policy compliance" (e.g., device ownership, OS type, encryption status).
4. Apply this access level to specific Google Workspace applications (e.g., Gmail, Drive) via Security → Access and data control → Context-Aware Access → Assign access levels.
5. This ensures that even if a user's password and 2SV are compromised, they cannot access sensitive data from an unauthorized or non-compliant device.

Common Pitfalls and Troubleshooting

• Insufficient user communication: Failing to adequately inform users about the enforcement and provide clear instructions will lead to a high volume of support requests and user frustration. Plan communications carefully.
• Lack of backup codes: Users who lose their phone or security key and don't have backup codes will be locked out. Emphasize the importance of generating and securely storing backup codes during enrollment.
• Ignoring high-privilege accounts: While enforcing 2SV for all users is good, administrators and service accounts should have the strongest possible 2SV methods (security keys) and ideally be placed in separate OUs with stricter policies.
• Forgetting "Less secure apps" access: If users rely on older applications that don't support modern OAuth 2.0 authentication (e.g., some legacy mail clients), they will be blocked once 2SV is enforced. Advise them to switch to modern apps or generate app passwords. Admin control over "Less secure apps" access can be found under Security → Access and data control → Less secure app access. Generally, this should be disabled.
• Immediate "On" enforcement: Enabling enforcement without a grace period can lock out a significant portion of your user base, causing a severe productivity impact and helpdesk overload. Always use "On (from date)" with a reasonable lead time.
• Phishing resistance misunderstanding: While 2SV significantly improves security, not all methods are equally phishing-resistant. SMS codes are susceptible to phishing. Educate users about identifying phishing attempts, even with 2SV enabled. Promote security keys for critical users.