The request arrives as a checkbox. A twelve person firm wants two factor on everyone, and the setting is right there in the Admin console. What goes wrong is never the checkbox. It is the sales lead who verifies with a text message that will no longer be accepted, the office scanner that has been sending signed documents with a password for years, and the only super administrator account belonging to the owner, who is travelling on the day enforcement lands.
Enforcement is a deadline, not a feature. From the moment it applies, an account with no second step cannot sign in, and the way back in runs through an administrator. So almost all of the work happens before you touch the setting. This is the order we use on client projects, and the three places small teams get caught.
What enforcement actually does
Two separate switches live in the same place: in the Admin console, go to Security, then Authentication, then 2-Step Verification. Only super administrators can change them.
The first switch lets people turn on 2SV voluntarily. The second, Enforcement, makes it a condition of signing in. Enforcement has two shapes. On starts immediately. Turn on enforcement from date takes a start date, and Google is explicit that the dated option is approximate: enforcement begins within 24 to 48 hours of the date you pick. If you need a precise moment, because you want someone at a desk to answer the phone when it happens, use On. During a dated window users see reminders to enrol when they sign in, and Google may email them too.
Either switch can be scoped to an organizational unit instead of the whole domain, which is what makes a staged rollout possible. One more thing to know before you plan: Google's admin help page on 2SV enforcement for admins states that Google is requiring 2SV on administrator accounts, rolled out gradually, and that during its notification period Google's policy supersedes any policy you have set. Checked 6 November 2026. Administrator accounts are already on a clock that is not yours.
Before the setting: find out who is already enrolled
The report sits under Reporting, then User Reports, then Security, and it needs the Reports administrator privilege. Add the 2-Step Verification enrollment column, and the 2-Step verification enforcement column if you also want to see who a policy already covers.
Read it as a lagging snapshot. The same help page says the data could be delayed up to 48 hours and points you to a user's own security settings page for real time status; Google's data retention and lag times page gives a wider figure for the same report, 1 to 5 days. Use the report to see the shape of the problem, then check people one by one on their user page in the days before enforcement, because that is the number that decides who can sign in on the morning.
If you intend to disallow text message and phone call codes, find the people using them first. Google points at the login_verification event in the Login audit log for exactly this.
The rollout we run, in order
Six steps. The third column is what tells you it is safe to move on.
| Step | What we change | What we check before moving on |
|---|---|---|
| 1. Announce | Turn on the voluntary setting domain wide and name the enforcement date in writing | Nobody can be locked out yet. The announcement says the date, the methods allowed and who to call |
| 2. Administrators first | Enrol every admin account with a phishing resistant method, plus a spare key or passkey each | Each admin account reads as enrolled on its own user page, not only in the report |
| 3. Second way in | Add a second super administrator and confirm recovery details on both accounts | The second person signs in to the Admin console today, not in theory |
| 4. Rehearsal | Enforce on one organizational unit: a small team sitting within reach of help | That unit is fully enrolled, and the Login audit log shows no new verification failures |
| 5. The rest | Enforce on the remaining units, with a short new user enrollment period set | Every straggler is either enrolled or parked in a group where 2SV is not enforced |
| 6. Tighten | Restrict the allowed methods once nobody depends on texts or phone calls | The Login audit log no longer shows text message or phone call verifications |
Choosing which second steps to allow
Google gives three options for the methods people may use: Any; Any except verification codes via text, phone call; and Only security key.
The middle one is the common upgrade and the common accident. Google warns plainly that users who verify with texts and phone calls will be locked out, which is why step 6 comes after the audit log is clean.
Only security key is the strict setting, and it is broader than its name suggests: Google's deployment guide says the option now supports passkeys as well as security keys, and that passkeys and security keys have the same level of phishing protection. Two consequences come with it: you have to set a grace period for lockouts, and users cannot generate their own backup verification codes, so an administrator has to hand them over.
Security codes exist for devices where a key cannot be used directly. Google's guidance is that using keys or passkeys directly gives maximum protection against phishing, so we enable security codes only where one device forces the issue, and we write down which one.
Passkeys are a second step first and a password replacement second
These are two different changes and they get confused constantly. A passkey used as a 2SV method needs no extra setting at all. Letting someone sign in without typing a password is separate: Security, then Authentication, then Passwordless, and it needs the Security Settings administrator privilege. It is off by default, and off means people can still create and use passkeys as a second step.
Two details decide how that pilot goes. The admin setting is only half of it: each user also has to turn on skip passwords and add a passkey on their own account, and their existing password is not removed. And users do not need to be enrolled in 2SV to skip passwords with a passkey, which is precisely why we finish the enforcement work first instead of treating passkeys as a way around it.
If Passwordless is turned off later, nobody can skip the password any more, but their passkey still works as a second step. Two limits: Google Credential Provider for Windows does not support passwordless sign in, and Workspace Guests always sign in with a password.
What breaks the week you enforce it
The printer. Reliably the printer, and with it the scanner, the accounting machine and any old script that sends mail with a username and password. Since 1 May 2025, Workspace accounts no longer support less secure apps, third party apps or devices that ask you to sign in with a Google username and password, so those clients need OAuth. Where a device authenticates directly and 2SV is on, Google documents the symptom as an authentication error and the fix as an app password: a 16 digit passcode that can only be created on an account with 2SV turned on. For older printers and scanners that cannot do OAuth at all, Google's recommended option is SMTP relay instead.
Build that inventory before enforcement day. App passwords a user already holds are listed on their page in the Admin console, and both you and the user can revoke them, which makes that list a map of what is about to break.
Moving a device from direct sign in to SMTP relay also changes the path your mail leaves the building by, so your SPF record has to cover the new one. Check the domain still authenticates before the next invoice run, not after a customer says the receipt never arrived.
The recovery paths to have ready before the date
Backup verification codes. Open the user in the Admin console, go to Security, then 2-Step Verification, then Get backup verification codes, and read one code to the person. Users cannot generate these for themselves. A new set invalidates any existing code, and the window for using them starts when you generate them, so these are made on the day they are needed rather than filed away. Only a super administrator can generate codes for another administrator.
More time, with a name. Google's documented way to give a straggler longer is to add them to a group where 2SV is not enforced. That is better than postponing the whole rollout, and because it is a group you can see who is in it and empty it later.
Then the one nobody plans for: the only super administrator is the person locked out. Recovery runs through Google's administrator recovery path, which asks you to prove you own the domain with a CNAME record and contacts the existing administrators first. It works and it is slow. Prevention costs almost nothing: more than one super administrator, a spare security key kept somewhere safe, and the knowledge that only another super admin can issue codes for an admin account.
What we watch in the month after
Four things, in this order. Enrollment reaching everyone, read on user pages rather than from the report. New hires, who are the usual leak: the new user enrollment period is optional and can be set anywhere from 1 day to 6 months, and during it a new account signs in with a password alone, so a generous one quietly undoes the policy for every person you hire. The app password list shrinking as devices move to OAuth or to relay. And a calendar reminder to confirm the second super administrator account still signs in, because the day you need it is a bad day to find out.
Worth saying plainly: a second step raises the cost of a stolen password, and it does not make an account unphishable. We have written up a real takeover that got past 2FA, and phishing resistant methods are the part of this rollout that actually answers it.
How Guanacos Tech helps
We run this as a short project: an inventory of who verifies how, administrator accounts hardened first, one unit enforced as a rehearsal, then the rest with recovery in place, and the devices sorted before they break. If you would rather the rollout passed without a morning of locked out staff, that is the work we do as Google Workspace consultants. A 30 minute call is enough to tell you which of your accounts would be locked out if you enforced it tomorrow.
Sources
- Deploy 2-Step Verification, Google Workspace Admin Help
- Avoid account lockouts when 2-Step Verification is enforced by your organization
- About 2SV enforcement for admins
- Manage a user's security settings (backup verification codes, app passwords)
- Allow users to skip passwords at sign-in
- User reports: Security (2-Step Verification enrollment column)
- Send email from a printer, scanner, or app
- Recovering administrator access to your account