7 Phishing-resistant 2SV (FIDO2/passkeys only)

Restricts the permitted second factor to FIDO2 security keys and passkeys, which sign a challenge bound to the site's real origin. A fake login page therefore cannot relay the factor — which is what defeats the credential-phishing kits that happily replay a Google prompt or a TOTP code. Everything else on the 2SV methods list is ordinary 2SV; 'Only security key' is this control.

Documentation: Protect your business with 2-Step Verification ↗

Caveats

Registering a factor is not enforcement¹
‘Only security key’ excludes Google prompt and TOTP²
2SV of any strength does nothing about a stolen session cookie³
Enforcing on the root OU can strand the tenant⁴

Setup steps

open ↗
https://admin.google.com/ac/security/2sv · captured 2026-07-15
Security › Authentication › 2-Step Verification
Select the target OU (organizational unit) — start with the admin/high-risk OU, not the root — and open the 2-Step Verification policy.

Allow users to turn on 2-Step Verification
On

Deploy 2-Step Verification ↗
open ↗
https://admin.google.com/ac/users · captured 2026-07-15
Security › Authentication › 2-Step Verification
Restrict the permitted second factor to phishing-resistant hardware only. This is the control — everything else is ordinary 2SV.

Methods
Only security key (passkeys/FIDO2 hardware keys)

Deploy 2-Step Verification ↗
Security › Authentication › 2-Step Verification
Turn enforcement on and choose the grace window for newly enrolled users.

Enforcement = On; New user enrollment period = 1 day (the shortest option; the range runs 1 day to 6 months)

Deploy 2-Step Verification ↗
Security › Authentication › 2-Step Verification
Disable trusted-device persistence, so a stolen laptop cannot skip the second factor. When a key is lost, recovery is per-user: an admin issues a backup verification code from Directory > Users > [user] > Security.

Allow user to trust the device
Off (verification on every sign-in)

Deploy 2-Step Verification ↗ Recover an account protected by 2-Step Verification ↗
Reporting › User Reports › Accounts
Before flipping enforcement, open the Accounts user report, scope it to the target OU, and confirm every member is enrolled with at least two security keys (primary + backup). Spot-check individuals under Directory > Users > [user] > Security.

Columns '2-Step Verification enrollment' and '2-Step Verification enforcement' → no user in the OU may show Not Enrolled

User reports: Accounts ↗ Manage a user's security settings ↗

Ongoing maintenance

requires a human On every hire into the enforced cohort: issue two keys (or platform passkeys plus a hardware backup) before their first day.

How to verify

From a test account in the enforced OU, attempt to enrol a TOTP authenticator app — the console should offer security keys / passkeys only.

Cross-check enforcement state for the OU’s users.

gam print users fields primaryEmail,isEnrolledIn2Sv,isEnforcedIn2Sv

v0.1.3Prevent policy #17 · #8 ↗