Password Policies and Session Controls for Users

Integrate Context-Aware Access and federated session governance combines short-lived sessions, per-request context checks, and aligned re-authentication between Google and an external identity provider (IdP). Cloud Identity (opens in a new tab) issues cached credentials after login, Chrome Enterprise Premium (opens in a new tab) checks context on every user API request, and VPC Service Controls (opens in a new tab) blocks API traffic that originates outside a defined resource perimeter. Together the three controls limit how long a stolen token stays useful and where that token can be used.

1.1Time-Bound Google Cloud Sessions for Federated Control

Time-bound sessions for Google Cloud services control how long cached Google Cloud credentials remain valid before the user must re-authenticate. New organizations receive a default session length of 16 hours, while organizations created before 2023 may still be set to never require re-authentication. Administrators should enforce a re-authentication policy with a session length between 1 and 24 hours, which forces the user to regularly re-authenticate the gcloud CLI with a password or security key.

Session length for Google Cloud services is distinct from session length for Google services. Session length for Google services controls web sessions for sign-in across Google Workspace services but does not control re-authentication for Google Cloud. Organizations that use Google Workspace must set both values so web logins and Google Cloud API access both expire on a defined schedule.

1.2Per-Request Context Checks with Chrome Enterprise Premium

Per-request context checks with Chrome Enterprise Premium reject user API traffic that does not meet defined context conditions. An administrator configures a Chrome Enterprise Premium access level and binding that allows attributes evaluated on every API request, including IP-based access or certificate-based access for mutual TLS (mTLS). Traffic flows from the user device to the Google Cloud console and Google Cloud APIs, and any request that uses compromised authorization credentials but fails the access-level conditions is rejected at request time.

Chrome Enterprise Premium depends on device and network signals, but not every collected signal is enforced per request. Not all device attributes collected by Endpoint Verification are evaluated during every API request. Administrators should design access levels around attributes enforced per request, such as source IP and client mTLS certificate, rather than assuming every collected posture field will block an active session.

1.3Resource Perimeter Defense with VPC Service Controls

Resource perimeter defense with VPC Service Controls defines service perimeters within which resources can communicate. API traffic flows from the caller to the restricted service only when the traffic originates within the defined perimeter and targets a supported resource. The service perimeter limits the usefulness of compromised credentials because the perimeter blocks requests to restricted services that originate from attacker-controlled endpoints outside the environment.

Chrome Enterprise Premium and VPC Service Controls sit on opposite sides of the trust boundary and apply to different identities:

When used together, the user-centric control rejects the request because device, IP, or certificate does not match, while the resource-centric control rejects the request because the source sits outside the perimeter.

1.4Aligning Google and External IdP Session Lifetimes

Aligning Google and external IdP session lifetimes means the Google Cloud session lifetime and the third-party single sign-on (SSO) IdP session lifetime expire in a coordinated way. The flow starts when the user authenticates to the external IdP, then Cloud Identity or Google Workspace caches Google credentials for the configured Google Cloud session length. When that Google session expires, the cached credentials are automatically invalidated and the next access requires the user to re-authenticate through the external IdP.

Alignment requires configuration on both sides of the federation boundary. Cloud Identity or Google Workspace must limit the session length for Google Cloud services so expiration forces fresh federated authentication. The external IdP must require multi-factor authentication (MFA) and limit its own session length so users must perform MFA every time their Google Cloud session expires. If the external IdP session is longer than the Google session, a user could re-authenticate to Google without a fresh MFA challenge, which defeats time-bound governance.

1.5Continuous Authentication for SSH Sessions

Continuous authentication for SSH sessions adds a human re-authentication checkpoint to Compute Engine operating-system logins. OS Login with 2-Step Verification (2SV) requires the user to re-authenticate with a password or security key each time an SSH connection is established. An attacker with compromised OAuth tokens but no password or security key is blocked by this checkpoint because the SSH path demands a separate human authentication.

Two complementary options extend MFA to remote server access. Traffic that flows from the user through Identity-Aware Proxy (IAP) for network access requires users to periodically perform MFA to refresh their Google credentials before the SSH tunnel is allowed. Access that flows directly to the VM through OS Login 2FA requires MFA on every SSH connection when enabled on individual instances or entire projects. Users with the Compute Instance Admin role or an equivalent role can disable OS Login 2FA by modifying instance metadata, so OS Login 2FA is effective only when MFA is also enforced in Cloud Identity or the external IdP.

Configure password policies and multi-factor authentication enforcement defines strong authentication defaults in Cloud Identity (opens in a new tab) and Google Workspace and forces users to prove identity with more than a password. Password controls reduce the chance that a guessed or stolen password alone grants access, while mandatory 2-Step Verification (2SV) requires a second factor such as a security key or phone prompt. Together with session limits that force periodic re-authentication, these controls govern the full user session lifecycle and limit how long compromised credentials remain useful.

2.1Mandatory 2-Step Verification Enforcement

Mandatory 2-Step Verification enforcement is Google's form of multi-factor authentication (MFA) that protects user accounts after passwords are compromised. Administrators enforce 2SV for all organizational units in the Google Admin console, so no user group is left with password-only sign-in. Security Command Center (opens in a new tab) audits this posture as a HIGH severity finding with category MFA_NOT_ENFORCED across organization, folder, and project resources. Remediation requires turning on enforcement for every organizational unit, not only for privileged users, because any compromised account can become a path to Google Cloud resources.

2.2Passwordless and Strong Authentication Options

Secure passwordless authentication is the preferred alternative to passwords when feasible, with strong passwords plus MFA as the required fallback. The control is audited as MISSING_MFA_OR_PASSWORDLESS_AUTHENTICATION with HIGH severity when neither option is enforced. Administrators configure the choice in the Google Admin console at Security > Authentication > 2-Step verification, where they can require security keys or other phishing-resistant factors. This design treats MFA as a baseline for all human users, while passwordless methods remove the shared secret entirely and further reduce phishing and reuse risk.

2.3Super-Admin Protection and Account Recovery

Dedicated super-admin accounts are separate Cloud Identity or Google Workspace user accounts that hold super-admin privileges for initial configuration and rare recovery tasks. Administrators should keep the set of super-admin holders small, create one dedicated account per administrator, and use those accounts only when elevated privilege is required for business continuity. Every super-admin account must have Google 2-step authentication enforced and must have backup codes created, so access survives loss of a phone or USB security key. Administrators must avoid everyday use of super-admin accounts, which limits exposure of the most powerful credentials to phishing and token theft.

2.4Default Authentication Settings and Inheritance

Default account settings in Cloud Identity and Google Workspace apply secure baselines to new users without per-user configuration. The supported defaults include:

• Enforcing 2-step verification for user sign-in
• Controlling who can access Google Workspace and Google services
• Allowing or disallowing access to less secure apps
• Assigning licenses for Cloud Identity Premium or Google Workspace
• Choosing a geographic location for data and controlling supplemental data storage for Google Workspace

These settings inherit through three levels with increasing priority. A global setting applies to all users but has the lowest priority, an organizational unit (OU) setting applies to all users in that OU and its descendant OUs and overrides the global setting, and a group setting applies to all group members and overrides both OU and global settings. When federating with an external IdP, administrators can keep users in the default OU and control access through dedicated groups provisioned from the external IdP, while Google Workspace workloads that need OU-only settings may still require a simple custom OU structure.

2.5Session Length Controls That Force Re-Authentication

Session length controls that force re-authentication invalidate cached credentials and force users to re-authenticate the gcloud command-line interface (CLI) with a password or security key. New customers receive an automatically enforced default session length of 16 hours for Google Cloud services, while customers that created their Google Cloud organization before 2023 may still have a legacy default to never require re-authentication. Administrators should review the setting and enforce a session length between 1 and 24 hours, which bounds how long an attacker can exploit a compromised token.

The Google Cloud services session is distinct from the Google services session, and both must be set when Google Workspace is in use:

When single sign-on uses an external IdP, Cloud Identity or Google Workspace still limits the Google Cloud session length so cached credentials expire, and the external IdP is configured to require MFA and to limit its own session so MFA recurs each time the Google Cloud session expires.

2.6Extending MFA to SSH and Remote Desktop Access

Extending MFA to SSH and remote desktop access applies second-factor checkpoints beyond web and API sign-in. OS Login with 2-Step Verification extends MFA to Secure Shell (SSH) access to Compute Engine (opens in a new tab) resources by requiring the user to re-authenticate with a password or security key at connection time, so an attacker holding only stolen OAuth tokens without the second factor is blocked. Users with the Compute Instance Admin role or equivalent can disable OS Login 2FA by changing instance metadata, so OS Login 2FA is only effective when MFA is also enforced in Cloud Identity or the external IdP. As an alternative, administrators can route SSH through Identity-Aware Proxy (IAP) to reduce network exposure, which forces users to periodically refresh Google credentials with MFA before reaching the instance.

Remote Desktop Protocol (RDP) to Windows instances does not support the OS Login service, so 2SV cannot be granularly enforced per RDP session. For IAP Desktop or Chrome-based RDP plugins, administrators apply coarse-grained web-session controls through session length for Google services and 2SV settings and disable the Allow user to trust the device option. Disabling device trust prevents a compromised device from bypassing future second-factor prompts during RDP access.

Administering session durations, inactivity timeouts, and token lifecycles limits how long authentication remains valid so cached credentials and OAuth tokens automatically expire and force fresh authentication. In Google Cloud, Cloud Identity (opens in a new tab) controls the maximum session length for Google Cloud services, workforce identity pools and proxies control idle timeout, and perimeter and login checks limit what a stolen token can still do. Shorter lifetimes shrink the window in which an attacker can exploit a compromised token.

3.1Google Cloud Session Length for Console and CLI

Google Cloud session length for console and CLI controls web console sessions and re-authentication for the gcloud CLI. The policy forces the user to re-authenticate with a password or security key after the configured period, which invalidates cached credentials and requires a new multi-factor authentication (MFA) event. For new customers a default of 16 hours is automatically enforced, while organizations created before 2023 may still be set to never require re-authentication and must be reviewed. The allowed session length is between 1 and 24 hours.

This setting is distinct from the session length for Google services, which controls web sign-in across Google Workspace services but does not control re-authentication for Google Cloud. If the organization uses Google Workspace services, both session lengths must be set. Failing to set the Google Cloud services value leaves command-line tokens valid even when Workspace web sessions expire.

3.2Coordinated Lifetimes with an External Identity Provider

Coordinated lifetimes with an external identity provider require matching session policies in two systems. Cloud Identity or Google Workspace must limit the session length for Google Cloud services so cached credentials are invalidated, and the external IdP must require MFA and limit its own session length. When the Google Cloud session expires, the user must re-authenticate through the external IdP, and the IdP then requires a fresh MFA check.

The dependency flows from Google Cloud to the external IdP: Google Cloud session expiry triggers re-authentication, and IdP policy determines whether that re-authentication includes MFA. If only the Google Cloud lifetime is shortened without shortening the IdP lifetime, the user may re-authenticate without a new MFA challenge. Both lifetimes must be aligned so every Google Cloud expiry produces an IdP MFA event.

3.3Idle Locks and Inactivity Timeouts

Idle locks and inactivity timeouts lock or disconnect a session after inactivity even when its maximum lifetime has not yet expired. Workforce identity pools enforce a session lock after 15 minutes of user inactivity, configured with --session-duration=900s, and remote HTTP access enforces disconnection by setting httpKeepAliveTimeoutSec to 900 seconds or less on the target HTTP proxies for Compute Engine instances. The lock temporarily prevents logical access without logging the user out, and the proxy timeout disconnects idle remote access.

A compliant session lock meets all of the following conditions:

• Activates after a maximum of 15 minutes of user inactivity
• Can also be activated on user request at any time
• Completely conceals all information on the screen while locked
• Does not appear to be turned off while in the locked state
• Requires the user to re-authenticate to unlock the system
• Cannot be disabled by the user

Unlock depends on successful re-authentication, and lock events must be monitored through audit logging, communicated to users, and included in deployment pipelines so the 900-second configuration is applied consistently.

3.4Re-Authentication for SSH and Privileged Remote Access

Re-authentication for SSH and privileged remote access is enforced with OS Login with 2-Step Verification (2SV) and Identity-Aware Proxy (IAP). OS Login with 2SV adds a checkpoint where the user must re-authenticate with a password or security key for each SSH connection, so an attacker holding only compromised OAuth tokens without the second factor is blocked. IAP controls network access so users must periodically refresh their Google credentials with MFA to reach the instance.

Two limitations change the design. Remote Desktop Protocol (RDP) to Windows instances on Compute Engine (opens in a new tab) does not support OS Login, so granular 2SV cannot be enforced for RDP sessions and coarse controls such as Google services session length, 2SV settings, and disabling Allow user to trust the device must be used instead. Users with the Compute Instance Admin role or equivalent can also disable OS Login 2FA by modifying instance metadata, so OS Login 2FA is effective only when MFA is also enforced in Cloud Identity or the external IdP.

3.5Limiting the Usefulness of a Compromised Token

Limiting the usefulness of a compromised token uses boundary checks that apply even while a stolen token is still valid. VPC Service Controls (opens in a new tab) is a resource-centric control that defines a service perimeter around supported resources and blocks API traffic to restricted services when the request originates from an attacker-controlled endpoint outside the perimeter. Chrome Enterprise Premium (opens in a new tab) is a user-centric control that evaluates attributes such as IP-based access or certificate-based access for mutual TLS (mTLS) on every API request and rejects user API traffic that does not meet the access level.

When used together, the two controls cover different sides of the same attack: VPC Service Controls stops the request at the resource perimeter regardless of identity type, while Chrome Enterprise Premium stops the user request before it reaches the resource when device or network conditions fail. Neither replaces session expiry, but both contain a compromised token that has not yet expired or been revoked.

Key Facts

• Session length for Google Cloud services defaults to 16 hours for new organizations, allows 1 to 24 hours, and forces gcloud CLI re-authentication, while session length for Google services controls only Workspace web sessions.
• Chrome Enterprise Premium evaluates IP and mTLS certificate conditions on every user API request and covers only user identities, while VPC Service Controls enforces a resource perimeter for all user and service account identities.
• Federated session governance requires limiting the Google Cloud session lifetime and limiting the external IdP session lifetime with MFA so every Google expiry triggers a fresh MFA challenge.
• OS Login with 2-Step Verification requires password or security-key re-authentication on each SSH connection, but users with the Compute Instance Admin role can disable it by changing instance metadata.
• Workforce identity pools enforce a session lock after 15 minutes of inactivity with --session-duration=900s, and HTTP proxies enforce idle disconnection with httpKeepAliveTimeoutSec of 900 seconds or less.