Phishing-Resistant MFA in Google Workspace: The Admin Console Rollout Plan

We onboard a lot of small businesses that already know passkeys and security keys beat passwords, and that phishing-resistant sign-in is where MFA is heading. What we get asked less often is the practical question: how do you actually turn this on in Google Workspace without locking out half the office on a Tuesday? This is the rollout plan, not the explainer. If you want the plain-language case for passkeys first, start with our passkeys and passwordless authentication post; if you have not yet worked through the baseline Workspace settings, read our Google Workspace security settings guide first. This post picks up where both leave off: the Admin console screens, the order of operations, and the exceptions that keep a real rollout from breaking.

Why text codes and push approvals are the weak link

Text message codes and app-based push approvals are still MFA, and still better than a bare password. But both share the same flaw: they can be phished in real time. A fake login page can relay a stolen password to the real Google sign-in page, prompt the victim for their code, and forward it before it expires. Push approvals have their own failure mode: an attacker who already has a password can keep sending approval requests until someone taps "yes" out of habit, a pattern we cover in our MFA fatigue and push-bombing post. Security keys and passkeys close both gaps, because the browser and operating system check that the site requesting the credential matches the exact domain it was registered to. There is no code to read out, no prompt to tap by accident, and nothing for a convincing fake page to capture.

Step 1: Notify users and set an enrollment period

Google Workspace's 2-Step Verification (2SV) settings live in the Admin console under Security › Authentication › 2-step verification. Before enforcing anything, tell your team what's changing, whether it's required or optional for now, and by what date. Then turn on Allow users to turn on 2-Step Verification for the organization, or the specific organizational unit you're starting with, so people can begin registering a security key or passkey voluntarily.

When you're ready to require it, the Enforcement setting offers a new user enrollment period of one day up to six months. During that window, a newly enrolled or newly hired user can still sign in with just their password while they get their key registered, which avoids the classic mistake of flipping enforcement on for everyone at once and generating a wave of lockout tickets the same afternoon. Give your team real time to enroll, and track enrollment status under Reporting before you move to enforcement. Google's own 2-Step Verification deployment guide walks through each of these screens in order.

Step 2: Enforce security keys and passkeys only, admins first

The Methods setting under 2-step verification enforcement offers three options: Any method, Any except verification codes via text or phone call, and Only security key. That last option is the one that matters here. Since Google added passkey support, "Only security key" now accepts both physical security keys and passkeys, and both carry the same phishing-resistant protection, so you don't have to choose between them at the policy level.

Roll it out narrowest first. Apply "Only security key" enforcement to an organizational unit containing just your admin accounts, confirm those users already have a key or passkey registered, then expand the same setting to everyone else once the admin group is clean. Check who already has a key or passkey registered before you flip this switch: report data can lag by up to 48 hours, and anyone unregistered is locked out the moment enforcement takes effect. If you select "Only security key," you also set a 2-Step Verification policy suspension grace period, which lets a user who's lost their key sign in temporarily with a backup verification code that only an admin can generate for them. Users can't generate their own backup codes under this mode, which keeps a stolen password from being enough on its own even during a recovery scenario.

Separately, Google is phasing in mandatory 2-Step Verification for administrator accounts across Workspace, independent of anything you configure yourself, with timing that varies by organization; check the notice in your Admin console for the enforcement date that applies to you, and see Google's 2SV enforcement for admins guide for how the notice period and cutoffs work. Getting ahead of that with your own "Only security key" policy for admins means this deadline arrives as a non-event rather than a scramble.

Step 3: Enroll high-risk users in the Advanced Protection Program

Some accounts are worth protecting beyond standard enforcement: super admins, anyone with access to banking or payroll, and anyone who's been individually targeted before. For those accounts, Google's Advanced Protection Program, found under Security › Authentication › Advanced Protection Program, is a curated bundle of the strongest available policies rather than a setting you assemble piece by piece. It enforces security key or passkey sign-in on its own terms, which take precedence over your general 2SV policy if the two ever disagree, restricts which third-party apps can touch that user's account data, turns on deeper scanning of incoming mail for phishing attempts, and adds stricter, admin-mediated account recovery if the person ever loses their key. Google's Advanced Protection Program guide lists the full set of policies it applies.

Enabling user enrollment is an admin-level toggle; each qualifying employee then enrolls themselves once they have a security key or passkey and a backup recovery method, a second key, or a recovery phone and email, ready to register. It's a heavier lift than baseline "Only security key" enforcement, which is exactly why it's worth reserving for the handful of accounts where a successful attack would do outsized damage, rather than rolling it out to everyone on day one.

Step 4: Backup keys and recovery, before you need them

Every phishing-resistant rollout eventually runs into a lost key, a broken phone, or a new laptop with no registered credential yet. Plan for it up front instead of discovering the gap during an actual lockout. Have every enrolled user register a second key or passkey as backup, stored somewhere other than with the primary device, and confirm the recovery phone number and email are current on any account enrolled in Advanced Protection. For everyone else under standard "Only security key" enforcement, remember that backup verification codes must come from an admin, not the user, so decide now who owns that request queue and how you'll verify a caller's identity before handing one out. A backup code is a bypass of the very control you just rolled out, and it should never be issued on the strength of a phone call alone.

Step 5: Extend it with Google Workspace as the identity provider

Phishing-resistant sign-in is only as valuable as the number of places it actually applies. Once 2SV enforcement is solid, the highest-leverage next move is making Google Workspace the single sign-on identity provider for whatever other business apps your team uses, rather than letting each one keep its own separate password. Google offers preintegrated single sign-on with a large catalog of popular cloud apps, and for anything not already in that catalog, the Admin console lets you add a custom SAML application under Apps › Web and mobile apps › Add App › Add custom SAML app, generating the identity provider details a vendor needs to connect; Google's custom SAML app setup guide covers the field-by-field walkthrough. Once an app authenticates through Google Workspace instead of its own login form, the same security-key or passkey requirement that protects Gmail now protects that app too, without asking anyone to register a second credential somewhere else. It also makes offboarding simpler: disable one account and access to everything connected through it goes with it.

Exceptions for contractors and legacy systems

Not everything will be ready on day one, and a rollout that ignores that will generate more support tickets than security value. Contractors who only need occasional access, and vendor portals or line-of-business software that hasn't added security key or passkey support yet, are the two most common exceptions. Handle both the same way: keep them in a separate organizational unit under standard 2SV enforcement, not "Only security key," until the app catches up or the engagement ends, and review that exception list on a schedule rather than letting it become permanent by default. An exception that never gets revisited is just a second, weaker policy running quietly next to your real one.

A realistic rollout timeline for a 10-person team

• Week 1: Announce the change, turn on "Allow users to turn on 2-Step Verification," and confirm everyone has a passkey-capable device or a physical security key.
• Week 2: Register security keys or passkeys for admin accounts and any Advanced Protection candidates, then move the admin organizational unit to "Only security key" enforcement with a short grace period.
• Weeks 3 to 4: Walk the rest of the team through registering a key or passkey during normal check-ins, tracking enrollment under Reporting the whole time.
• Week 5: Move everyone else to "Only security key" enforcement, with contractors and any unsupported vendor apps carved into their own exception group.
• Week 6 and after: Connect other business apps to Google Workspace as the identity provider, starting with whichever one holds the most sensitive data.

How Ghosxt does this

This is one of the identity rollouts we handle directly: Google Workspace as the identity provider, with phishing-resistant sign-in enforced across it and connected apps, so the strongest available protection covers everything your team touches rather than just the inbox. See current pricing for what that costs depending on team size. If you're specifically running Google Workspace for a nonprofit or a fully remote Mac-first team, our IT support for nonprofits on Google Workspace and managed IT for remote Mac teams pages cover those setups in more detail.

Frequently asked questions

What's the difference between enforcing 2-Step Verification and enforcing security keys only?

Standard 2-Step Verification enforcement in Google Workspace requires a second factor but lets users choose any method, including a text message code or the Google prompt. The "Only security key" enforcement option removes that choice and requires a registered security key or passkey before someone can sign in, which is the setting that actually delivers phishing-resistant sign-in rather than just a second factor.

Do passkeys count as a security key for Google's enforcement setting?

Yes. Since Google added passkey support, the "Only security key" enforcement option accepts both physical security keys and passkeys, and Google treats them as carrying the same phishing-resistant protection, so an admin does not have to choose one technology over the other at the policy level.

What happens if an employee loses their only security key?

Under "Only security key" enforcement, a locked-out user cannot generate their own backup verification code; an admin has to generate one for them, which is exactly why Google lets you set a grace period when you turn enforcement on. It is also why every enrolled user should register a second backup key or passkey up front instead of relying on a single device.

Can contractors keep using text-message codes or app-based approvals during the rollout?

Yes, as long as they sit in a separate organizational unit under standard 2-Step Verification enforcement rather than "Only security key." That keeps the exception visible and contained instead of quietly weakening the policy for everyone, and it should be reviewed on a schedule rather than left in place indefinitely.

Does enforcing security keys in Google Workspace protect the other business apps we use?

Only if those apps sign in through Google Workspace. Setting up Google Workspace as the single sign-on identity provider for a preintegrated app, or as a custom SAML app for one that is not in the catalog, means the same security-key or passkey requirement applies there too, instead of leaving each app's own login form as a separate, weaker door into the same data.

Prefer to talk first? Email sales@ghosxt.com or call (831) 204-0501.