Google Cloud Identity Explained for GCP: Users, Groups, MFA, and SSO

Cloud Identity in plain terms

The simplest way to understand Cloud Identity is to separate two things that are easy to confuse:

• Cloud Identity answers: who are you, and can you sign in? It manages user accounts, groups, passwords, MFA requirements, and how your company’s identity provider connects to Google.

• IAM answers: what are you allowed to do? It binds roles and permissions to the identities Cloud Identity provides.

They work together, but they are not the same thing and you cannot replace one with the other. A broken sign-in is a Cloud Identity problem. A permission denied error on a GCP API call is an IAM problem.

Cloud Identity specifically manages:

• Users: managed accounts under your domain, such as alice@example.com
• Groups: collections of users that IAM bindings target
• Sign-in policies: which accounts can authenticate and how
• MFA / 2-step verification: enforced at the directory level for all users
• SSO and federation: connecting your existing identity provider so users authenticate once
• Provisioning and deprovisioning: automated user lifecycle via SCIM

How Cloud Identity works end to end

Here is the full access flow from a user logging in to reaching a GCP resource:

1. Identity exists in Cloud Identity. A managed user account (alice@example.com) is created in the Cloud Identity directory, either directly or synchronised via SCIM from a corporate identity provider (IdP).

2. User signs in. Alice signs in through Google’s login screen or is redirected to your corporate IdP (Okta, Active Directory, Entra ID) via SAML 2.0 SSO. Authentication happens before GCP resource access is involved.

3. MFA and access policies are checked. Cloud Identity enforces whatever authentication requirements are configured: 2-step verification, hardware security keys, or context-aware access conditions.

4. User is a member of one or more groups. Alice belongs to platform-engineers@example.com. Group memberships are maintained in Cloud Identity and are the mechanism through which IAM access is assigned at scale.

5. IAM bindings grant permissions to those groups. The group platform-engineers@example.com has roles/logging.viewer on the production project. Alice inherits this permission through her group membership. See IAM policies for how bindings are structured.

6. Access is evaluated at the resource level. When Alice makes an API call, GCP checks whether any IAM binding on the resource, project, folder, or organisation grants the required permission to Alice or to any group she belongs to.

Cloud Identity and the Organisation node

GCP’s resource hierarchy starts at the Organisation level. You cannot create an Organisation node without Cloud Identity or Google Workspace tied to a verified domain.

Without an Organisation node, each GCP project is isolated. You can still use IAM within individual projects, but you cannot apply organisation policies that span all projects, inherit IAM bindings from the top of the hierarchy, or enforce guardrails that apply automatically to every project your team creates in the future.

Cloud Identity comes in two tiers. The difference is not in core identity features — both support managed users, groups, SSO, and the Organisation node — it is in device management depth:

• Cloud Identity Free: managed users, Google Groups, SSO, basic endpoint management, and full support for IAM and organisation policy management. Available at no additional per-user cost.

• Cloud Identity Premium: adds mobile device management, advanced security policies, endpoint verification, context-aware access, and extended audit reporting. Priced per user. Google Workspace plans include Premium features.

What Cloud Identity manages

Cloud Identity is more than a user list. Here is what it controls and why each part matters for GCP access:

• Managed users: accounts under your domain. Unlike personal Google accounts, managed users can have organisation-wide authentication requirements enforced, can be deprovisioned centrally, and are visible in Admin Console audit logs.

• Groups: collections of users that IAM policies target. Groups are how you avoid binding roles to individuals. See users vs service accounts for when each identity type is appropriate.

• SSO (Single Sign-On): users authenticate once through your corporate identity provider and access GCP without a separate Google password. Cloud Identity acts as the service provider; your IdP is the authentication authority.

• MFA / 2-step verification: enforced as a directory-level policy for all users, not just as an optional setting. You can require hardware security keys for privileged accounts and standard authenticator apps for others.

• Federation with external IdPs: SAML 2.0 integration with Okta, Active Directory, Entra ID (formerly Azure AD), Ping Identity, and other providers. Users authenticate with their existing corporate credentials; Cloud Identity trusts the assertion.

• SCIM provisioning and deprovisioning: the System for Cross-domain Identity Management (SCIM) protocol synchronises user and group data from your corporate IdP to Cloud Identity automatically. When you deactivate someone in your IdP, the change propagates to GCP access without manual intervention.

The group-first access model

Grant access to groups, not to individual users. This is the single most impactful structural decision you can make for IAM maintainability in GCP.

When you bind a role to an individual user, that binding has no automatic lifecycle. When the user changes roles or leaves, the binding stays in your IAM policy until someone finds and removes it manually, across every project the user had access to.

When you bind a role to a group, access follows group membership. Add a new team member to the group and they inherit all the group’s permissions immediately. Remove them from the group and access disappears. The IAM binding itself never changes. This is also what makes SCIM deprovisioning reliable: when a user is removed from a group in Cloud Identity, they lose every permission that group carried, automatically.

Define groups around job functions, not project names or temporary needs:

• platform-engineers@example.com: infrastructure and platform team
• security-auditors@example.com: security team with read access to audit resources
• data-analysts@example.com: analysts who query BigQuery datasets
• app-developers@example.com: developers with dev and staging project access
• prod-oncall@example.com: on-call engineers with elevated production access

# Bind a group to a role — covers all current and future group members
gcloud projects add-iam-policy-binding my-app-prod \
  --member="group:platform-engineers@example.com" \
  --role="roles/logging.viewer"

# List current IAM bindings to check for direct user: bindings
gcloud projects get-iam-policy my-app-prod \
  --format="table(bindings.role,bindings.members)"

# Find individual user: bindings that should be migrated to groups
gcloud projects get-iam-policy my-app-prod \
  --format=json | \
  python3 -c "
import json, sys
policy = json.load(sys.stdin)
for b in policy.get('bindings', []):
    for m in b['members']:
        if m.startswith('user:'):
            print(b['role'], m)
"

For practical examples of applying least privilege through group bindings, and for understanding how to structure roles correctly, see managing IAM with gcloud.

Connecting to your existing identity provider

Most organisations already have an identity provider (IdP): Active Directory, Entra ID (Azure AD), Okta, Ping Identity, or another SAML or OIDC-based system. Cloud Identity connects to these through two complementary mechanisms:

• SAML 2.0 Single Sign-On: users authenticate via your existing IdP. Cloud Identity trusts the SAML assertion and grants GCP access without a separate Google password. When a user is deprovisioned in the IdP, they immediately lose the ability to authenticate.

• SCIM provisioning: user and group data synchronises automatically from your IdP into Cloud Identity. Create or deactivate a user in your corporate directory and the change propagates to GCP access. This is the automated offboarding path.

SCIM provisioning paired with group-based IAM bindings is the combination that makes offboarding reliable. When an employee leaves:

1. HR deactivates them in the corporate directory.
2. SCIM propagates the deactivation to Cloud Identity.
3. The user can no longer authenticate via SAML SSO.
4. Their group memberships are removed, which removes their inherited IAM access.

Without this chain, offboarding relies on manual steps that get missed under routine operational pressure. If you manage non-human workloads, Workload Identity Federation applies the same principle to service identities: external workloads authenticate without long-lived keys, and access is revoked at the source.

When to use Cloud Identity

Cloud Identity is the right choice in all of these scenarios:

• Central access control for GCP: managed accounts, group-based IAM, and org-level policies all require Cloud Identity or Google Workspace.

• Managed accounts instead of personal Gmail: personal accounts cannot have organisation-wide MFA enforced, cannot be deprovisioned centrally, and leave IAM bindings behind when users leave.

• SSO with an existing IdP: if your team already authenticates through Okta, Entra ID, or Active Directory, Cloud Identity federates with it so users do not need a separate Google password.

• Reliable offboarding: SCIM provisioning means deactivating someone in your corporate directory automatically revokes their GCP access, with no manual cleanup list required.

• Org-level governance across many projects: Cloud Identity creates the Organisation node required for organisation policies and inherited IAM that span all current and future projects.

Cloud Identity vs IAM

These two systems work together but serve entirely different roles. Knowing the boundary prevents confusion when debugging access problems and when designing your access model from scratch.

• Cloud Identity manages identities and authentication: users, groups, sign-in policies, MFA enforcement, SSO, and federation with external providers. It answers who is this person and can they sign in?

• IAM manages authorisation and permissions: role bindings that determine what an authenticated identity can do on which resources. It answers does this identity have permission to do this?

• They are not alternatives — both are required. Cloud Identity provides the verified identity. IAM grants permissions to it. A sign-in failure is a Cloud Identity problem. A permission denied error on an API call is an IAM problem.

For the IAM side of this relationship, see IAM roles explained and how IAM policies work. For the distinction between human identities and service identities, see users vs service accounts.

Cloud Identity vs Google Workspace

Cloud Identity and Google Workspace share the same underlying directory infrastructure. The practical difference is what comes with it beyond the directory:

• Cloud Identity: directory, groups, SSO, MDM, and GCP Organisation node. No Gmail, Docs, Meet, or Drive. The right choice for organisations that use GCP but already have productivity tools from another provider such as Microsoft 365.

• Google Workspace: everything in Cloud Identity Premium plus Gmail, Docs, Drive, Meet, and the full productivity suite. If your organisation already uses Workspace, your GCP Organisation node is already tied to your Workspace domain.

If you use Microsoft 365 and GCP together, the typical setup is Cloud Identity with Entra ID (Azure AD) as the IdP, federated via SAML and SCIM. Users log in with their Microsoft credentials; GCP trusts the assertion. You keep one source of truth for identity rather than maintaining two separate directories.

Super Admin accounts

The Super Admin role in Cloud Identity is separate from GCP IAM. It controls the directory itself: creating and deleting users, resetting passwords, and managing the domain. Because a Super Admin can reset credentials for any user in the organisation, including those with Owner-level GCP access, it is the highest-privilege role in your entire cloud environment, even though it never appears in any GCP IAM policy.

• Keep Super Admin accounts to the minimum needed, typically two or three named individuals. Every additional Super Admin is additional attack surface.
• Require hardware security keys for all Super Admin accounts. Standard authenticator apps are insufficient at this privilege level.
• Do not use Super Admin accounts for day-to-day work. Use a lower-privilege admin account for routine tasks; Super Admin access should be exceptional.
• Alert on every Super Admin login and every privilege change made under that role. Unexpected Super Admin activity is a priority security event.
• Store Super Admin recovery codes in an offline, physically secured location. Losing access can lock you out of your entire domain.