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

> v0.1.3 · role: Prevent · [policy: #17 · #8](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

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](https://knowledge.workspace.google.com/admin/security/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.
- 'Only security key' excludes Google prompt and TOTP — enforce it before every user holds two keys and you will lock people out; the second key is the recovery plan.
- 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 (№51).
- Enforcing on the root OU can strand the tenant — move super admins into a dedicated OU first, and have the №20 break-glass backup codes offline before you flip it.

## Setup steps

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

   - **Allow users to turn on 2-Step Verification** = On

   docs: [Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification)

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

   - **Methods** = Only security key (passkeys/FIDO2 hardware keys)

   docs: [Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification)

3. 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)

   docs: [Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification)

4. 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)

   docs: [Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification) · [Recover an account protected by 2-Step Verification](https://knowledge.workspace.google.com/admin/security/recover-an-account-protected-by-2-step-verification)

5. 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

   docs: [User reports: Accounts](https://knowledge.workspace.google.com/admin/reports/user-reports-accounts) · [Manage a user's security settings](https://knowledge.workspace.google.com/admin/security/manage-a-users-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

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

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

   ```
   gam print users fields primaryEmail,isEnrolledIn2Sv,isEnforcedIn2Sv
   ```

## Settings screens

- Security > Authentication > 2-Step Verification
  - console: https://admin.google.com/ac/security/2sv
  - screenshot: ../screenshots/admin.google.com/ac/security/2sv.png
- Directory > Users (per-user 2SV status under [user] > Security)
  - console: https://admin.google.com/ac/users
  - screenshot: ../screenshots/admin.google.com/ac/users.png