2FA in Google Workspace: 2-step verification and security keys
By Kike Gandia · Co-Founder & CEO, OSCP
2-step verification is the single measure that stops the most attacks in Google Workspace, but not all methods protect equally. This guide explains how to roll out 2SV across the organization and why security keys and passkeys are far superior to SMS.
Why 2FA is the most cost-effective defense
Credential theft via phishing is the main entry vector into cloud environments. 2-step verification (2SV) blocks the vast majority of unauthorized access even if the password is leaked, because the attacker also needs the second factor. It is by far the measure that prevents the most incidents per euro invested.
Why SMS isn't enough
Not all second factors protect equally. SMS codes are vulnerable to SIM swapping and interception, and both SMS and TOTP codes can be captured in real-time phishing attacks (adversary-in-the-middle). Physical security keys (FIDO2) and passkeys are phishing-resistant because they're bound to the legitimate domain.
How to enforce 2SV across the organization
From the admin console you can make 2SV mandatory for all users, with an enrollment period for them to sign up. It's best to start with administrators and high-value accounts, define controlled exceptions only when essential and monitor that no users are left without a second factor.
Security keys and passkeys for administrators
For the most sensitive accounts (super admins, finance, management) it's advisable to require security keys or passkeys, and ideally enroll them in Google's Advanced Protection Program. This practically eliminates the risk of credential phishing on the accounts whose compromise would be most severe.
Which second factor to choose for each profile
You do not have to roll out the same method to everyone. The sensible approach is to require the strongest option where a compromise hurts most, and enforce a decent minimum everywhere else.
| Method | Phishing-resistant? | Works without signal? | Recommended for |
|---|---|---|---|
| FIDO2 security key | Yes | Yes | Super admins, finance and management |
| Device passkey | Yes | Yes | Staff with managed corporate devices |
| Google Prompt | No | No, needs a data connection | Acceptable minimum for the rest of the workforce |
| TOTP code from an app | No | Yes | Alternative when there is no corporate phone |
| SMS or voice code | No | No | Temporary fallback only, never the primary method |
| Backup codes | No | Yes | Recovery, stored offline |
The column that matters is the first one: only FIDO2 keys and passkeys are cryptographically bound to the legitimate domain, so a real-time phishing proxy cannot replay them. Every other method can be captured and reused within seconds.
The gap 2SV leaves: app passwords and legacy protocols
Enforcing 2SV does not close every door. App passwords are credentials generated for clients that cannot perform 2-step verification —old IMAP, POP and SMTP clients, a scanner, a CRM— and they authenticate without any second factor. If an attacker obtains one, your security key rollout does not affect them at all.
After making 2SV mandatory, do three more things: inventory the app passwords that already exist and who uses them, disable the ability to create new ones from the admin console, and restrict IMAP and POP access to the users who genuinely need it. The same reasoning applies to service accounts with domain-wide delegation: they reach mailboxes over the API without passing any second factor.
FAQ
Can I force all employees to use 2FA?
Yes. From the admin console you can apply mandatory 2SV at the organization or organizational unit level, with an enrollment period. It's the recommended configuration for any company.
What happens if an employee loses their key or phone?
It's handled with backup codes generated in advance and an admin-controlled recovery process. It's worth having that procedure defined before making 2SV mandatory.
How long does it take to roll out mandatory 2SV across a company?
The technical switch is immediate: enforcement is enabled per organizational unit from the console. What actually sets the calendar is the enrollment period you give users, the inventory of accounts that cannot hold a conventional second factor, and buying and distributing keys if you plan to use them. That preparation is what gets planned; the configuration itself is not the bottleneck.
Can it be enforced without disrupting operations?
Yes, in phases. The usual approach is to start with IT and administrators, continue with the highest-risk organizational units and finish with the rest, with an enrollment period for each wave. Unavoidable exceptions are grouped, documented and given an expiry date, so they do not quietly become permanent.
What about shared mailboxes and service accounts?
A generic account cannot safely custody a second factor, so the answer is not to exempt it. The right move is to remove interactive sign-in and grant access through mailbox delegation to named people, each with their own 2SV, or through a service account with narrowly scoped permissions. Leaving a shared account with a password and no second factor leaves exactly the door an attacker looks for.
Does 2SV protect IMAP, POP or SMTP access?
No. Those protocols authenticate with an app password and never pass through 2-step verification. If you have them open, treat them as a separate channel: restrict who can use them, review existing app passwords and disable their creation where they are not essential.
Related service
Google Workspace security audit
Related content
- Google Workspace hardening checklist
- Super admins in Workspace
- Google Workspace security for businesses