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 — until Enforcement = On, a user with a key registered can still sign in with password plus a weaker factor.
2SV of any strength does nothing about a stolen session cookie — an exfiltrated cookie replays past every factor, so pair with web session length (№12) and the privileged access workstation (№53).

Setup steps

Select the target OU (organizational unit) — start with the admin/high-risk OU, not the root — and open the 2-Step Verification policy.

open ↗

https://admin.google.com/ac/security/2sv · captured 2026-07-15

Security › Authentication › 2-Step Verification

Allow users to turn on 2-Step Verification

On

Deploy 2-Step Verification
Restrict the permitted second factor to phishing-resistant hardware only. This is the control — everything else is ordinary 2SV.

open ↗

https://admin.google.com/ac/users · captured 2026-07-15

Security › Authentication › 2-Step Verification

Methods

Only security key (passkeys/FIDO2 hardware keys)
Turn enforcement on and choose the grace window for newly enrolled users.

Security › Authentication › 2-Step Verification

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

Enforcing on the root OU can strand the tenant — move super admins into a dedicated OU first, and have the №19 break-glass backup codes offline before you flip it.
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.

Security › Authentication › 2-Step Verification

Allow user to trust the device

Off (verification on every sign-in)

Recover an account protected by 2-Step Verification
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.

Reporting › User Reports › Accounts

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.3 Prevent policy #17 · #8 ↗