Prepare and test your skills
Prepare and test your skills
Configure 2SV Enforcement Policies and Rollout Lifecycles is the process that defines who must use a second factor to manage Google Cloud and how accounts move from reminder to enforcement to compliance. 2-Step Verification (2SV) (opens in a new tab) requires a password plus a second authentication factor before an account can access management consoles. Enterprise Cloud Identity (opens in a new tab) and Google Workspace provide the policy boundary, enrollment controls, and session controls that apply enforcement without locking users out during onboarding.
Enforcement scope and trust boundaries separate the Google Cloud control plane that is gated by 2SV from the workload data plane that is not. Accounts subject to enforcement must have 2SV enabled to access the Google Cloud console and the Firebase console, and accounts without 2SV are prompted to enroll before they can proceed. Traffic to applications and workloads running on Google Cloud continues to flow, including traffic to applications secured by Identity-Aware Proxy (IAP), but developers without 2SV cannot use the consoles to manage those applications.
Several access paths sit outside the Google Cloud 2SV requirement:
Accounts with passkeys must still enable 2SV and add an authentication factor. When sign-in comes from an untrusted device without a configured passkey, Google requests the second factor even if the password is known. Accounts federated through a third-party identity provider (IdP) for single sign-on (SSO) can satisfy the requirement with the 2SV provided by that IdP.
Monitoring the enrollment lifecycle links identity eligibility to the account's current enforcement state. The userEmail field identifies the monitored principal by email address, and the mfaEligibility field explains whether the account can enroll. Eligibility depends on identity configuration and the Workspace policy that governs the account, with three values for mfaEligibility: MFA_ELIGIBILITY_ELIGIBLE means the account can enroll, MFA_ELIGIBILITY_INELIGIBLE means organization policy in Google Workspace blocks enrollment, and MFA_ELIGIBILITY_UNSPECIFIED means eligibility is unknown, which is returned when the user authenticates through a third-party IdP using SSO.
The enforcementState field tracks where the account sits in the rollout lifecycle from notification to compliance or exemption. States change in order as deadlines arrive, users enroll, or the organization changes its enforcement choice:
Extending, bypassing, and restoring organization enforcement are organization-level controls that adjust when console access is blocked without removing 2SV from already-enrolled users. These controls apply only to organizations that use Enterprise Cloud Identity without SSO. Principals with the Organization Administrator role (roles/resourcemanager.organizationAdmin) manage these controls on the Organizations page in the Google Cloud console, and changes can take a few minutes to take effect.
Organizations created before August 3, 2026 can receive a one-time, 90-day extension of the 2SV requirement at the organization level. The extension workflow completes in order:
After the extension expires, the 2SV requirement is automatically reenabled. Organizations that use Enterprise Cloud Identity without SSO can also opt out at the organization level by opening the Organizations page, selecting the organization, disabling Enforce 2SV, and allowing time for the change to take effect. Opting out only bypasses the requirement and does not disable 2SV for users who already enabled it. If the organization later opts back in, a minimum 30-day grace period applies before 2SV is required again, which prevents immediate lockout during re-enrollment.
Session length, reauthentication, and administrator hardening control how long authentication remains valid and how privileged accounts are protected. A Google Workspace administrator configures the maximum session length for Workspace user accounts and whether reauthentication is required at expiration, and local Application Default Credentials (ADC) files also expire with the session and must be refreshed with gcloud auth application-default login. For sensitive use cases, the idle session timeout is set to 15 minutes because idle sessions can be used for credential theft, and IAP can separately require reauthentication to protected services after a configured period.
Google Cloud also requires reauthentication before sensitive console actions to protect privileged users against cookie theft. Billing assignment changes and Identity and Access Management (IAM) allow policy changes at the organization, folder, or project level are treated as sensitive actions. Reauthentication is required when all three conditions are met: the action starts in the Google Cloud console, the user has not reauthenticated in the last 15 minutes by password or multifactor authentication (MFA), and the account is managed by Google. Accounts managed by an external IdP and federated with Workforce Identity Federation (opens in a new tab) are not required to reauthenticate, and reauthentication is enabled by default with exceptions handled through support. Administrator enrollment receives additional hardening through hardware security keys, disabled self-recovery for super admin accounts with peer-admin and support-assisted recovery, and post-SSO verification that adds Google risk analysis after external SSO.
Exam tip: Opting out bypasses console enforcement but does not turn off 2SV for already-enrolled users, while the control plane remains gated and the workload data plane remains unaffected.
Evaluate and Mandate Phishing-Resistant Verification Methods is the practice of choosing second factors that cannot be harvested or replayed and requiring the strongest factors for privileged accounts. 2-Step Verification (2SV) (opens in a new tab), also known as multifactor authentication (MFA), requires a password plus a second authentication factor to sign in, so theft of the password alone does not grant access. Accounts with passkeys must still enable 2SV and add an authentication factor, because sign-in from an untrusted device without a configured passkey still triggers a second-factor challenge.
Hardware security keys are physical second factors that provide phishing-resistant protection for Cloud Identity and Google Workspace identities. The key must be present during sign-in to the Google Cloud console or Firebase console, so a remote attacker who harvests a password or intercepts a one-time code cannot complete authentication without the hardware. This property directly counters credential harvesting and man-in-the-middle attacks that succeed against codes sent over phone networks. Google identifies hardware security keys as the strongest possible defense against account takeover and as the layer that builds on a standard MFA policy.
Mandated security-key verification for privileged accounts means requiring super admins and Organization Administrators to use hardware security keys as their second factor. Super admin accounts and Organization Administrator principals are the highest-value targets for sophisticated attacks because they control organization-wide identity, policy, and recovery settings. Google recommends Titan Security Keys (opens in a new tab) for super admin 2SV, with another security key as the alternative when Titan Security Keys are not possible. The mandate eliminates reliance on phone-delivered factors for these accounts, which remain exposed to Signaling System 7 (SS7) interception, SIM swap, compromised phones, compromised email, and social engineering.
| Verification approach | Phishing resistance | Guidance for privileged accounts |
|---|---|---|
| Titan Security Keys | Phishing-resistant, strongest defense against takeover | Recommended second factor for super admin accounts |
| Other hardware security key | Phishing-resistant | Acceptable alternative when Titan Security Keys are not possible |
| Standard MFA with phone-based factor or recovery | Vulnerable to SS7, SIM swap, phishing, and social engineering | Baseline for general users, not sufficient alone for highest-value administrators |
The table shows why privileged accounts move from phone-based MFA to security-key-only verification. Phone-based paths can be intercepted or socially engineered, while the key must be physically present to complete sign-in.
Exam tip: Google recommends Titan Security Keys for super admin 2SV, with another security key as the only stated alternative, because phone-based paths remain exposed to SS7, SIM swap, and phishing.
Blocked self-recovery for super admin accounts removes a phone- and email-based path that attackers can abuse to reset super admin passwords. Cloud Identity disables super admin self-recovery by default for new customers, but existing organizations may still have the setting on in the Google Admin console under account recovery settings. Turning the setting off forces a defined internal process where a locked-out super admin contacts another super admin and uses support-assisted recovery. Complementary session control sets the idle session timeout to 15 minutes for sensitive use cases, because an unattended idle session can be used for credential theft.
Enforced 2SV in Google Cloud applies to the control plane, not the data plane. Accounts subject to enforcement must have 2SV enabled to reach the Google Cloud console and the Firebase console, and accounts without 2SV are prompted to enroll before they can proceed. Applications and workloads running on Google Cloud, including applications secured by Identity-Aware Proxy (IAP), are not blocked by the requirement, but developers without 2SV cannot use the console to manage those applications.
Enforcement scope includes important boundaries that preserve phishing resistance without breaking federation:
Organizations using a third-party identity provider (IdP) for single sign-on (SSO) can satisfy the Google Cloud requirement with the IdP's 2SV, while organizations using Enterprise Cloud Identity without SSO enforce 2SV directly in Google.
Layered risk-based checks around security keys restrict where a stolen session or key can be used and force fresh proof of identity before sensitive changes. Post-SSO verification applies Google's sign-in risk analysis after external IdP authentication, so users see additional login challenges when Google determines a sign-in is suspicious. Context-Aware Access creates granular policies for the Google Cloud console and Google Admin console based on user identity, location, device security status, and IP address.
Reauthentication for sensitive actions protects privileged users against cookie theft in the console. The sensitive actions are billing assignment changes and Identity and Access Management (IAM) allow policy changes at the organization, folder, or project level. Reauthentication is required when all of the following are true:
Reauthentication for sensitive actions is enabled by default, with exceptions available only through support, so privileged operations always re-establish the phishing-resistant identity shortly before the change is applied.
Manage Account Recovery and Monitor Verification Compliance is the operational practice of keeping users signed in during credential loss while proving that 2-Step Verification (2SV) remains enforced. In Cloud Identity (opens in a new tab) and Google Workspace, recovery is controlled by account-recovery policies and security-code options, enrollment is controlled by enforcement and grace-period policies, and compliance is verified through credential-strength signals and threat findings that detect when verification is weakened or disabled.
Account recovery policy controls determine whether locked-out administrators and users can regain access to their Google accounts. Super Admin Account Recovery uses the Policy API setting type security.super_admin_account_recovery with the caption Allow super admins to recover their account, while User Account Recovery uses security.user_account_recovery with the caption Allow users and non-super admins to recover their account. Both settings share the Policy API field name enableAccountRecovery with a boolean data type, where true allows recovery and false blocks it. The Policy API table marks mutate as not supported for both settings, so the documented control point is the Admin console policy rather than a direct API mutation.
| Recovery scope | Policy API setting type | Admin console caption |
|---|---|---|
| Super admins | security.super_admin_account_recovery | Allow super admins to recover their account |
| Users and non-super admins | security.user_account_recovery | Allow users and non-super admins to recover their account |
Both rows use the boolean field enableAccountRecovery, which keeps the recovery decision separate for highly privileged super admins versus the general user population.
Security-code and backup-code options provide temporary verification paths when a user loses a phone, security key, or authenticator. The Security Codes setting uses the Policy API field securityCodeOption with three allowed values that bound how administrators can issue fallback access:
ALLOWED_WITH_REMOTE_ACCESS permits security codes with remote access.ALLOWED_WITHOUT_REMOTE_ACCESS permits security codes without remote access.CODES_NOT_ALLOWED blocks security codes entirely.Backup verification is also governed by backupCodeExceptionPeriod, listed as 2-Step Verification policy suspension grace period with a Duration data type. The credential-strength value otp covers one time password methods, explicitly defined as Google Authenticator and Backup Codes, so backup-code sign-ins remain distinguishable from password-only sign-ins in access decisions.
Enrollment enforcement and grace-period tracking define who must use 2SV, when enforcement starts, and how much time new users have to enroll. Authentication policy security.two_step_verification_enrollment uses the boolean field allowEnrollment for Allow users to turn on 2-Step Verification. Enforcement policy security.two_step_verification_enforcement uses the Timestamp field enforcedFrom to record when enforcement begins. New user enrollment period policy security.two_step_verification_grace_period uses the Duration field enrollmentGracePeriod to allow a limited enrollment window before enforcement applies, which prevents lockout during onboarding.
Enrollment tracking also includes device and method restrictions. The device-trust policy security.two_step_verification_device_trust uses the boolean field allowTrustingDevice for Allow user to trust the device. The methods policy security.two_step_verification_enforcement_factor uses the enum field allowedSignInFactorSet with the values ALL, PASSKEY_ONLY, PASSKEY_PLUS_SECURITY_CODE, PASSKEY_PLUS_IP_BOUND_SECURITY_CODE, and NO_TELEPHONY, which lets administrators narrow enforcement from all factors down to passkey-centered or non-telephony sets.
Credential-strength signals let Access Context Manager (opens in a new tab) enforce 2SV at the identity perimeter by checking how the user authenticated. A custom access level evaluates Common Expression Language (CEL) expressions against request.auth.claims.crd_str, and the condition must resolve to a single boolean value. The supported strength values divide authentication into password versus second-factor proof: pwd means password, push means push notification to the mobile device, sms means code sent by SMS or phone call, swk means software key such as a phone as security key, hwk means hardware key such as Google Titan Key, otp means one time password methods defined as Google Authenticator and Backup Codes, and mfa means any method in this set except pwd.
A custom access level that requires strong authentication is created through an ordered workflow in Advanced Mode:
request.auth.claims.crd_str.mfa == true or request.auth.claims.crd_str.hwk == true.Trusted-device behavior changes what credential strength is reported. When users can mark a device as trusted, a later sign-in on the same device may skip the second-step challenge, and Google then correctly reports that sign-in as password-only rather than multi-factor authentication because no second challenge occurred. If applications or workflows depend on always requiring strong credentials, disabling the trusted-device feature forces users to present second factors on every sign-in, even on frequently used devices, and users may need to sign out and sign back in for the most recent sign-in to carry multi-factor assertions.
Exam tip: A trusted-device sign-in without a fresh second-factor challenge reports pwd == true, not mfa == true; require a new sign-in after disabling trusted devices to restore multi-factor assertions.
Verification-exception detection uses Security Command Center (opens in a new tab) Event Threat Detection findings to flag persistence techniques that weaken authentication. The finding Persistence: Two Step Verification Disabled fires for Google Workspace when 2SV is turned off, while Persistence: Strong Authentication Disabled fires when strong authentication is turned off. Related identity-perimeter changes are covered by Persistence: SSO Enablement Toggle and Persistence: SSO Settings Changed, which signal single sign-on modifications that can bypass or alter expected verification paths. Together, these findings let reviewers trace an enrollment-compliance gap from a policy setting to the specific authentication exception that created it.
Google Cloud 2-Step Verification enforcement requires 2SV to access the Google Cloud console and the Firebase console and prompts unenrolled accounts to enroll before they can proceed. Workloads and applications secured by Identity-Aware Proxy continue to serve traffic, while Google Workspace including Gmail, Google Drive, Google Sheets and Google Slides, YouTube, and the gcloud CLI sit outside that console requirement.
Organizations that use Enterprise Cloud Identity without single sign-on and have the Organization Administrator role can manage enforcement on the Organizations page, with changes taking a few minutes to take effect. Organizations created before August 3, 2026 can receive a one-time 90-day extension that is automatically reenabled after expiration, can opt out by disabling Enforce 2SV without disabling 2SV for already-enrolled users, and face a minimum 30-day grace period before 2SV is required again when opting back in.
Hardware security keys provide phishing-resistant protection because the key must be present during sign-in, so a remote attacker with a harvested password or intercepted one-time code cannot complete authentication. Titan Security Keys are the recommended second factor for super admin accounts, with another hardware security key as the alternative, because phone-based factors remain vulnerable to Signaling System 7 interception, SIM swap, compromised phones, compromised email, and social engineering.
An enterprise uses Cloud Identity to govern administrative access to Google Cloud projects hosting mission-critical workloads. A recent internal red-team assessment demonstrated that threat actors could execute adversary-in-the-middle (AitM) reverse-proxy phishing attacks to intercept session cookies and bypass standard multi-factor authentication methods, such as SMS codes and mobile authenticator push prompts.
The security architect must enforce an authentication policy for all privileged administrators that eliminates credential harvesting and AitM relay attacks.
Which 2-Step Verification (2SV) configuration should the architect implement?
Last updated