Identify the Workspace accounts and the administrator who owns the change
Confirm that these are managed Google Workspace accounts, identify the tenant owner and agree who may change authentication policy. List administrators, staff, external collaborators and other relevant identities separately. Record which organizational units or configuration groups contain them. Do not assume a policy aimed at one department covers a supplier, a separate tenant or every application that accepts another login method.
Establish the change window, user communication and an additional protected administrative route before enforcing anything. Google currently documents administrator-specific 2SV requirements, so an organization's optional staff rollout is not a reason to ignore a provider requirement for administrators. Use the current console and provider guidance for the account type; do not follow an old screenshot that describes a different tenant configuration.
Check the effective policy, not only the selected department
The documented console location is Security, Authentication, 2-step verification, using the required super-administrator authority. Review the targeted organizational unit or configuration group and inherited settings. Google states that group settings override organizational-unit settings. Save a before record of scope and effective settings so a later unexpected result can be traced to the policy actually applying to the user.
Choose permitted methods according to the business's devices, risk and recovery capability. A code, prompt, security key and passkey have different properties and support requirements. Do not force a method that the pilot group cannot register or recover. Describe the expected sign-in and the owner of exceptions before saving a restrictive policy; changing the whole tenant first is not a useful readiness test.
Separate enrollment readiness from enforcement acceptance
Communicate what will change, which method is supported and where employees should get help. Enroll the pilot users and verify their available methods before advancing. Reports can help organize the rollout, but Google notes reporting delays for some enrollment information. Combine reports with current per-user settings and an agreed fresh sign-in test rather than interpreting a dashboard snapshot as immediate proof.
Keep a compact readiness register. For each group, record who owns support, how the required method was demonstrated, the approved recovery route and the acceptance result. Existing sessions or trusted-device behavior can hide what a new sign-in would request. Record those conditions instead of demanding that every existing tab display a second prompt at the same moment.
| Gate | Evidence to collect | Hold the rollout when |
|---|---|---|
| Scope | Effective unit, group and inherited policy. | The intended users or overrides are unknown. |
| Method | Pilot registration and supported devices. | A required method is unavailable to the group. |
| Recovery | Protected alternate admin and verified user-help route. | Only the affected account can authorize recovery. |
| Sign-in | Fresh permitted sign-in under the intended policy. | Enrollment status and actual behavior disagree. |
| Operations | Critical application access and support readiness. | An essential workflow has no accepted access route. |
| Expansion | Named approval and documented exceptions. | A pilot failure remains unexplained. |
Prepare recovery before a person loses the device
Agree how staff will verify themselves through a known support channel and who has the correct privilege to assist. Google's recovery guidance describes backup-code and additional-administrator arrangements, including special conditions for security-key-only policies. Apply the supported procedure to the actual account and policy. Treat recovery codes as secrets and keep them out of shared chat, screenshots and ordinary change records.
A recovery route should remain usable when the main phone or mailbox is unavailable. Walk through that dependency using a test identity or a tabletop exercise first. Keep the distinction between a documented route and a successfully demonstrated route. Moving users into a group without enforcement weakens their protection; it should not become the routine response to every recovery request.
Enforce the reviewed scope and observe the business result
After the readiness gates pass, apply enforcement to the agreed pilot scope and record the effective result. Check the current provider behavior for scheduled enforcement rather than promising an exact minute from a calendar setting. Verify new sign-in, the required method, authorized recovery and representative business applications. Record the tested browser, account and policy so the evidence has a clear boundary.
If the result fails, use the approved administrator and supported recovery process, then investigate the cause. Do not repeatedly remove MFA or broaden exceptions until the symptom disappears. Separate a policy conflict, unsupported client, missing enrollment and suspicious access, because they need different actions. Expand only after the owner accepts the result and unresolved exceptions have an accountable next step.
Maintain the policy through new staff, devices and suppliers
Add enrollment and recovery preparation to onboarding, and review methods and access during departure. Recheck policy inheritance after reorganizing groups. When an application or device changes, confirm that the approved workflow still works rather than assuming a previous pilot covers the new environment. Keep exception ownership and the support route visible to the people who actually operate the tenant.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli knowledge of business email, account security and digital infrastructure. We can scope a Workspace authentication review and supported implementation around your tenant. Scheduling, access and acceptance are agreed before work. The scope connects sign-in protection with the account ownership, application access and recovery your business needs.
